Todo Context Api에 대하여...

<회고록>

Todo List를 context api를 통해서 만들어 보자는 생각이 들었다. 그럼 여기서 이런 의문이 들 수 있다. 왜 컨텍스트 api를 이용해서 만들었는가? redux라는 라이브러리도 많은데 context api를 고른 이유는 무엇인가? 이유는 다음과 같다. 

• redux의 경우 생각보다 굉장히 무거운 라이브러리 이다. redux의 장점은 버그나 로그 관리등 부가적으로 할 수 있는 것들이 많다는 점이다. 하지만 그만큼 무겁고 redux를 사용하기에는 환경 세팅이 정말 어렵다는 점이다. 근데 이번에 내가 만든 todo list는 사실 그렇게 무거운 프로그램이 아니다. 따라서 redux를 사용하기에는 적합하지 않는 환경이라고 생각했다. 그래서 나는 redux보다 상태관리를 하는데 좀더 가벼운 context api를 선택하게 되었다.
• 사실 redux , recoil , react-query는 모두 context api를 기반으로 만들어졌다. 그렇기 때문에 모든 라이브러리에 근간이 되는 것은 context api라고 봐도 무방하다. 그래서 나는 이런 라이브러리들을 사용하기 전에 라이브러리들이 만들어지는데 근간이 되는 context api를 먼저 시도하고 다른 라이브러리들을 사용하고 싶다는 생각도 있었다.

<컴포넌트 구조>

컴포넌트 구조는 사실상 굉장히 간단하게 작업했다. 첫번째로 TodoList와 TodoForm이라는 컴포넌트가 있는데 이들의 관계는 부모 자식 관계가 아니라 형제 관계이다. 따라서 props를 통한 데이터를 주고 받는 것은 사실 상 이 2가지 컴포넌트들을 가지고는 불가능하다. 그래서 나는 이들을 감싸는 TodoContainer라는 컴포넌트를 만들었다. 그리고 이 컴포넌트가 사실상 context api로 이루어진 녀석이다. 결과적으로 로직과 관련된 부분들은 TodoContainer라는 컴포넌트 내에 만들어 두고 이를 각 TodoList와 TodoForm이라는 컴포넌트에서 사용하는 구조이다.

<context api의 사용후기>

• 장점
  • 각 컴포넌트의 역할 들이 명확해졌다. TodoContainer는 로직과 전체적인 컴포넌트를 감싸는 역할 , TodoForm은 TodoForm와 관련된 뷰 역할을 하는 컴포넌트 , TodoList은 TodoList와 관련된 뷰 역할을 하는 컴포넌트 이런 식으로 각 역할이 명확해졌다.
  • 뷰와 뷰모델의 역할의 구분이 명확해졌다. 뷰 역할을 하는 TodoForm , TodoList에는 로직이 들어가지 않고 뷰모델을 담당하는 TodoContainer에는 뷰와 관련된 부분이 들어가지 않는 듯 각 역할의 구분이 명확해졌다는 장점이 있다.
• 단점 (아쉬웠던 점?)
  • 사실상 context api를 굉장히 규모가 큰 프로그램에서는 그 역할을 담당하기에는 아직 부족하다는 느낌이 들었다. 왜냐하면 context api자체는 전체적인 컴포넌트 관리도 되지만 사실 상 2개 ~ 5개 사이에 간이적인 컴포넌트를 관리하는데 더 초점을 둔 상태 관리 도구라고 생각한다. 즉 아직까지는 전체 상태관리를 하기에는 로깅 , 에러 핸들링 , 부가 적인 기능들을 관리하는데는 무리가 있다고 판단이 들었다.