디자인 시스템이 정말 필요한가요?
2024. 10. 25.
디자인 시스템이 정말 필요한가요?
디자인 시스템은 도입하면 편해지는 도구가 아니라 사내에 하나의 제품을 만드는 일입니다. 제품을 만드는 일인 만큼, 거대하고 다루기 힘듧니다. 위 두 개의 글은 디자인 시스템을 만드는 대신, 여러가지 대안을 제시합니다. 마지막 글은 디자인 시스템과 관련된 여러가지 정의를 명확하게 하고, 올바르게 만드는 방법을 제시합니다. 디자인 시스템은 이른 추상화일 수도 있고, 관리 포인트의 추가로 이어질 수 있음을 명심해야 합니다. 이외에도, Shopify에서는 디자인시스템에 대한 세 가지 사실과 디자인 시스템을 어떻게 다뤄야 하는지를 소개하고, Github에서는 디자인 시스템 구축 방법과 팀에 따라 어떻게 접근해야 하는지 소개합니다.
Web Components의 역사
심윤섭: Web Components에 대한 생각들에 이어서 Web Components의 시작과 React 방식 설계와의 충돌, 그리고 웹 플랫폼의 미래를 말하는 글입니다. Web Components를 집중적으로 말하는 글이지만, React의 설계 기반, 그로 인한 단점, 재미로 볼 수 있는 역사(Web Components와 함께)를 볼 수 있습니다. 글쓴이도 말하듯이 Web Components와 React는 장단점이 있으며, 웹 표준과 웹 환경은 앞으로 나아가고 있습니다. 외에도 Shadow DOM을 사용하지 않는 Web Components도 소개하고 있으니 Web Components에 대해 관심있는 분은 보시길 바랍니다.
RSC 또한 "폭포 요청 문제"가 있다.
심윤섭: 기존 SSR의 최상단에서 데이터 받아오기에서 RSC의 컴포넌트마다 데이터 받아오는 형식으로 변경 시에 서버 안에서 요청을 한번에 하지 않는다는 문제가 있습니다. RSC를 사용하지 않고 글에서 제시된 Remix의 loader 패턴을 사용하거나, Tanstack start처럼 클라이언트 중심 어플리케이션을 제공하는 방식도 있으니 RSC에서 혁명적인 기능이 추가되지 않는 이상, 장단점을 조율해야겠네요.
김대관: 컴포넌트 마다 데이터를 받아오는 형식으로 서버 안에서 데이터의 요청의 한번에 이루어지지 않고, waterfall 현상이 발생해 속도가 저하가 될 수 있다는 사실을 알게 된 글이었습니다. SSR의 주요 기능인 NextJS에서는 이런 waterfall 현상들을 없애기 위해 Promise.all을 통해 요청 처리를 하거나 렌더링 전략에 따라 해결하는 방법을 생각해야 합니다.
React와 dataset으로 재렌더링 방지하기
DOM에 직접 접근하여 dataset을 설정하는 방식으로 스타일을 바꾸는 방법을 소개합니다. requestAnimationFrame()을 사용하여 렌더링 블락을 막은 것은 눈에 띄지만, 설정한 요소가 재렌더링 되는 경우 초기화된다는 점과 DOM으로 직접 접근해 관리가 어렵다는 점은 고려하고 사용해야겠네요.
UI 라이브러리의 분류
여러가지 UI 프레임워크와 어떤 방식으로 추상화했는지에 따라 새로운 단어로 소개하는 글입니다.
Safari 크로스 브라우징의 역사
iOS의 Webkit 고정, 그리고 느린 버그 대응, 일부 주요 기능 미대응으로 크로스 브라우징이 어려웠던 역사를 소개하는 글입니다. 몇 가지의 기능은 아직 고쳐지지 않았다고 합니다. 주의해서 사용해야겠네요.
페이지 종료 컴포넌트에 Esc키 이벤트를 사용하지 않는 이유
Esc키를 세 번 누르는 이벤트를 사용하지 않고 Shift키를 사용한 이유를 적은 간단한 글입니다. Esc를 사용할 때의 접근성과 다른 단축키와 겹치지 않으려는 노력은 상기할만 하네요.
구현해보기
첫번째 글은 Drag로 여러 DOM을 선택하는 로직을 구현하는 법을 소개한 글이고, 두번째 글은 기존의 useReducer를 사용한 접근법에서 useActionState로 변경하면서 React 19에서의 Form 접근법을 알리는 글입니다. 세번째 글은 React Native 안 Webview에서 앱 알림 관리하는 가이드 글입니다.