JBEE.io
JBEE.io copied to clipboard
react/thinking-about-global-state/
전역 상태 관리에 대한 단상 (stale-while-revalidate) | JBEE.io
이 글의 부제는 Stop Using Redux for Caching for API Response이다. 한 때 전역 상태 관리 도구로 Redux를 즐겨썼던 개발자로서 이제 더이상 Redux를 사용하지 않게 된 이유와 회고를 담은 글이다. Table of Contents 전역 상태 (Global State) Server cache UI state 다시 전역 상태 전역 상태 (Global State) 이 글의 대상 중 하나인 Redux…
정말 좋은글이네요! 잘 읽었습니다 :+1:
최근 관심가졌던 내용인데 정말 잘 정리해주셨네요. 감사합니다 잘 읽었습니다. 👍👍
이번에도 Jbee랑 비슷한 고민하고 있네요. react-query 검토하는 중
재밌게 읽었습니다 :) 감사합니다~!
잘 읽었습니다.👍 저의 경우에는 Next.js와 redux를 함께 사용하여 getInitialProps에서 데이터 패치를 실행하여 리덕스에 값을 저장하고 있는데요. getInitialProps자체가 페이지가 불러오기전에 await함으로써 리덕스에 데이터가 있음을 확인할 수 있었습니다. 불필요한 네트워크 호출을 줄이기위해 최신을 필요로 하지 않는 데이터에 대해서는 getStaticProps를 사용하여 응답값을 서버에서 JSON형태로 저장하거나, 'axios-extensions'를 사용하여 중복호출을 방지하는 등의 옵션을 사용 할 수 있었습니다. 저의경우 react-query혹은 swr은 SSR과 함께사용하기에 힘들어보였습니다.ㅠㅠ
좋은 내용 공유해주셔서 감사합니다.
@jerrynim 아 좋은 의견 감사합니다 :)
getInitialProps자체가 페이지가 불러오기전에 await함으로써 리덕스에 데이터가 있음을 확인할 수 있었습니다.
getInitialProps
가 호출되는 시점에 capture 된 데이터이지 않을까요? 그리고 인증이 필요한 http 요청에 대해선 한계가 있을 것 같은 방법이네요 ㅠㅠ 의견 공유 감사합니다!
아직 해보지 못했던 고민인데 먼저 고민해주시고 공유해주셔서 감사합니다 :)
좋은 글 작성해주셔서 감사합니다. 최근 전역상태로 관리해야할 관심사 부분에 대한 고민이 깊었는데 해당 글로 많이 해소가 되었어요!
애플리케이션의 특성에 따라서 전역 상태를 정의하기 나름이지만 이 이외에 일반적인 애플리케이션의 경우에는 전역 상태에서 관리할 상태는 없다고 생각한다.
애플리케이션의 크기가 커지면 커질수록 전역에서 관리해야 하는 상태는 없어진다.
여러 컴포넌트가 상태를 공유해야 하는 경우, 상태를 공유해야 하는 컴포넌트를 Provider로 묶어줘서 해결할 수 있다.
해당 문구에 공감이 많이 됩니다. 글에 나온대로 SWR이나 GraphQL과 같은 기술을 사용하면 네트워크 응답을 따로 관리해줄 필요도 많이 줄어든다고 생각이 들어요. 개인적으로도 애플리케이션이 커질수록 모든 상태를 전역상태로 관리해버리면 전역상태 관리에 필요한 리소스와 관리포인트가 너무 많아져서 지역적으로 관리하는게 맞다라는 결론이 들었습니다.
다시 한 번 좋은 글 작성해주셔서 감사합니다!
좋은 글 감사합니다~
Redux, 비동기처리, 전역으로 관리 모두 요즘 고민하던 주제인데 좋은 글 덕분에 인사이트 얻고 갑니다! 감사합니다~
필요에 맞게 사용하고 있었는지 되돌아보게끔 하는 글이네요. 좋은 글 감사합니다!
잘 읽고 갑니다. 리덕스를 걷어내면서 상태관리를 어떻게 할지 도움이 되었습니다!
최고입니다…
정말 글 잘 읽었습니다. 완독했어요... 특히 stale 관련해서 처음 알게되었어요..
아! 제목 "stale-while-revalidte"에서 revalidte 오타가 있습니당!