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(리코일)이라는 친구가 있다. 리액트를 만든 페이스북에서 상태관리를 위하여 만든 라이브러리이기 때문에 가장 리액트친화적이고, 잘 이해된 상태관리 시스템이라고 이해할 수 있다. 그렇다면 굳이 라이브러리까지 설치하여 사용하는 상태관리가 왜 필요할까? 리액트의 한계성 리액트에서는 특정 상태를 공유하기 위하여 공통된 최상위 요소까지 끌어올려야 한다. 최상위 컴포넌트 -> 하위 -> 하위 -> 사용할 컴포넌트 와 같은 식으로 굳이 필요하지 않은 컴포넌트들을 거쳐 받아 사용할 수 있으며, 이 과정에서 트리 전체가 재 랜더링이되는 비효율성을 가지고 있다. 이에 따라 코드를 분할하고자 할 때, 직접적으로 상태가 사용되지 않는 컴포넌트라 하더라도 엮여있어 분할에 어..
- Total
- Today
- Yesterday
- Git
- 프론트앤드
- 리액트훅
- vue
- 프론트엔드
- sentry
- 센트리
- 리액트상태관리
- 깃명령어
- 리코일
- 김민태
- js
- 센트리모니터링
- javascript
- TIL
- gitRebase
- 자바스크립트
- react
- js테스트
- npm
- 리액트
- 크롬
- BFCache
- 사파리
- CSS
- 모바일사파리
- frontend
- storybookUI
- 깃
- reacthook
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |