혜르미온느

recoil은 몇 번 포스팅을 했었지만 사실 충분하게 이해하지 못했다. 거의 vuex만 써오던 나에게는 너무 생소한 스타일이기도 했고, 생각보다 레퍼런스가 많이 없었다고 핑계를 대본다... 하여 실무에서 리코일을 사용하며 애를 먹었고, 관련 작업을 할 때 너무 작아지는 기분이 들었다. 아직도 recoil은 어떻게 다루어야할지는 모르겠지만 공식 문서에 나온 todoList 예제를 보며 차분하게 따라해 볼 생각이다. ✔️ Recoil 테스트 환경 세팅 npx create-react-app 프로젝트명 npm install recoil ✔️ Recoil 사용 설정 단순 recoil 다운받았다. 사용시작! 이라고 하면 너무 좋겠지만 recoil을 사용하겠다는 일종의 세팅과정이 한 번 더 필요하다. recoil 상..

리액트를 위한 여러 상태관리 라이브러리 중에 recoil(리코일)이라는 친구가 있다. 리액트를 만든 페이스북에서 상태관리를 위하여 만든 라이브러리이기 때문에 가장 리액트친화적이고, 잘 이해된 상태관리 시스템이라고 이해할 수 있다. 그렇다면 굳이 라이브러리까지 설치하여 사용하는 상태관리가 왜 필요할까? 리액트의 한계성 리액트에서는 특정 상태를 공유하기 위하여 공통된 최상위 요소까지 끌어올려야 한다. 최상위 컴포넌트 -> 하위 -> 하위 -> 사용할 컴포넌트 와 같은 식으로 굳이 필요하지 않은 컴포넌트들을 거쳐 받아 사용할 수 있으며, 이 과정에서 트리 전체가 재 랜더링이되는 비효율성을 가지고 있다. 이에 따라 코드를 분할하고자 할 때, 직접적으로 상태가 사용되지 않는 컴포넌트라 하더라도 엮여있어 분할에 어..

프론트엔드를 접해보신 분들은 누구나 다음과 같은 고민을 해보신 적 있을겁니다. 상태관리 여기서 관리 대상인 상태란 무엇일까요? 개인적으로 고민했을 때에는 언제든지 변경될 수 있는 데이터를 '상태'라고 일컫는 것 같아요. 변경의 여지가 있으니 관리를 해 주어야 하는 데이터가 되니까요. 그럼 여기서 프론트엔드적 측면에서 관리해야하는 데이터는 크게 두가지가 있습니다. 서버 데이터와 클라이언트 데이터. 서버에서 받는 데이터의 특징 클라이언트와 다른 공간에서 관리되어짐 get/update 과정에서 비동기 API가 필요함 불특정 다수와 공유되는 데이터로 사용자가 의도하지 않은 변경들이 일어날 수 있음 클라이언트에서 받는 데이터의 특징 클라이언트 소유의 공간에서 관리되어짐 비동기적 API가 필요하지 않음 다른 사람과..