우주먼지 개발 log
[세션] 리덕스 특강 본문
반응형
1. 전역상태 관리의 필요성- 상태란?
- 일종의 데이터 저장 변경 관리하는 데이따
- 리액트의 UI 렌더링에 필요한 정보들의 의미하기도 함.
- 상태가 변경되면 UI가 리렌더링됨
**가장 기본적인 방법**
//useState
function TestComponent() {
const \[value, setValue\] = useState("초기값"); console.log(value);
_//_ **\=> 초기값** _return_ null;
}
- 그럼 데이터 흐름이 양방향 인 것? -> ex) Vue
- 리액트의 데이터 단방향 흐름의 단점
- 망할 프롭스 드릴링 fxxx
function HomePage () { const [selectedMemeberName, setSelectedMemberName] = useState("진호"); const [letters, setLetters] = useState([]); return ( <dib> <Members _selectedMemeberName_={selectedMemeberName} _setSelectedMemberName_={setSelectedMemberName}/> <Letters _letters_={letters} _selectedMemeberName_={selectedMemeberName}/> </div> ) } function Members({selectedMemberName}) { _//_ **특정 멤버를 선택할 수 있어야 하고, 선택한 멤버가 누군지에 따라 버튼의 색을 바꿔 줘야함.** _return_ ( <ul> <li> <button _onClick_={() => {}} _style_={{ background: selectedMemberName === "진호" ? "aqua" : "white" }}>진호</button> </li> <li> <button _onClick_={() => {}} _style_={{ background: selectedMemberName === "용승" ? "aqua" : "white" }>용승</button> </li> <li> <button _onClick_={() => {}} _style_={{ background: selectedMemberName === "열" ? "aqua" : "white" }>열</button> </li> </ul> ) } function Letters({selectedMember}) { const lettersOnSelectedMember = letters.fillter(letter => letter.MemberName === selectedMember); _//_ **어떤 멤버가 선택되었는지를 알고, 그 값에 따라서 전체 letters를 필터링 할 수 있어야 함** return letters.map(letter => <Letter _key_={letter.id} _content_={letter.content}>) }
- props-drilling은 어플리케이션의 규모가 증가함에 따라 함께 매우 커지고 복잡해지는 경향이 있다.
- 유지 보수의 어려움을 뜻함
- 유지보수가 쉬운 방법을 만들어 내자.
- 전역 상태 관리
- 부모, 자식간의 상태 전달을 넘어서서, 어느 컴포넌트에서나 접근 가능한 "상태 저장소"를 만들어, 그것을 해당 상태가 필요한 컴포넌트에서 불러다가 사용한다.
2. 전역 상태 관리 방법
redux
: 특정한 방식으로 전역 상태 관리를 하는 서드파티 라이브러리- 리액트 자체와는 무관함
- 리액트 보다 fit 하게 가공한 라이브러리 ->
react-redux
context API
: 리액트에서 공식적으로 제공하는, 리액트에 기본적으로 포함되어 있는 기능- 그 외 수많은 라이브러리들:
zustand
: redux를 좀 더 간편하게 사용할 수 있게 만든 redux 경량화 버전react-query
: 전역 상태 관리 + 서버 상태 관리 라이브러리
3. Redux- 쉽지않다 (끄덕) => 용어와 개념이 좀 많고 복잡함.
- 그럼 우리가 해야할 것..?
- 개념을 정확하게 이해
- 용어를 완전히 숙지
- 리덕스를 최초에 설계를 한 분이, 데이터의 변경이 굉장히 보수적이고 절차적으로 바뀌도록 설계함.
- 즉, 얼렁뚱땅 상태가 바뀌는 일이 없도록 함. 상태의 디버깅이 쉽도록 설계함.
- ### 리덕스의 개념
- Reducer는 상태를 변경해 주는 일종의 공장
- 왜 공장이라고 표현?
- 아무렇게나 일하지 않는다.
- 반드시, "작업 지시서"에 따라서만 작업을 한다. 즉 "작업 지시서"에 따라서만 상태를 바꿔준다.
- Redux는 전역에서 접근 가능한 저장소에 있는 상태를, 상태 변화가 필요할 때마다 작업 지시서를 꼼꼼히 써서, 그 작업 지시서를 리듀서(공장)에 보내서 리듀서가 최종적으로 상태를 변경하고, 변경한 상태를 다시 UI에 알려준다. 변경한 상태를 알게된 UI는 리렌더링을 하면서, 변경된 상태로 새롭게 화면을 그린다.
- 그럼 작업 지시서는 대체 어떻게 발행하나?
- 작업지시서 ->
action
- UI(컴포넌트)에서, Action(작업지시서)을 생성하고, 생성한 Action을 리듀서(공장)에 보낸다.
- Action을 생성하는 '함수'가 필요하다. -> 그 함수를 리덕스 용어로
Action creator
- UI에서
Action Creator
(함수)를 (상황에 따라 매개변수와 함께) 호출하여, Action(작업지시서, 객체)를 만들고, 만든 작업지시서를 Reducer에 보낸다. Dispatch
: 만든 작업지시서(Action)을 Reducer 보내는 행위 또는 함수
용어 숙지
- Store - Store가 주입되어 있는 컴포넌트들에서 접근 가능한 상태 저장소(보통은 전역에서 접근)
- State - 상태
- Reducer -
State
를Action
(작업지시서) 내용에 따라 변경해 주는 함수
=>State
를 작업지시서의 내용에 따라서 변경하는 공장 - Action - 작업 지시서. 보통 객체. 이 객체 안에는 보통 1가지는 필수이며, 1가지는 필요에 따라 들어있다.
필수로 들어있는 것 -> 액션의 타입
필요에 따라 들어 있는 것 -> 페이로드(payload): 작업 지시서에 함께 보내는 자료? 준비물 stuff
ex) 작업지시서의 type이 'N만큼_숫자증가' 이면, 당연히 N이 얼만큼인지도 함께 알려주어야 함.
{
type: 'INCREMENT_BY_AMOUNT',
payload: {
amount: 100
}
} _//_ **-> 이걸 받은 reducer(공장)은 state의 특정 값을 100만큼 올린다.**
// Action Creator - 액션(작업지시서)를 만들어 주는 함수. 일반적으로 하나의 액션에는 하나의 액션 크리에이터를 대응해서 만들어 준다.
// Dispatch - 액션을 리듀서로 보내는 행위 또는 함수. -> 작업지시서를 공장으로 보내주는 것.
반응형
'TIL(Today I Learned) > 스파르타 내배캠' 카테고리의 다른 글
[세션] Authentication 인증 (0) | 2024.02.20 |
---|---|
[세션] 중복코드를 관리하는 법 feat. 소셜로그인 (0) | 2024.02.20 |
[스파르타 내일배움캠프][후기] React_3기 찐 프론트엔드 개발자가 되는 과정 >.< (2) | 2024.02.16 |
[취업준비] 이력서 완성 주차, 2일차 (1) | 2024.02.15 |
[취업준비] 이력서 완성주차, 타임테이블 ^.^ (0) | 2024.02.12 |