react-query 즉 Tan Query 를 통해 서버 상태를 선언적으로 관리하여 많은 문제 해결을 할 수 있습니다. 아래와 같은 시나리오를 가정해보죠. 현재는 리덕스 툴킷을 사용하여 프론트 측의 전역 상태에 스키마를 정의하고 정규화를 수행하면서 채팅앱을 구현하였습니다.로그인한 내가 있고 나는 프로필 이미지와 성별, 닉네임, 이미지들, 게시물들, 등등의 정보를 가집니다.일대일 채팅방은 채팅방 아이디, 마지막 메시지 타입, 마지막 메시지 내용, 채팅방 참여자 두명의 정보, 읽지 않은 갯수 등의 정보를 가집니다.채팅 메시지는 아이디와 타입, 내용, 보낸사람 아이디, 보낸사람 닉네임, 받는사람 아이디, 받는사람 닉네임, 채팅방 아이디 등의 정보를 가집니다.게시물은 아이디, 제목, 이미지, 작성자, 좋아요 ..
react-query 는 서버 리소스 기준으로 fetching 하고 상태관리 하는 라이브러리라고 보면 되겠죠? 간단하게 사용할 때는 유용할 거 같긴한데 redux, thunk 조합 보다 유연성은 떨어질 거 같은데 또 redux-persist 같은거 사용도 안 될 거 같고, 두개를 동시에도 많이 사용하시나요?저는 개인적으로 그냥 올라운드라 커버 가능한 redux, thunk 조합을 사용하는게 일관되고 유연성이 있어서 더 좋아보이긴 하는데요.. 그럼 redux, thunk 기본 조합에 캐싱? 그런 기능 필요시 그에 맞게 추가해야겠죠? react-query 는 그냥 그 자체만으로 따로 취급해야 하는거겠죠? redux, thunk 방식에 react-query 를 연동한다던가 하는 그런 성격의 것은 아닌거죠?만약..
자꾸 한번씩 의심을 하게 된다. redux 대신 좀 더 쉽게 사용할 수 있는 전역 상태 라이브러리는 없는가에 대해서... 하지만 다른 것들은 쉬운게 아니라 기능이 없는 것이다. redux 가 아직까지는 제일 낫다. 그러나 recoil 은 아직 experimental 인데 이 경우는 아직 잘은 모르겠고 (왜냐하면 리액트 팀의 공식 라이브러리이니깐...) constate 라던가 뭐 이런건 그냥 거의 contextAPI 와 hook 를 사용한 단순한 라이브러리 정도여서 그냥 기능이 없을 뿐이지 심플한 것이 아니다. React 의 useState, useReducer 같은 거 사용한 contextAPI 와의 조합 정도... 전역 상태는 redux-toolkit 이 현재로서는 최고의 선택. flux 패턴의 구현체..
정리해보면 nextjs + react-query + redux-toolkit + rtk-query + react-hook-form + yup 의 구성이 좋다. SSR 이 아니라면 CRA (create-react-app) 로. SSR 이면 CNA (create-next-app) 로. 물론 모두 typescript 를 적용. React-Query, RTK-Query, SWR 등은 요청 캐싱용 라이브러리이지 리액트에서 말하는 컴포넌트의 상태, 리덕스의 전역 상태와는 관련이 없다. Hook 와 단일자원(웹소켓이라던가 DB 라던가)의 조합은 마치 전역 상태와 같은 늬앙스를 줄 수 있는데 이는 Hook + 단일자원 이 원래 그러한 역할을 할 수 있기 때문이다. 이것이 늬앙스가 비슷하다하여 마치 리덕스 전역 상태를 ..
React 의 훅 그리고 Context API 에 대한 추상적인 고찰. React 훅은 마치 javascript 의 클로저 처럼 함수가 하나의 실행 영역을 가지는 것과 유사하게 파라미터를 받을 수 있고(마치 리액트 컴포넌트의 속성과 같이) 내부에서 사용될 수 있는 변수들이 존재하며 상태(state)와 동작(method) 을 가지는 기능 단위이다. 보통 하나의 기능 단위는 상태와 동작으로 정의될 수 있다. 그리고 함수형 프로그래밍 방식에서 추구하는 확실한 기능 단위의 조합 방식에도 부합한다. 리액트는 UI 라이브러리이며 그 기본 단위인 컴포넌트는 생명주기, 렌더링 관련된 기능과 속성, 상태, 동작과 같은 것을 가진다. 훅이 나오기 전 클래스 형 컴포넌트를 주로 사용하던 시기에 단순한 독립적인 유틸리티 함수..
redux.js.org/style-guide/style-guide#reducers-must-not-have-side-effects Redux Style Guide [필수] * 상태를 Mutate 하지 말 것. * 리듀서는 Side Effect 를 가지면 안된다. - ajax, timeouts, promises, random, date.now, 리듀서 밖에서 관련 변수 수정 x, 리듀서 밖에 영향을 줄 수 있는 코드가 리듀서 함수에 있으면 x * Non-Serializable 값이 상태나 액션에 있으면 안된다. - Promises, Symbols, Maps/Sets, funtions, class instances 와 같은 것들이 Redux store state 나 dispatched action 에 있으면..
toolkit-saga https://velog.io/@suyeonme/React-Redux-toolkit에서-미들웨어-사용하기 toolkit 설명 https://kyounghwan01.github.io/blog/React/redux/redux-toolkit/#종합-예제 rn 과 toolkit 관련 블로그 https://post.naver.com/viewer/postView.nhn?volumeNo=29438367&memberNo=10070839 redux-toolkit 사용하면 combineReducer 와 devtools 를 사용하지 않아도 이미 적용되어 있다. 하지만 configureStore 에 devTools: process.env.NODE_ENV !== 'production', 이런 옵션으로 넣..
redux toolkit 과 함께 사용하기에는 rtk-query 가 더 좋아보인다. rtk-query-docs.netlify.app RTK Query - Powerful data fetching and caching for Redux | RTK Query RTK Query is an advanced data fetching and caching tool, designed to simplify common cases for loading data in a web application. rtk-query-docs.netlify.app github.com/klis87/redux-requests klis87/redux-requests Declarative AJAX requests and automatic net..
가장 기본적으로 javascript 의 기본 Error 객체의 구조는 다음과 같다. new Error() 해보면. message, name, code 정도가 있다 실제로는 message 와 name 만 있다. name 은 기본 Error 이고 message 는 기본 '' 이다. 리액트에서 에러 처리에 대한 고려는 곧 redux 를 사용할 것인가 라는 고려까지 하게 만든다. 그래서 전체적인 구성에 있어서 큰 영향을 미치는 사안이다. 리액트의 useState, useEffect, useContext, useMemo, useCallback, useReducer 등과 같은 훅과 함께 react-redux 의 useDispatch, useSelector 훅은 너무나도 보편적으로 잘 사용되고 있기에 리덕스를 사용하..
기존에 약간 애매했던게 immutable 은 객체변화 감지를 단순화하게 하기 위해서 하는 목적도 있는데 그럼 store 가 매번 immutable 하게 갈아치워지는건가? 생각했었다. 하지만 그런 것이 아니라 redux 구현체의 원리를 보니 reducer 마다 합쳐서 combine reducer 를 해서 각 reducer 단위로 state 라는 녀석의 변화 감지를 하도록 되어 있다고 한다. 결국은 store 는 하나의 상태 저장소 라는 개념이고 단일 책임 원칙과 각 리듀서들을 통합해서 단순화한 하나의 상태 저장소라는 개념이다. 따라서 불변성이 지켜져야 하는 부분은 store 의 state 즉, reducer 마다 할당된 state 들 각각이 immutable 해야 한다. NGRX 는 service 단을 두..