티스토리 뷰

리액트를 위한 여러 상태관리 라이브러리 중에 recoil(리코일)이라는 친구가 있다. 리액트를 만든 페이스북에서 상태관리를 위하여 만든 라이브러리이기 때문에 가장 리액트친화적이고, 잘 이해된 상태관리 시스템이라고 이해할 수 있다.

 

그렇다면 굳이 라이브러리까지 설치하여 사용하는 상태관리가 왜 필요할까?

리액트의 한계성
  • 리액트에서는 특정 상태를 공유하기 위하여 공통된 최상위 요소까지 끌어올려야 한다. 최상위 컴포넌트 -> 하위 -> 하위 -> 사용할 컴포넌트 와 같은 식으로 굳이 필요하지 않은 컴포넌트들을 거쳐 받아 사용할 수 있으며, 이 과정에서 트리 전체가 재 랜더링이되는 비효율성을 가지고 있다.
    이에 따라 코드를 분할하고자 할 때, 직접적으로 상태가 사용되지 않는 컴포넌트라 하더라도 엮여있어 분할에 어려움을 준다.
  • context는 단일 값에 대한 저장만 가능하며, 여러가지 집합을 담기에는 한계가 존재한다.
    https://hyermione.tistory.com/79
 

[React Context Api] 리액트에서 데이터를 자유롭게 주고받는 법.

프론트앤드 개발을 하다보면 각 컴포넌트간의 데이터 교환을 해야하는 상황이 정말 많다. 가장 보통은 props로 하위 컴포넌트에 데이터를 전달해 주는 방식을 택할 것이다. 다만 전달하려는 데이

hyermione.tistory.com

 

이를 해결하고자 recoil은 독립적인 그래프를 생성하여 react 트리에 이식되는 개념을 가지고 있다. 즉, 자체의 순수함수를 거쳐 각각 사용이 필요한 리액트컴포넌트에 도달하며, 다음과 같은 특징이 있다.

recoil 특징
  • 리액트스러운 : 리액트처럼 작동하고 생각한다.
  • 데이터의 흐름 : 파생 데이터와 비동기 쿼리는 순수 함수와 효율적인 구독으로 관리된다.
  • 교차하는 앱 관찰 : 코드 분할을 손상시키지 않고 앱 전체의 모든 상태 변경을 관찰하여 지속성, 라우팅, 시간 이동 디버깅 또는 실행 취소를 구현한다.

 

recoil의 접근방식
  • 지역변수처럼 get/set의 인터페이스를 사용할 수 있도록 하며, 필요한 경우 reducer로 캡슐화가 가능하다.
  • 다른 react의 기능들과 호환성을 갖는다.
  • 코드 분할에 용이하다.
  • 상태를 사용하는 컴포넌트를 수정하지 않고도 변경된 상태 데이터를 보여줄 수 있다.
  • 상태 데이터는 동기/비동기 간의 이동이 가능하다.
  • 탐색을 취급할 수 있다.
  • 상태는 애플리케이션을 변경시에도 계속 유지될 수 있다.
 

https://hyermione.tistory.com/70

 

redux vs mobx vs recoil

프론트앤드 상태관리 라이브러리는 여러가지가 있고, 그 중 리액트 상태관리 라이브러리의 대표주자는 아마 redux가 아닐까 한다. 그 뒤를 바짝 추격하는 친구는 mobx. 하지만 리액트를 만든 페이

hyermione.tistory.com

 

 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/11   »
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
글 보관함