Today I Learned
Container Component in React
이 블로그를 참조해서 공부를 했는데, 리액트를 통해 좀더 유지, 보수하기 좋은 코드를 짜기 위한 고민을 해봤다.
The most common function of a container component is to obtain data. Obtaining data doesn’t mean the traditional way of fetching data from an API’s endpoint, it also has to do with the logic of a React component.
Once the process of executing the logic or obtaining data in the component is complete. It renders the corresponding component Sometimes, the container component can perform two functions (i.e. to render UI and hold logic).
그러면서 Container Component가 뭘까에대해 고민하게 됐고, 위 블로그에서 답을 얻을 수 있었다. 주로 리액트를 개발하다보면, data 부분과 view 부분을 분리해서 개발하곤 한다. 근데, Container component 만큼은 data, view 부분이 분리돼있지 않다. 즉, 모두를 포괄하는 의미에서 container로 쓰인다. 데이터 로직을 container에서 관리하고, 나머지 하위 컴포넌트 들에서는 렌더링 로직만 넣어놓는 것이다. 근데 이게 뭐가 좋을까?. 사실 컴포넌트 단위로 개발을 하는 리액트에서 하나의 컴포넌트 내에 그에 맞는 데이터 로직과 렌더링 로직이 있는 것이 나쁜건가하면 명확히 그렇다고는 할 수 없다. 하지만 단위를 컴포넌트가 아닌 여러개의 컴포넌트로 구성된 컨테이너로 개발한다고 하면, 컨테이너에서 데이터 로직을 처리하고, 그 하위 컴포넌트에서는 그 데이터를 받아서 렌더링만하게 하는 것이 훨씬 심플해보인다.
결론부터 얘기하자면, React 에서 Component 를 Presentational Component 와 Container Component 로 나누는 것은 재사용성과 유지보수성을 높이기 위함이다.
[출처][React] Presentational and Container Components|작성자 JeromeBaek
이 블로그도 참고해서 작성했는데, 훨씬 presentational & container 개발 패턴에 대해 명확히 이해해볼 수 있었다. 하지만 마지막으로 기억해야할 것은 이것은 일종의 패턴일 뿐이지 '강제성'은 아니라는 것이다. 즉, presentational component에 state가 있으면 '절대로' 안되는가? 라고 하면 답은 NO다.
FLUX Pattern
항상 나는 'FLUX' 패턴을 사용중이라고만 생각을 하고 써왔지, 이것이 뭘까에 대해 정확히 고찰해본적은 없다. 일단 FLUX Pattern은 MVC 패턴의 대안으로 나온 패턴이다. MVC 패턴이 View와 Model의 양방향 데이터 흐름을 지향함에 따라 view와 model이 많아지면서 그 흐름이 복잡해지고, 비동기적으로 처리하거나 model간의 교류가 있을 경우에는 혼선(에러)이 발생하는 등의 문제가 있게되자, 이에 대한 대안으로 FLUX 패턴, 즉, 단방향 데이터 흐름을 지향하는 패턴이 나온 것이다. FLUX 패턴이 어떤 흐름으로 데이터와 view 로직을 만드는지 보면, REDUX를 쓸 때와 '거의'유사하다. VIEW에서 유저가 인터랙션(ACTION)을 일으키면 그 액션으로부터 시작해서
ACTION => DISPATCH => STORE => VIEW 이런식으로 계속해서 반복된다.
A, B 블로그를 통해서 이해해봤는데, 좋은 것 같아 첨부한다. 이에 더해서 모두가 알고 있을 https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-GS188xDYE-u1ShQmFFGbrk0v&t=621s
페이스북 개발자의 강연도 참고해보면 좋을 듯하다(시간이 꽤돼서 나중에 봐야겠다)
