Beyond the Article: 한 걸음 더

URL를 `State`로 가져오는 것은 제약이 많다.

Beware The URL Type-Safety Iceberg | nuqs 🔗

이전에 SearchParams는 State다. 하지만 type-safe한가?에서 소개한 nuqs의 메인테이너가, nuqs는 런타임 type-safe보다, "time-safe"에 집중하고 있음을 소개하고 있습니다. time-safe가 무엇인지, SearchParams를 상태로 가져오는 것에 어떤 제약이 있는지 친절하게 소개하고 있으므로, 꼭 보시길 바랍니다. 어쩌면, Tanstack router에게 보내는 글일 수도 있겠네요.

"리액트 상태"는 잘못 설계되었을까.

useState should require a dependency array 🔗

한 개발자의 useState에는 dependency array가 있어야 했다. Signal처럼 되었어야 하는데 잘못된 설계다.라는 것을 주장하고 있는 글입니다. 물론, 그에 반대되는 입장 또한 존재합니다(Signal을 React에서 쓰는게 좋은가?). Signal을 사용하려면 <For>과 <Show>같은 라이브러리에서 제공하는 태그를 사용해야 한다는 것에 Svelte가 겪은 단점을 그대로 겪을 수 있다는 것(Svelte 5의 명과 암)과 똑같은 일이 일어날 수 있음에 Signal을 사용하는 것을 경계하고 있습니다. 저 또한 Signal을 React에서 사용하는 것은 좋은 선택이라고 생각하지는 않지만, 사용은 자유니까요 🙂.

웹은 항상 발전되어왔다. 그렇기에 항상 주목해라.

Hacking Layout Before CSS Even Existed — Den Odell 🔗

어떻게 보면 "라떼는"의 글입니다. 하지만, 웹이 왜 이렇게 발전해왔는지, 그러므로 어떤 마음가짐을 가져야 하는가에 대한 에세이입니다. 하지만 최근 브라우저 회사에서 Baseline이라는 기준을 가지고 여러 방식으로 도움을 주고 있고(Polyfill을 언제 사용해야 할까), e18e같은 여러 단체(E18E가 뭔데)에서 오픈소스의 최신화에 여러 지원을 하고 있으므로, 항상 도구를 알맞게 사용하고, 프로젝트에서 어떤 제약을 갖고 있고 그에 맞게 어떤 기술을 사용해야 하는지 아는 것이 필요해보입니다.

제발 Node.js 버전 관리 좀 하세요.

Node.js — Beware of End-of-Life Node.js Versions - Upgrade or Seek Post-EOL Support 🔗

Node.js LTS는 1년동안 Active 상태가 되고, 1년 반동안 Maintenance 상태가 됩니다. 단순히.. Node.js의 버전에 관심을 가지지 않는 사람들이 많아 소개드립니다.

RSC에서 import는 어떻게 동작할까

How Imports Work in RSC — overreacted 🔗

자바스크립트에서 import와 모듈 시스템이 어떻게 동작하는지 설명하고, 이에 대한 문제, RSC는 어떻게 이를 대응했는지 소개하는 글입니다. 물론 이 import 'server-only'같은 구문을 싫어하는 사람들도 있지만(Server Components에 대한 리뷰), RSC에서 이렇게 구성한 이유를 설명해주므로, RSC를 왜 이렇게 설계했는지 이해하고 넘어갈 수 있을 것 같습니다.