
![image](https://github.com/prefer2/prefer2.dev/assets/67692759/dff7b89c-84e1-4232-b0eb-2969d6c841f0)

## unwrap

[https://redux-toolkit.js.org/api/createAsyncThunk#handling-thunk-results](https://redux-toolkit.js.org/api/createAsyncThunk#handling-thunk-results)

createAsyncThunk로 생성한 thunk는 무조건 promise를 반환한다. 이렇게 반환한 promise는 unwrap 프로퍼티가 있는데 이를 통해 fullfiled된 액션의 payload를 받거나, error를 던지거나, rejected action에서 rejectWithValue로 생성한 payload를 받을 수 있다

```tsx
const onClick = () => {
  dispatch(fetchUserById(userId))
    .unwrap()
    .then((originalPromiseResult) => {
      // handle result here
    })
    .catch((rejectedValueOrSerializedError) => {
      // handle error here
    });
};
```

```tsx
const onClick = async () => {
  try {
    const originalPromiseResult = await dispatch(
      fetchUserById(userId)
    ).unwrap();
    // handle result here
  } catch (rejectedValueOrSerializedError) {
    // handle error here
  }
};
```

언제 사용할까?

action의 fullfilled, rejected 후의 행동이 각 컴포넌트 별로 다를 때(공통적으로 처리가 어려울 때)

If you need to access the error or success payload immediately after a mutation, you can chain `.unwrap()`.

```tsx
addPost({ id: 1, name: "Example" })
  .unwrap()
  .then((payload) => console.log("fulfilled", payload))
  .catch((error) => console.error("rejected", error));
```

> However, it's common to want to write logic that looks at the success or failure of the actual request that was made. Redux Toolkit adds a `.unwrap()` function to the returned `Promise`, which will return a new `Promise` that either has the actual `action.payload` value from a `fulfilled` action, or throws an error if it's the `rejected` action. This lets us handle success and failure in the component using normal `try/catch` logic. So, we'll clear out the input fields to reset the form if the post was successfully created, and log the error to the console if it failed.

---

## Node exporter

[https://github.com/prometheus/node_exporter](https://github.com/prometheus/node_exporter)

[https://prometheus.io/docs/guides/node-exporter/](https://prometheus.io/docs/guides/node-exporter/)

모니터링 데이터를 프로메테우스로 수집하고, 수집한 정보를 한 곳에 모아(통합), 그라파나로 시각화한다고 이해정도만 한 정도…

TL님이 시간 있을때 한번 공부해보면 좋을 것 같다고 추천해주셨다. 최근 새로운 프로젝트를 진행하면서 로그를 추가해줄 일이 있었는데 회사의 로깅 시스템은 정말 잘 되어있는것 같다. 쭉 보다보니 회의때 듣던 이게 무슨 단어이지 싶은 단어들이 많이 나타나는게 아주 공부할게 많은 것 같다. 물론 이미 추상화가 잘되어 있고 미들웨어로 쓱싹하면 로그가 짠하고 나타나지만 공부하면 나쁠거 없지!

[https://d2.naver.com/helloworld/1044388](https://d2.naver.com/helloworld/1044388)

옛날 글이고 지금은 무려 nelo4지만 여기에 적을 수 있는 유일한 글인것 같아 남겨놓기

---

## 브라우저 디버깅

모던리액트 deep dive 중 내용

- 소스탭 > 감시, 범위(스코프), 호출스택, 전역 리스너 등을 확인할 수 있다. 실행하는 파일을 직접 볼 수 있는 것 뿐만 아니라 어떻게 실행되는지 자세하게 알 수 있다. 심지어 감시에 변수 값을 넣어서 원하는 값으로 변경하는 기능도 가능
- 메모리탭
  - 힙 스냅샷 > 비교를 통해 useMemo, useCallback과 같은 값들이 유지되는지 확인할 수 있다 ⇒ 실제로 함수가 재생성되는지 함수명을 기명함수로 두어 확인
  - 타임라인 할당 계측 ⇒ 시간의 흐름에 따른 메모리 변화, 어떤 변수가 일으켰는지

디버깅을 브라우저로 기깔나게 하시는걸 보고… 자스에서도 console.log 디버깅이 아닌 디버깅이 가능한걸 배우고 있는 요즘이다. hover하면 해당 값이 어떤 값 들어갔는지도 잘 볼 수 있고 소스탭을 잘 사용해보자

---

## 짧은 회고

공개될려면 좀 멀었지만 신규 서비스가 하나 완성되었다. 함께 진행하신 분과 하면서 배운게 여러가지인데 코드를 이쁘게 짜는걸 보며 감동받았다. 훅 분리나 로직 분리를 보면서 대박이다라는 생각을 속으로만 계속 하는중ㅋㅋ 나는 아직 예외처리같은 부분은 많이 부족하다고 느꼈는데 불필요한 코드를 작성하는 것은 아닌가라는 생각을(이걸 더하면 지저분해지는 것이 아닐까라는 생각) 줄이고 방어코드를 잘 작성해야겠다. 내가 작성하는 코드의 영향범위를 잘 파악하고 자신감을 가지자! 팀원분들의 좋은점은 많이 배우고 싶다.

집을 구하는 중인데 덕분에 부동산 용어나 돈의 개념에 대해서 생각이 많아지는 요즘이다. 돈의 속성이라는 책이 기본서라는데 한번 읽어봐야하는가 싶다. 좋은 집을 잘 구할 수 있으면 좋겠다.

+) 매주 글작성은 너무 무리라 한달 단위로 변경할래


[WIL] 2024.01


![image](https://github.com/prefer2/prefer2.dev/assets/67692759/6ff326a7-514c-4f56-bcaa-c7004804f176)


## 무중단 배포

무중단 배포는 말 그대로 서비스가 중단되지 않은 상태로 새로운 버전을 사용자들에게 배포하는 것을 의미한다. 기본적으로 최소 2대의 서버가 필요하다

- 롤링(rolling) 배포
    - 트래픽을 점진적으로 구버전에서 새로운 버전으로 옮기는 방식.
    - 새로운 버전의 인스턴스를 생성하고, 로드밸런서에 이 인스턴스를 연결하고 구버전의 어플리케이션이 실행되는 인스턴스를 하나 줄인다
    - 이전 버전이 사용되는 어플리케이션에 대한 연결을 없애고 새로운 버전으로 교체한 후 다시 연결하는 방식
    - 다양한 오케스트레이션 도구에서 지원한다. 많은 서버 자원을 확보하지 않아도 무중단 배포가 가능하다는 장점이 있다. 점진적으로 새로운 버전이 사용자에게 출시되므로 배포로 인한 위험성이 줄어든다는 장점도 있다
    - 배포 도중 서비스 중인 인스턴스 수가 줄어들게 되어 각각의 서버가 부담하는 트래픽의 양이 늘어날 수 있다. 트래픽을 잘 파악해야 한다. 또 구버전과 신버전이 동시에 서비스되기 때문에 호환성 문제도 발생할 수 있다
- blue/green 배포
    - 트래픽을 한번에 구버전에서 신버전으로 옮기는 방법. 현재 운영중인 서비스의 환경을 Blue라고 부르고, 새롭게 배포할 환경을 Green이라고 한다.
    - 배포 시점에 로드 밸런서가 트래픽을 Blue에서 Green으로 일제히 전환시킨다
    - 한번에 트래픽을 모두 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않는다
    - 실제 운영에 필요한 서버 리소스 대비 2배의 리소스를 확보해야 한다
- 카나리(canary) 배포
    - 점진적으로 구버전에 대한 트래픽을 신버전으로 옮기는 것은 롤링 배포 방식과 비슷하지만, 새로운 버전에 대한 오류를 조기에 감지하기 위한 방식이다
    - 소수 인원에 대해서만 트래픽을 새로운 버전에 옮긴 상태에서 서비스한다. 새로운 버전에 이상이 없다라고 여겨진 경우에 모든 트래픽을 신버전으로 옮긴다. 이때 새로운 버전으로 옮기는 기준은 랜덤이다.
    - 새로운 버전으로 인한 위험을 최소화 할 수 있지만, 신/구 버전의 애플리케이션이 동시에 존재하므로 호환성 문제가 발생할 수 있다

공부해야하는 내용이라는 조금 다른 방향으로 공부했지만 이번기회에 한 번 정리해봐서 좋다

## npm install VS npm ci

우선 package.json과 package-lock.json의 차이를 알아야한다. package.json에는 version range로 의존성 목록의 버전을 관리한다(eg. “react”: “^17.0.2”) 이러한 version range로 협업하는 사람마다 서로 다른 node_modules를 생성할 수 있다(각자의 로컬 환경마다 npm, node 버전이 다를 수 있기 때문에)

package-lock.json은 package.json과 다르게 정확한 버전이 명시되어 있다. 이때문에 우리는 협업시에 package-lock.json도 형상관리를 해주는 것이다.

### npm ci(clean install)

- 쓰기 권한이 없다
- package-lock.json이 무조건 존재해야만 하고, 없으면 에러를 낸다
- package-lock.json 파일을 기반으로 의존성을 설치하고, package.json은 버전 매칭 벨리데이션 용도로 사용한다
- node_modules를 삭제한 후, 의존성을 한번에 설치한다

https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci

초기 install은 `npm c`i를 사용하자…!


## RTK

principle of Redux, which is that, everything that changes in your application, including the data and the UI state, is contained in a single object, we call the state or the state tree.

### configureStore

- option 객체가 named되어 있어 읽기 쉽다
- `applyMiddleware`로 미들웨어들을 배열로 전달
- 자동으로 Redux DevTools 사용

기본적으로 redux-thunk 미들웨어를 가지고 있다. 

```jsx
import { configureStore } from '@reduxjs/toolkit'
import usersReducer from './usersReducer'
import postsReducer from './postsReducer'

const store = configureStore({
  reducer: {
    users: usersReducer,
    posts: postsReducer,
  },
	middleware: ...
	enhancers: ...
})

export default store
```

### createSlice

createSlice는 reducer 함수에 기반해서 action type과 action creator를 자동으로 생성해준다.

```jsx
const postsSlice = createSlice({
  name: 'posts',
  initialState: [],
  reducers: {
    createPost(state, action) {},
    updatePost(state, action) {},
    deletePost(state, action) {},
  },
})

// Extract the action creators object and the reducer
const { actions, reducer } = postsSlice
// Extract and export each action creator by name
export const { createPost, updatePost, deletePost } = actions
// Export the reducer, either as a default or named export
export default reducer
```

- initialState
- name: 생성된 action의 prefix
- reducers
- **extraReducers**

slice의 컨셉! 각 slice reducer가 state의 slice를 가지고 있다는 점. 그리고 많은 slice reducer들이 같은 action type에 독립적으로 응답할 수 있다는 점.

extraReducers

비동기 액션에 대한 리듀서? createAsyncThunk를 통해 생성된 action을 다룰 때 주로 사용

reducer와 extraReducer가 모두 같은 action type에 동작한다면 reducer가 사용됨

builder callback

```jsx
// createReducer에서도 builder function 형식을 따라감
// createReducer는 좀 더 편하게 reducer를 만드는 방식

import { createAction, createReducer } from '@reduxjs/toolkit'

interface CounterState {
  value: number
}

const increment = createAction('counter/increment')
const decrement = createAction('counter/decrement')
const incrementByAmount = createAction<number>('counter/incrementByAmount')

const initialState = { value: 0 } as CounterState

const counterReducer = createReducer(initialState, (builder) => {
  builder
    .addCase(increment, (state, action) => {
      state.value++
    })
    .addCase(decrement, (state, action) => {
      state.value--
    })
    .addCase(incrementByAmount, (state, action) => {
      state.value += action.payload
    })
})
```

builder object

- addCase
- addMatcher
- addDefaultCase

https://redux-toolkit.js.org/api/createReducer#usage-with-the-builder-callback-notation

### createAsyncThunk

```jsx
import { createAsyncThunk, createSlice } from '@reduxjs/toolkit'
import { userAPI } from './userAPI'

// First, create the thunk
const fetchUserById = createAsyncThunk(
  'users/fetchByIdStatus',
  async (userId, thunkAPI) => {
    const response = await userAPI.fetchById(userId)
    return response.data
  }
)

// Then, handle actions in your reducers:
const usersSlice = createSlice({
  name: 'users',
  initialState: { entities: [], loading: 'idle' },
  reducers: {
    // standard reducer logic, with auto-generated action types per reducer
  },
  extraReducers: (builder) => {
    // Add reducers for additional action types here, and handle loading state as needed
    builder.addCase(fetchUserById.fulfilled, (state, action) => {
      // Add user to the state array
      state.entities.push(action.payload)
    })
  },
})

// Later, dispatch the thunk as needed in the app
dispatch(fetchUserById(123))
```

https://redux-toolkit.js.org/api/createAsyncThunk

https://blog.hwahae.co.kr/all/tech/6946


## 짧은 회고

조각조각 공부한 내용들이 아까워서 주간 회고를 하려고 한다. 얼마나 오래 갈지는 모르겠지만 한 번 시작하면 몇주라도 더 열심히 메모할테니까….! 글쓰기 습관을 들이자

공통 기술 교육이 끝나고 이제 진짜 팀 교육이 시작되었다. 지금까지 내가 경험해왔던 프론트엔드에만 집중하는 개발이 아닌 조금 더 큰 그림의 학습을 하고 있어 신기하다. 시야를 넓힐 좋은 기회라 생각한다. 새로운걸 공부해서 그런지 간만에 코딩해서 그런지 재미나다.

연수원도 갔다왔겠다 이제 진짜 공부하자 하핳


Tags - redux (2)

[WIL] 2024.01

[WIL] 8월 4, 5주차