이번 호부터는 뉴스레터의 글들을 몇 가지 섹션으로 나누어 제공해 드립니다. 이는 독자님들께서 다양한 정보와 이야기들 사이에서 자신만의 관심사를 발견하고 탐색하는 데 작은 도움이 되었으면 하는 바람에서입니다. 표현 방식이나 다루는 영역은 다를 수 있지만, 모든 글 하나하나에 저희가 발견한 의미 있는 정보와 새로운 관점을 담기 위해 노력했습니다. 어느 부분을 읽으시든 구독자님께 유익한 영감을 드릴 수 있기를 바라며, 저희가 준비한 다양한 이야기들을 찬찬히 살펴보시면 좋겠습니다.

Beyond the Article: 한 걸음 더

React Context API는 사실 많은 렌더링을 야기하지 않는다..?

No, react context is not causing too many renders 🔗

React Context API에서 Provider를 컴포넌트로 감싸서 제공하면 너무 많은 렌더링을 야기하지 않는다는 취지의 글입니다. 하지만 React Context 정말 사용해야 하나요?과 비슷한 결이기도 하지만, 추가로 Provider로 감싸는 것은 물론 set함수(위 setValue)를 다른 Provider로 감싸주어야 set함수만 사용하는 컴포넌트에서 재렌더링이 발생하지 않습니다. 이러한 어려움을 뚫고 사용하는 것보다는 React Context는 상태관리 도구가 아님을 명심하여, 간단하게 사용하려면 use-context-selector나 zustand를 사용하는 것을 보통 권장드립니다.

React와 디자인 패턴과 원칙

React Hook Factory 🔗

React Context API를 Factory 패턴을 통해서 더 잘 사용할 수 있게 만드는 간단한 글입니다.

Dependency Inversion in React: Building Truly Testable Components · cekrem.github.io 🔗

React에서 의존성 역전 원칙을 어떻게 사용할 수 있는지 보여주는 간단한 글입니다. 비슷하게, 오픈소스를 만들면서 배운 점들에서 Tanstack Query에서 Inversion of Control을 적용해 어떤 좋은 점이 있었는지를 소개하고, 하나의 함수에 하나의 동작을 의미하는 SRP또한 React에서 컴포넌트할 때 적용해보는 경우도 있으니 참고하면 좋습니다. 하지만 첫번째 글에서도 나오고, 이전의 React와 SOLID 원칙 글에서도 소개했듯이, 과도하게 적용하면 개발자 경험과 유지보수성 모두 잃을 수 있기 때문에 경계해야 합니다.

RSC가 할 수 없는 것.

The Limits of RSC: A Practitioner's Journey 🔗

RSC의 기능으로 Infinity scroll을 구현하기 어렵다는 것을 깨닫고, Tanstack Query로 교체한 과정을 소개한 글입니다.

Client-Side React Rocks 🔗

클라이언트에서만 사용할 수 있는 Context, createPortal API…를 사용해서 때로는 클라이언트에서만 동작하는 로직이 필요할 수 있음을 보여줍니다.

두 글은 모두 RSC가 필요없음을 우리에게 시사해주고, 첫번째 글에서 RSC는 하이브리드 방식으로 일부에서만 사용하는 것이 좋다고 말하는 것처럼, RSC는 모든 경우에 다 필요한 것이 아니기에 필요한 곳을 잘 파악해서 사용해야 합니다. 저번에 소개한 RSC에 대한 글은 선택지를 넓혀주는 것을 보여준다면, 이번 글들은 모든 곳에 사용하지 않아도 된다는 것을 보여줍니다.

Airbnb의 마이그레이션 전략

Rearchitecting Airbnb’s Frontend. Overview: We recently rethought the… | by Adam Neary | The Airbnb Tech Blog | Medium 🔗

Airbnb에서 rail 방식에서 React 기반 SPA 방식으로 어떻게 마이그레이션 했는지 소개하는 글입니다. Airbnb는 일종의 Astro와 비슷한 방식(island같이 데이터를 받아오는 형식)의 전략을 썼지만, 다른 방식의 마이그레이션 전략 또한 있으니 참고하세요 :)