블로그글 보면

- 전역상태관리

- Props drilling의 귀찮음 해소

컴포넌트 간에 state변경 등 이런 소리가많은데


이런건 다 부차적이라고 생각했음.


왜냐하면 그 리덕스 라이브러리 하나때문에 

1) 파일나눠가지고 코드 여러개써야하고,

2) 리액트 라이프사이클은 무시당하고,

3) 요상한 문법으로 코드는 더 알아보기 힘들어지지 않는 등... (개같은 mapStateToProps  같은 함수)

이지랄염병떨어야하는 코스트가 생기기 때문..


단순 props drilling방지, 전역상태관리를 원한다면 다른 코드량 적게드는 솔루션들이 많음...


그럼 그 좆같은 ACTION, REDUCER 파일 나눠가면서 얻어가는게 뭐냐?

독립적인 UI State관리라고 생각함.


웹개발은 보통 사용자들이 보는 모바일처럼 뷰를 기준으로 본다기보단, 컴포넌트를 기반으로 만들기 때문에 

중구난방식으로 퍼져있는 컴포넌트들의 각각의 상태를 관리하려면 그냥 간단한 상태관리로직 + UI바인딩으로 운영되는 리덕스같은게 제일 좋은듯 (컴포넌트 단위가 100개정도가 넘어간다면)

뷰나 페이지가 어떻게 구성되어있나 상관없이, 그냥 내가 원하는 상태를 기준으로 관리한다는 점이 큰 리덕스를 통해 얻을 수 있는 이득인듯. (가장 심플한 솔루션이라 오히려 좋게된 케이스)


컴포넌트가 늘어나면 늘어날수록 

코드관리/상태관리/유지보수 부분에서 다른 솔루션들에 비해  이점이 생기고..


근데 컴포넌트가 적으면 적을수록

가치는 확연하게 떨어지는듯..


그럼 비슷한 다른 솔루션들은 왜 리덕스에 비해 별로냐?

Mobx같은 솔루션들은 사용자들이 보는 뷰 혹은 컴포넌트 하나당 mobx가 붙을 수 있어서 지역상태부터 전역상태까지 관리해줄 수 있음.

컴포넌트 기준으로 관리되기때문에, 개발자가 별도로 컴포넌트들을 관리하거나 해야한다고 생각함. 이게 은근 불편.

redux는 컴포넌트의 구성과 상관없이 그냥 상태를 기준으로 관리하기때문에 이런점에서 우위가 있는듯.


따라서 mobx는 컴포넌트양과 코드가 많아질수록 확실히 더 불리해지는 솔루션이라고 생각함.



근데 갠적으로 소규모 개인프로젝트에서는 아무것도 안써도 된다고본다

리액트는 보면볼수록 존나 완벽한 MVC프레임워크같음.

특히 요즘처럼 훅으로 개발하는경우는 양방향 바인딩도 굉장히 쉽게된다고 생각하고..

테스팅도 별도 라이브러리없이 하기도 쉬움. 


리액트 사랑하지만

하지만 vue나 공부해야지.

에반유 만세.