React query의 tracked-query와 개방 폐쇄 원칙

https://github.com/TanStack/query/pull/1578

Feature/use tracked query by TkDodo · Pull Request #1578 · TanStack/query

리액트 쿼리에는 tracked-query라는 기능이 있습니다.

우리가 해당 기능이 있는지 없는지 아는가에 관계없이, 좌측 구조분해 할당한 데이터만 컴포넌트에서 자동으로 구독하게 해주는 기능입니다.

const {data} = useQuery(...)

자세한 설명은 해당 페이지에서...

리액트 쿼리 : 렌더링 최적화

사실 원래 이 기능은 useTrackedQuery라는 훅으로 등장할 예정이었는데요,

해당 feature의 커미터는 해당 훅의 기능을 위해 trackedQueryObserver라는 클래스 또한 구현하였습니다.

 

즉 원래 설계에서는 useQuery가 아닌 다른 훅을 사용해야 했었는데요,

해당 설계는 다음 의견에 의해 바뀌게 됩니다.

https://github.com/TanStack/query/pull/1578#issuecomment-755145276

Feature/use tracked query by TkDodo · Pull Request #1578 · TanStack/query

해당 댓글 아래에서 zustand, jotai 라이브러리 창시자의 구현도 볼 수 있습니다.

1. 다른 훅 대신 옵션으로 기능을 확장할 수 있다.

2. 프록시 대신 Object.defineProperty로 간단하게 구현할 수 있다.

 

결괴적으로 바뀐 파일은 두 파일이 되는데요

새로운 기능을 위해 파일이 추가되는 형태에서, 기존 파일이 변경되는 형태로 설계가 바뀌었네요.

• types.ts (옵션 타입 추가)
• queryObserver.ts (publish, subscribe에 프롭 변경 여부를 반영하는 기능 추가)

쿼리의 변경사항을 관측한다는 관점에서 queryObserver에 해당 기능이 있는게 더욱 응집도 있는 것 같습니다!

---

개방 폐쇄 원칙

소프트웨어는 사용하는 곳의(API 컨슈머) 수정은 발생시키지 않으면서, 기능의 확장에 대해서는 열려있어야 합니다.

만약 기존 설계가 반영되어 useQuery를 useTrackedQuery로 변경해야 했다면,

해당 최적화의 장점을 누리지 못하는 사람들과, 해당 훅이 있는지도 모르는 사람들이 많았을 것입니다.

그리고 useQuery와 useTrackedQuery의 기능은 따로 갈 수도 있었겠지요.



제 생각에 변경된 설계가 더 나은 설계인 이유는 더 나은 수준의 일반화(옵션)를 달성했기 때문이 아닌가 합니다.

• 공통화 가능한 것은 최대한 공통화하고
  • 새롭개 생길 함수의 인터페이스가 거의 같기 때문에 공통화 할 수 있었던 것 같습니다.
• 인터페이스를 최대한 얇게 유지하고
  • ex) 리덕스. 작은 인터페이스로 기능의 무한 확장이 가능합니다.
  • 인터페이스는 알아야할 정보, API의 표면적이며, 기능은 부피입니다.
  • 표면적이 작고 부피가 클수록 좋은 API라 할 수 있습니다. (프로그래머를 위한 카테고리 이론에서 발췌)
• 특별한 경우 (useInfinityQuery와 같이) 편리한 전용 API를 제공하는것

이 좋은 설계가 아닌가 합니다.