2주 차 네 번째 수업 TIL

원티드 프리온 보딩 프론트 앤드 2주 차 네 번째 수업  TIL (22.01.24~22.03.03)

프리온 보딩 프론트 앤드의 강사님은 위 코드의 공동 창업자&이사의 직책을 가지고 계신 김예리 님이 강의를 해주셨습니다.

 

Redux

• 리액트 Redux를 설명해보세요.
• 답: 리액트에서 전역변수로 하나의 스테이트 값을 이용할 수 있는 라이브러리를 의미합니다

 

• Redux의 장점은 무엇이 있나요?
• 답: 하위객체에 필요한 props 가 있다면 계속해서 밑으로 전달하는 것이 아닌 redux에서 필요한 값을 불러와서 사용하면 되기 때문에 사용하기 좋고 로그인 중인지 여러 페이지에서 계속해서 확인하는 작업이 필요하다면 모든 페이지에서 동일한 값을 가지고 있어야 하는데 이럴 때 좋습니다

 

• Redux에서 준수해야할 3가지 원칙은?
• 답 :
• state 값을 직접적으로 변경해선 안됩니다. EX ) state.push("1) 
• state의 값은 dispatch의 reducer 함수를 변경하여 값이 변경되어야 합니다. 

여기까지가 저의 생각이였고 인터넷 검색에서는 다음과 같이 나와 있습니다.

• 단일 진실 출처(저장소).
• 상태가 읽기 전용(작업).
• 순수 함수(Reducer)로 변경한다.

 

• Redux와 비슷한 다른 것들은 써보았는지?
• 답: Redux를 배우기 이전에 recoil을 써보았습니다. 그렇지만 전역 변수를 관리할만한 프로젝트 경험이 많지 않아서 공부하기 위해서 써본 경험이 있습니다.

 

• 어떤 상황에서 Redux를 쓰면 좋고 왜 그런지?
• 답 : 페이지가 많고 프로젝트의 규모가 커졌을 때 유저의 값을 저장한다거나 모달창이 떠있는 상태인지 혹은 토스트를 작동 중인지 등등 전역 변수를 통해 사용자에게 오류를 내지 않고 이용에 있어서 불편함을 없애기 위함입니다.

Data Binding

단방향과 양방향에 대해 알려주셨고 단방향은 리액트, 양방향은 뷰로 예시를 들어서 설명해주었습니다.

• 뷰(화면)과 모델(데이터)을 연결하는 것을 의미.
• 단방향(One way Data Binding, Unidirectional Data Flow)
• 양방향(Two way Data Binding)

MVC Pattern

MVC 패턴에 대해서 설명해주었습니다. 이렇게 패턴이라고 생각하지 않고 사용했었는데 무엇을 사용하고 있는 중인지 알게 되었습니다

Model

• 데이터라고 생각하면 된다. json 또는 데이터 모델 정의.
• 일반적으로 데이터를 처리하는 로직과 함께!

View

• 화면, html, 레이아웃이라고 생각하면 된다.

Controller

• 이벤트 핸들러와 이벤트를 처리하는 로직이 있는 곳이라고 생각하면 쉽다.
• 데이터랑 뷰 이어주는 역할.
• 요청이(이벤트 발생) 오면 모델에 적절한 로직을 실행하도록 한다.

Flux Pattern

MVC 패턴과 Flux 패턴이 나오게 된 경위를 설명해주시면서 왜 Redux 같은 전역 변수 라이브러리가 필요해졌는지 설명해주셨습니다.

기존 MVC의 문제점

• 프로젝트 규모가 커질수록 빠르게 복잡해진다.
• feature 추가될 때마다 모델과 뷰를 연결하는 복잡성이 증가한다.
• 데이터 간의 의존성과 연쇄적인 갱신은 뒤얽힌 데이터 흐름을 만들고 예측할 수 없는 결과로 이끌게 된다.
• 새로 온 개발자가 합류하면, 너무 복잡해서 코드만 보고 해석조차 불가능. (유지비용 증가)
• 복잡성이 증가할수록 예측 불가능해지고 안정성이 떨어진다. (어디서 버그가 터져 나올지 테스트도 어렵다..)

Flux

• 단방향 데이터 흐름(unidirectional data flow)이 핵심.
• 사용자에 의해 Action이 발행되면, 해당 Action에 영향이 있는 모든 View가 갱신(rerender)된다. 어디에서 어떤 일이 일어날지 알 수 있다(=예상 가능하다. 복잡하지 않다). 흐름은 하나니까!
• Flux는 세 가지 부분으로 구성 되어 있다.
  1. Dispatcher
  2. Stores
  3. Views(리액트 컴포넌트)

 

Dispatcher 

• dispatcher를 통해 action을 발행한다.
• 모든 데이터는 중앙 허브인 dispatcher를 통해 흐른다.

Store

• 어플리케이션의 데이터와 비즈니스 로직을 가지고 있는 store

Views

• action이 발행되면 이 action에 영향이 있는 모든 view가 갱신됨

Redux

리덕스의 store, action , dispatcher에 대해서 상세히 강의해주셔서 다시 한번 공부하는 시간이 되어서 좋았습니다.

• Store: Application의 전체 state는 store라고 불리는 곳에서 관리된다.
  • store는 redux의 상태값(state)를 갖는 객체이다.
• Action: action은 state 변화를 일으킬 수 있는 행동정보, 현상 등이라고 생각하면 된다.
• Dispatcher: action이 일어나면 Dispatcher를 통해서 store의 state가 업데이트된다.
• View: state가 변경되면 view에서 감지하고, 화면에 반영(rerender) 된다.
• 위의 그림과 같이 view단에서 action이 일어날 수도 있다(당연). view에서 action이 일어나면 -> 다시 dispatcher에 의해 store에 저장되고 -> state가 변경되면 -> 필요한 view에서 감지를 알아차린다.

 

Redux의 세 가지 원칙

리덕스의 세 가지 특징에 대해서 설명해주셨고 리덕스 이해에 도움이 되었습니다.

전체 상태 값이 하나의 객체로 표현됨

• 간단히 말하면 하나의 React앱에 store가 하나라는 뜻임

상태 값(state)은 읽기 전용이다.

• 원래 컴포넌트에서의 state 관리 생각하시면 됩니다.
• (state 값 직접 바꾸지 않고, setState 함수 사용해서 변경했잖아요~)

상태 값(state)은 순수 함수에 의해서만 변경되어야 한다.

• 상태 값(state)을 변경시키려면, 상태 값을 변경하는 함수가 필요합니다.
• 이 함수를 reducer라고 하고, 이 함수가 순수 함수(pure function) 이어야 한다는 말.

 

Context / Provider / Conumer

Context는 리액트에서 아직 사용해본 적이 없는데 프로젝트에서 얼른 공부한 것을 사용해보고 싶습니다.

• Context를 간단히 설명하자면 크게 Provider와 Consumer로 나뉩니다.
  • Provider는 전역 상태를 정의하고, 전역 상태를 update 하는 로직이 있습니다.
  • Consumer로 전역 상태를 사용할 수 있습니다.

React Native

React Native에 대해서 간단하게 설명해주셨는데 저는 어플 개발에 관심이 많고 React Native로 취업 의사가 강력하게 있어서 팀 과제에 RN을 사용하는 과제가 나왔으면 좋겠다는 생각을 했습니다.

 

참고자료

 

• Generator 공부하는데 너무 시간 쓰지 마시고, Redux-Saga 사용법을 익혀주세요!