recoil은, 최신 기술은 항상 옳은가?

recoil 도입, 그후

기존의 recoil을 이용한 컴포넌트의 상태 관리는 내게 있어 매우 혁명적이었다.

그러나 내가 생각하는 컴포넌트의 기능 구현이 상상 이상으로 지연되었고,
그것의 원인 또한 recoil이었다.

recoil은 분명 놀랍도록 간결하고 강력한 라이브러리지만
좁은 커뮤니티와 문서를 포함한 다양한 sample code, troubleshooting case의 부족함은 극복하기 어려운 난제였다.
상당히 오랫동안 똥볼만 걷어찬 것은 명확한 output을 뽑아내고자 하는 내 목표에 큰 장애물이다.

다양한 관점에서 이 문제를 바라보고 올바른 방향으로 해결해보도록 하자.

해결방법

결국은 선택이다.
단순하다.
recoil을 이용하여 안될것 같다면 redux를 도입하면 된다.
하지만 reocil로 안된다는건 내 레벨에서 안된다는 것이지 recoil로 불가능한게 아니다.
아마 다른 관점과 더 많은 지식으로 충분히 해결할 수 있겠지.

하지만 flux의 핵심개념을 recoil을 이용하여 이해하는것에 실패했고,
더 많은 정보가 필요한 지금 시점에서 과연 이게 옳을까?

또, redux로 변경한다고 해서 이 문제를 해결할 수 있을까?

그럼에도 확실한건 무슨 방법이든 해봐야한다는것이다.
redux는 도움받을 수 있는 루트가 많다.

recoil을 redux로 전환해보자.

느낀점

최신 라이브러리이고, 평가가 좋다고해서
입문자가 섣불리 도입하는것은 별로 좋지 못하다고 느꼈다.
입문자는 과감하게 도입하고, 활용하기보다는
전체적인 아키텍처의 흐름을 이해하고 지식으로 쌓는것이 더 중요하기 때문이다.

앞으로 새로운 기술이나 새로운 패턴의 방법론을 내 프로젝트에 적용할때에는
조금 더 보수적인 관점에서 바라봐야 함을 느꼈다.

todo

•  Redux 설치 및 프로젝트 적용
•  Redux를 활용한 categoryGrid 상태 제어
•  Redux를 활용한 multiCategoryGrid 상태제어