설명하자면 좀 긴데.. (1) 태초에 React 가 개발되었고, '상태'를 통해 UI를 반영하게 되었음 (2) 문제는 순서보장이 중요한 '상태' 변경은 어찌 처리할거냐에 대한 부분에서 Flux Pattern이라는것을 발표함. 즉 임의의 데이터 컨트롤러를 하는 패턴. (3) Flux 개념 자체를 실용적으로 사용하기 어려워서, Redux라는 라이브러리로 쉽고 플랫하게 풀었음 (4) Redux가 은근 보일러플레이트가 많고, 코드가 난잡해지자 RTK라는 강하게 opinonated된 라이브러리를 만들었음. 여기까지가 Flux -> RTK 까지의 과정임.
익명(211.209)2023-10-05 15:04
답글
Flux/Redux/RTK는 데이터 흐름 컨트롤, 순서보장, 상태 관리 요런건 잘 함. 근데, React는 모든것을 '상태' 기준으로 그리려는 특징이 있음. 즉 너가 외부 데이터 (API)를 가져다 쓰려면 '상태'로 변경해놓고 적용해야된다는 말임. 근데 요 변환과정을 Redux로 처리하려면 매우 귀찮은게 있음. 그러니까, (1) 외부 데이터 fetching -> (2) 데이터 가져와서 상태 적용-> (3) 여기서 뭐 변환하든 뭐하든 지지고 볶고.. (4) 그리고 최종적으로 상태 적용 짠!.. (3), (4)는 전통적으로 Redux가 잘하는건데 (1),(2) 하려면 개지저분해짐.
익명(211.209)2023-10-05 15:07
답글
(1), (2)를 컨트롤 하기 위해서 React Query, SWR 같은 류의 라이브러리가 나온거고, Redux와 잘 버무려서 쓸 수 있도록 한게 RTK Query임.
그럼 (1), (2)는 RTK Query에게 맡기고, (3), (4)는 원래 Redux가 잘하는거니까 Redux보고 처리하라고 하면 됨.
RTK랑 RTK Query는 전혀다른 목적이 있다고 보면됨
설명하자면 좀 긴데.. (1) 태초에 React 가 개발되었고, '상태'를 통해 UI를 반영하게 되었음 (2) 문제는 순서보장이 중요한 '상태' 변경은 어찌 처리할거냐에 대한 부분에서 Flux Pattern이라는것을 발표함. 즉 임의의 데이터 컨트롤러를 하는 패턴. (3) Flux 개념 자체를 실용적으로 사용하기 어려워서, Redux라는 라이브러리로 쉽고 플랫하게 풀었음 (4) Redux가 은근 보일러플레이트가 많고, 코드가 난잡해지자 RTK라는 강하게 opinonated된 라이브러리를 만들었음. 여기까지가 Flux -> RTK 까지의 과정임.
Flux/Redux/RTK는 데이터 흐름 컨트롤, 순서보장, 상태 관리 요런건 잘 함. 근데, React는 모든것을 '상태' 기준으로 그리려는 특징이 있음. 즉 너가 외부 데이터 (API)를 가져다 쓰려면 '상태'로 변경해놓고 적용해야된다는 말임. 근데 요 변환과정을 Redux로 처리하려면 매우 귀찮은게 있음. 그러니까, (1) 외부 데이터 fetching -> (2) 데이터 가져와서 상태 적용-> (3) 여기서 뭐 변환하든 뭐하든 지지고 볶고.. (4) 그리고 최종적으로 상태 적용 짠!.. (3), (4)는 전통적으로 Redux가 잘하는건데 (1),(2) 하려면 개지저분해짐.
(1), (2)를 컨트롤 하기 위해서 React Query, SWR 같은 류의 라이브러리가 나온거고, Redux와 잘 버무려서 쓸 수 있도록 한게 RTK Query임. 그럼 (1), (2)는 RTK Query에게 맡기고, (3), (4)는 원래 Redux가 잘하는거니까 Redux보고 처리하라고 하면 됨.