state management (7) 썸네일형 리스트형 리액트 디자인 패턴 : uncontrolled component pattern TL;DR uncontrolled component는 컴포넌트의 관심사를 달성하기 위해 스스로 내부 상태를 관리하는 컴포넌트입니다. 컴포넌트에 상태 관리 책임을 넘기고 편해지는 방법을 알아봅시다. 원문 번역입니다 : https://jjenzz.com/component-control-freak Are You a Component Control Freak? It's tempting to always control the components we implement but we can sometimes simplify things if we use the uncontrolled pattern. jjenzz.com 우리는 종종 컴포넌트의 상태를 직접 제어하려 합니다. 리액트 튜토리얼(React’s own intr.. 리덕스는 왜 단일 스토어를 사용하는가? TL;DR : 리덕스의 모듈화 단위는 스토어가 아니라 리듀서다 Dan Abramov의 답변 번역입니다 : https://stackoverflow.com/questions/33619775/redux-multiple-stores-why-not Redux - multiple stores, why not? As a note: I've read the docs for Redux (Baobab, too), and I've done a fair share of Googling & testing. Why is it so strongly suggested that a Redux app have only one store? I understand the... stackoverflow.com 여러 스토어를 사용해야 하는 극.. Remix로 알아보는 전역 상태 관리와 프론트엔드 개발의 미래 프론트앤드 애플리케이션의 미래, PESPA 아키텍처에는 전역 상태 관리 솔루션이 필요 없을 것입니다. js가 없어도 기본 기능이 동작해야 하기 때문이죠. 그런데 로그인 정보, 테마 정보 같은건 전역 상태로 어디선가 가져와야 하지 않을까요? 그런 정보는 어디서 가져오나요? PESPA의 구현체인 remix를 통해 해답을 찾아봅니다. PESPA의 상태 관리 솔루션 1. 웹 표준 : Form 리액트 라우터 6.4 이후 리액트 라우터에 Remix의 철학이 많이 녹아들어왔습니다. React 자체의 여러 상태관리 솔루션(useState 등)의 사용보다, 바닐라 JS와 브라우저 API, 웹 표준의 사용을 지향합니다.(#useThePlatform) 아래는 SPA에서 사용하는 솔루션인 리액트 라우터 코드지만, Remix와.. Remix의 데이터 플로우[Data Flow in Remix] Remix를 사용하면 상태관리 도구가 왜 필요 없는지 알아봅니다. TLDR : Action이 발생할 때마다 변경된 데이터를 Loader를 통해 Component에 반영해주면 되기 때문입니다. 해당 로직은 서버에서 동작하므로 동기화에 대해 걱정할 필요도 없습니다. 원문 링크입니다 : https://remix.run/blog/remix-data-flow Data Flow in Remix Remix takes the idea of “one-way data flow” and extends it across the network, so your UI truly is a function of state: from the client to the server and back again. remix.run React가.. 정규화된 상태 업데이트하기 [Managing Normalized Data][Redux][프론트엔드 상태관리] 원문 : 정규화된 데이터 업데이트 상태 정규화에서 언급했듯이 Normalizing State Shape 라이브러리는 중첩된 응답 데이터를 저장소에 통합하기에 적합한 정규화된 형태로 변환하는 데 자주 사용됩니다. 그러나 다른 곳에서 사용되는 정규화된 데이터에 대한 추가 업데이트를 실행하는 문제는 해결되지 않습니다. 자신의 선호도에 따라 다양한 접근 방식을 사용할 수 있습니다. 게시물의 댓글에 대한 변이를 처리하는 예를 사용합니다. 일반적인 접근 방식 (다른 상태 관련 라이브러리 없이 구현하기) 단순 병합 한 가지 접근 방식은 액션 내용을 기존 상태로 병합하는 것입니다. 저장된 항목을 업데이트하기 위해 항목의 일부가 있는 액션을 허용할 수 있습니다. Lodash merge 함수는 우리를 위해 이 일을 합니다.. [짤막글] 언제 context API를 사용하고 언제 zustand나 redux를 사용할까요? TLDR : (!트리_아래_업데이트 && context) || zustand 긴말 필요없이 아래 트윗을 인용합니다. (Tanner Linsley === 리액트 쿼리 메인테이너, 창시자) https://twitter.com/tannerlinsley/status/1293640999533568000?lang=en 트위터에서 즐기는 Tanner Linsley “I'm using #ReactQuery with Zustand and really liking the pairing. It's a super tiny, very flexible, no-nonsense client-state solution for React. If I were to write a client-state solution from scratc.. 언제 리코일을 사용하는게 좋을까? TL;DR : 캔버스나 GUI 같은 앱이 아니면 딱히 필요하지 않다. 프로젝트 초반에 리코일을 도입하기 위한 리서치를 진행하다 어쩌다보니 사용하지 않고 있는데요. 사실 생각보다 원하는대로 쓰기 어렵다는 것 외에도 (뒤에 이유를 설명합니다.) 전역 상태 관리 도구로서 에측하지 못한 하나의 단점이 있는데요. 반드시 데이터가 리액트 컴포넌트 내부에 존재해야 한다는 것입니다. 생각보다 개발하다보면 마이크로 최적화를 위해 렌더링 없이 상태 참조가 필요한 경우가 왕왕 있습니다. (useRecoilCallback을 활용할 수도 있지만, useCallback과 같은 문제가 있습니다.) https://recoiljs.org/docs/api-reference/core/useRecoilCallback/ 물론 ms단위의 미묘.. 이전 1 다음
