<aside> ⭐ 학습목표

• 상태관리 개념과 원칙
• flux pattern
• action, dispatch, reducer, middleware, store
• redux-toolkit을 이용한 상태관리 실습
• 이력서 피드백 </aside>

<aside> 💬

TIL

redux와 상태관리에 대해 복습하는 시간을 가졌다. 복잡하게만 느껴졌던 개념들도 계속 접하다 보니 조금씩 익숙해지는 듯했다.

• Redux에서 도입한 Flux 패턴이 Flux 패턴 그 자체인 줄 알았다. 하지만 일반적인 Flux 패턴은 store가 여러 개 있을 수 있지만 Redux는 단 하나의 store만 가진다는 차이가 있었다. 하지만 Flux와 Redux 모두 단방향 데이터 흐름을 사용하여 데이터의 일관성과 예측 가능성을 유지한다.
• Redux가 다른 상태관리 툴과 비교해 보일러 플레이트 코드가 많고, 학습 곡선이 있으며, 사용하기 불편하다는 단점에도 불구하고 아직까지 많은 회사에서 사용하고 있는 것 같다.
• 마지막 세션으로 진행한 이력서 피드백이 많은 도움이 되었다. 다른 사람들이 작성한 이력서를 보며 좋은 점, 보안해야 할 점 등을 자세히 피드백 해주셔서 내 이력서도 다시 수정을 해야할 것 같다는 생각이 들었다. 좀 더 구체적이고 자세한 설명과 트러블 슈팅 등을 강조 하였는데, 다른 사람들의 이력서를 보니 내 이력서가 왜 눈길이 가지 않는지 알 것 같기도 했다. 그런데 다들 이력서에 경력도 많고, 프로젝트도 많네.. 😢 </aside>

📖 table of contents

1. 상태관리와 패턴

• 모든 애플리케이션은 state값이 있음

• 컴포넌트간의 다른 상태를 공유함으로써 애플리케이션을 reactive하게 유지할 수 있음

• state는 변경사항 발생했을 때 이 변경 사항을 사용하는 모든 View에서 반영이 되어야함

• props drilling을 방지하기 위해 전역 상태관리를 사용

• 어떤 아키텍쳐를 사용하는지에 따라서 데이터 흐름은 달라지고 View에 반영하는 방식도 달라진다.

  ex. MVC, Flux

▪️MVC pattern

• Model 애플리케이션의 데이터를 처리

• View 데이터를 표시하는 역할을 하는 UI. data-flow의 마지막 단계

• Controller View와 Model 구성 요소 사이의 인터페이스

• 컴포넌트간 데이터 흐름이 다방향으로 흐르는 것은 문제가 아니다. 오히려 좋을지도. 하지만 데이터가 여러 방향으로 진입될 때 서로 동기화가 되지 않을 가능성이 커짐 → Redux가 Flux 패턴을 사용한 이유

  

  MVC 패턴의 Data Flow

▪️Flux pattern