- 2/2 Redux의 불편함을 해결하기 위한 개선하기위한 3가지 방향 Redux 사용상의 불편함 기능상으로 좀더 inhance를 위해서 나온 서버사이드 상태관리 클라이언트사이드와 서버사이트 아키텍처로 나누어서 클라이언트를 동기화하는데 중점을 두고 서버사이드는 정말 중요한 정보만 담아서 정보관리를 최소화하겠습니다. 부모에서 자식으로 단방향 부모에서 자식으로 상태주고싶으면 → props 자식에서 쓰던걸 부모에서도 쓰고 싶음 → 상태올리기
context API
-
만든다 → createContext → const AuthContext = createContext(); 이렇게 대문자로 만들어야한다. ⇒ 왜? 리액트에서 컴포넌트는 대문자이므로
→ initialValue 넣어주는 이유는? 자동완성기능때문에
-
사용한다 → useContext → 함수다. 함수는 인자를 받을수있따. → 인자로 무얼받느냐 createContext의 리턴값을 인자로 받는다.
-
범위지정한다. → Provider 어디에 들어있어요? → context에 들어있다.
→ AuthContext.Provider이렇게.
→ 근데 우리는 이걸 helloProvider처럼 함수로 래핑을 하겠다. {children} props를 받아서
⇒ 잘모르고 적절하지 않게 사용하면 리렌더링이 많이 발생할수있으니 주의해라 - 공식문서 -
⇒ 왜 래핑을 해서 사용한다고했더라…..?
넣는방식 2가지
authProvier에서 직접 내려주는거
children으로 받아서 내려주는거 하나
자식요소 끌어올리기라고한다??
자식을 직접받는게 아니고, {children}
- ★context 와 redux의 결정적 차이????
하나의 애플리케이션을 만들면 상태가 정말 많이 생길수밖에 없다.
⇒ 객체형태로 묶어서 관리하는게 베스트겠지?
여기서,
redux는 한번에 묶어서 상태를 관리해도 ㄱㅊ.
그 하나만 렌더링이 가능하다
→ context는 그렇지 않다?? 전체 다 렌더링이 되어버린다
⇒ 중복문제
⇒ if esle로 바꾼다.
useSelector() ⇒ 전체 state가 나온다.
const state = useSelector() 근데 이렇게 하면 안된다
store에서
const store = configureStore({ reducer: cartReducer });
이렇게 하면 cartReducer가 루트가 된다.
즉, configureStore({ reducer: {cart: cartReducer } });
- 훅은 함수안에서 호출XX 기억 ⇒ useDispatch()도 훅이다.
- 삭제버튼 클릭이벤트행들러함수 쓸떄 고차함수 쓰는거
★Immer
draft 는 아래아래까지 깊은복사를 해준다
원래는 어떻게 했어야했는지???? 알아봐야겠따…
immer를 그냥 js로 다시 해보자
노드 프로젝트
npm init가장 먼저하자 그리고 나서
npm install
- createSlice()
userSlice = createSlice({
…..
})
createSlice의 장점
action type, action creator 자동으로 만들어주고
immer js 쓸수있고
Redux 데브툴스봐보면
prefix로 붙는거 name
서픽스는 reducer??
