React -> Redux -> React Query 로 이어지는 변화속에서 React Query나 SWR 과 같은 방식에 대해 저자는 Widget Driven Develop 이라는 이름을 붙여서며

React -> Redux -> React Query 로 이어지는 변화속에서 React Query나 SWR 과 같은 방식에 대해 저자는 Widget Driven Develop 이라는 이름을 붙여서며 개념을 정리하고 있습니다. 간결하면서도 핵심만 잘 정리된 글이라고 생각합니다. React-Query 등은 이미 많이 알려졌지만 우리가 익히 알고 있는 내용도 좋은 이름을 붙이고 새롭게 개념화를 하면 훨씬 더 간결하게 바라볼 수 있기 공유드려봅니다. 요약한 내용과 함께 본문에서 제공하는 이미지들을 함께 보시면 훨씬 더 이해하시기 쉬우리라 생각합니다. 1 컴포넌트기반 개발의 시대 - markup, style, ui-logic 을 하나의 단위로 구성 - 재사용 가능한 고품질 부품 컬렉션을 만드는 것 2 누락된 것 = 백엔드로 부터 오는 Data Logic은 어떻게? - 컴포넌트에는 공유 Data를 다루는 지 않는다. - 컴포넌트간 데이터를 교환하는 것이 가장 어려운 일 3 해법1 - Data는 백엔드에서 온다. 각 컴포넌트에서 바로 백엔드와 통신하면 어떨까? => 데이터 교환 문제는 해결이 되나 서버과부화 데이터 중복 요청, 데이터 불일치 문제가 발생 => 캐싱에 너무 취약해짐 4 해법2 - Data만 주로 다루는 컴포넌트를 만들어서 공통 데이터를 뿌리면 어떨까? - 이것이 유명한 Container - Presenter 패턴 => 복잡한 컴포넌트 구조에서는 Prop Drilling Problem이라는 악명높은 문제를 만나게 된다. 5 좀더 나은 방식? -> 상태관리 접근 방식 - Container가 컴포넌트가 아니라 별도의 스토어로 관리하고 데이터를 전역적으로 관리한 후 데이터의 조작과 변경을 적절히 컴포넌트와 통신하자 => Prop Drilling 문제를 해결했으나 더 복잡한 상태관리 개념과 개발 방식을 가지게 되었다. 6 그러지 말고 데이터 로직을 컴포넌트안에 넣을 수는 없을까? - 컴포넌트에서는 해법1처럼 백엔드로 직접 통신하는 것처럼 사용하지만 API Wrapper가 존재하여 중복된 요청을 제거하고 캐싱을 과 데이터 불일치 문제를 해결해주는 레이어를 만들면 어떨까? => 컴포넌트 + Data 로직 = 위젯 결론 위젯은 독립적이며 데이터 로직을 더 쉽게 관리할 수 있습니다. 그리고 이러한 문제를 해결해주는 React-Query, SWR과 같은 라이브러리들이 존재합니다. 이러한 라이브러리를 활용하여 데이터 로직을 구성 요소의 제어 하에 두고 애플리케이션을 재사용 가능한 자체 포함 위젯 세트로 변환할 수 있습니다. 데이터 흐름이 투명하고 아키텍처가 유연하며 코드가 탄력적이며 테스트하기 쉽습니다.