혜르미온느

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

RecoilRoot recoil 상태를 사용하는 컴포넌트는 부모 트리 어딘가에 나타나는 RecoilRoot가 필요하다. 루트 컴포넌트가 RecoilRoot를 넣기에 가장 좋은 장소이다. import React from 'react'; import { RecoilRoot, atom, selector, useRecoilState, useRecoilValue, } from 'recoil'; function App() { return ( ); }​ Atom 아톰은 상태(state)의 일부를 나타낸다. Atoms는 어느 컴포넌트에서나 읽고 쓸 수 있다. 아톰의 값을 읽는 컴포넌트들은 암묵적으로 atom을 구독한다. 그래서 atom에 어떤 변화가 있으면 그 atom을 구독하는 모든 컴포넌트들이 재 랜더링 되는 결과..

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

리덕스 공식 홈페이지에 가면 이런 말이 있다. A Predictable State Container for JS AppsGet Started 바로 자바스크립트를 위한 예측 가능한 상태의 저장소라는 의미이다. 프로그램의 몸집이 커질수록 여러가지의 상태와 컴포넌트들이 생겨나고, 이들이 서로 유기적으로 얽혀있어 거대한 복잡도를 가지게 된다. 리덕스는 이러한 복잡성을 해소해주고, 상태들을 예측 가능하게 해준다는 의미이다. 1. 단 하나의 상태를 갖는다. 하나의 객체(store) 안에 프로그램에서 필요한 모든 상태를 넣는다. 2. 예고없이 상태값을 변경하는 행위를 사전에 차단한다. (읽기 전용이다) dispatcher/reducer를 통해서만 객체를 수정할 수 있으며, 스테이트 값이 바뀔 때 마다 각 상태 사용처..

프론트앤드 상태관리 라이브러리는 여러가지가 있고, 그 중 리액트 상태관리 라이브러리의 대표주자는 아마 redux가 아닐까 한다. 그 뒤를 바짝 추격하는 친구는 mobx. 하지만 리액트를 만든 페이스북에서 또 만들어준 상태관리 라이브러리가 있는데, 이름하여 recoil이다. 리액트를 만든 곳에서 리액트를 위한 상태관리를 만들었다니 얼마나 리액트 친화적으로 만들었을까? 실제 사용 경험은 mobx밖에 없지만 redux와 mobx 그리고 recoil의 차이를 정리해보려고 한다-! 참고로 2022년 2분기 기준 근 1년간 추세는 다음과 같다. 리덕스가 압도적이며, 보이지는 않지만 리코일이 미미하게나마 상승곡선을 그리고 있다. https://www.npmtrends.com/recoil-vs-redux-vs-mobx..