지난 8월 17일, 네이버에서 진행하는 사내 프론트엔드 컨퍼런스인 FE Devtalk에서 "디자인 시스템(개발편 2탄)"란 주제로 20회 행사가 진행되었다.
쏘카, 뱅크샐러드, 카카오 엔터프라이즈, 직방과 같은 인터넷 서비스 회사들이 자체적인 디자인 시스템을 어떻게 기획/디자인/개발/협업하고 있을까 라는 궁금증으로 시작된 이 주제는 3회에 걸쳐 진행되면서 그 이야기들을 풀어내고 있다.
이번 20회에선 코멘토, 코발트, 와디즈, 직방의 개발자들이 참여해 디자인 시스템 개발에 대한 경험을 공유했다. 아래 링크에서 발표들을 확인해 볼 수 있다.
- 17회 - 디자인 시스템(기획자, 디자이너 편) - 리디, 소카, 마이리얼트립
- 19회 - 디자인 시스템(개발편 1탄) - 다노, 뱅크샐러드, 카카오엔터프라이즈
- 20회 - 디자인 시스템(개발편 2탄) - 코멘토, 코발트, 와디즈, 직방
디자인 시스템을 실제로 만드는 디자이너의 입장에서 매번 고통스럽게 반복해야하는 작업이 많다.
이를 Zeplin과 tensorflow.js의 객체인식(Object Detection)을 사용해 문제를 해결했던 프로젝트에 대해 소개하고 있다.
Zeplin-ML라는 이 프로젝트는 스크린 디자인들에서 UI객체를 찾아주는 기능을 제공하며, 그것을 비교하기 쉽게 컴포넌트 라이브러리 화면들도 제공한다.
소프트웨어 개발을 하면서 우리들은 결과적으로 동일한 것을 수행하지만, 자신들의 것이 최고라고 홍보하는 수많은 라이브러리와 도구들 중에서 그들의 장단점을 비교하고 선택하는 과정을 거친다. 그러나 때때로 차별화 요소는 우리가 성취하고자 하는 것과 덜 관련이 있고, 단점들이 무엇인지 항상 명확하지는 않다. 이런 것들이 정말 중요한 것들일까?
한 번쯤은 다들 고민해 봤을 주제들인 MPA vs SPA, React vs Reactivity, VDOM vs No VDOM, Components vs Web Components 등의 논점들이 무엇이고 어떠한 점을 고려해야 할지 살펴볼 수 있다.
2000년대 RJS (Ruby-to-JavaScript)나 CoffeeScript 등을 통해 JavaScript가 아닌 다른 언어로 JavaScript 코드를 생성해 낼수 있게 되었고, 이후 2015년 ES6로의 발전을 통해 더 나은 JavaScript 코드를 작성할 수 있게 되었고, 최신 문법의 브라우저 지원을 기다릴 필요 없이 Babel이 미래의 최신 문법의 코드를 즉시 사용할 수 있게 만들어 주었다. 그러나 이는 공짜가 아니었고, 웹의 복잡성을 수반하게 만들었다.
오늘날의 웹 환경에서 transpiler나 번들링 도구가 꼭 필요한 것일까?
CSS 파일을 ESM과 같이 import 문법으로 로딩할 수 있게 하는 CSS module script 지원이 Edge와 Chrome 93에 추가될 예정이다.
import sheet from './styles.css' assert { type: 'css' };
document.adoptedStyleSheets = [sheet];
shadowRoot.adoptedStyleSheets = [sheet];보다 자세한 CSS Module Script에 대한 내용은 다음 링크를 참고하라.
Node V16.8.0이 릴리즈 되었다.
V16.6.0버전 부터는 Array.prototype.at 이 사용 가능하다. 더이상 array[array.length-1] 로 마지막 원소를 찾아갈 필요가 없다. array.at(-1) 이면 끝!
props가 바뀌지도 않았는데 자식 컴포넌트가 리렌더링되는 현상의 이유와 useMemo를 통한 해결과정을 알려주는 가이드이다. 의도치 않은 리렌더링으로 고생한 경험이 있다면 1독을 권한다.
컴포넌트를 라이브러리로 개발할 때에 Headless로 구현하면 어떤 점이 좋아지는지 그리고 어떻게 작성할 수 있는지에 대해 설명하고 있다.
여기서 Headless(또는 Renderless)란 컴포넌트 라이브러리에서 스타일을 담당하는 부분을 제외하고 상태와 관련된 부분만을 다루는 것을 말한다.
TypeScript 4.4에 추가된 기능에 대해 예시를 통해 설명한 글이다.
class에서 static 블록을 사용할 수 있는 기능이 추가되었다. 또한, 기존에는 Type Guard를 통해 해결했던 문제를 4.4에서는 "alias 된 조건문과 판별문 흐름 분석"을 통해 좀더 쉽게 타입 추론을 할 수 있다.
컴포넌트를 어떻게 나눌지 결정하는 것은 쉬운 일이 아니다. 이 글은 David Parnas의 1979년 “Designing Software for Ease of Extension and Contraction”에서 얻은 아이디어에 기초하여, 코드의 재사용성을 높이고 유지보수 비용을 줄이는 측면에서 어떻게 컴포넌트를 나눌 수 있을지 가이드라인을 제시한다.
자바스크립트와 웹 생태계의 부흥에 따라 수 많은 프레임워크가 등장했고 최근에는 React, Angular, Vue 3강 구도가 유지되고있다. 각 프레임워크 별 연봉은 어떻게 될까?
위 글에서는 자바스크립트 개발자의 연봉과 프레임워크 별 연봉을 서구권 국가 위주로 통계를 내서 정리해놓았다. (아쉽게도 대한민국의 통계는 없다.)
Flux 기반의 Redux, Vuex의 상태 관리 라이브러리를 Vanilla JS를 이용해서 만들어 가는 튜토리얼 문서이다. Observer pattern, 그리고 상태 변화를 인지할 수 있는 Object.defineProperty, proxy 등을 소개하면서 간단한 상태 관리 라이브러리를 만들어 볼 수 있다. 실무에서 상태 관리 라이브러리를 사용하기 전에 한 번씩 따라 해 보면 좋은 학습이 될 것이다.
React 앱을 PWA로 만들어가는 과정을 단계별로 서술한 튜토리얼이다. PWA를 만져보고 싶지만 어떻게 시작해야 할지 모르는 상태에서 글을 한번 따라 해 보면 PWA에 대한 이해를 높일 수 있을 것이다. 튜토리얼을 따라 하지 않고 PWA와 Service Worker에 대한 설명만 읽어보아도 PWA에 대한 감을 잡을 수 있다.
JavaScript를 더 어렵게 만드는 이상한 문법 25개를 풀 수 있다.
심심풀이로 풀어보고 실무에서는 이와 같은 혼란스러운 문법을 가급적 지양해야겠다.
React Suite는 기업용 제품을 위한 오픈소스 리액트 컴포넌트 라이브러리다. 좋은 개발 경험을 제공하는 데에 초점을 두었다. 링크와 같이 각 컴포넌트의 디자인 프로토타입과 명세도 제공한다.
Bootstrap이나 Material-UI와 같은 컴포넌트 프레임워크(또는 라이브러리)를 도입해 웹서비스를 개발하면 초기에 빠르게 서비스를 만들 수 있다는 장점이 있다.
하지만 컴포넌트를 커스터마이징을 하려고 하거나, 서비스가 발전해 자체적인 디자인 시스템을 구축한다고 했을 때 위와 같은 프레임워크의 도입이 부담이 될 수 있다.
그렇다고 하나부터 열까지 컴포넌트를 자체적으로 개발하는 것 또한 낭비적인 부분이 생긴다.
이를 해결해 줄 수 있는 솔루션이 바로 WEBRIX이다.
WEBRIX 는 <Movable/>, <Stackable/>, <Pannable/>, <Resizable/>, <Poppable/>, <Scalable/>, <Scrollable/>, <Collapsible/> 와 같이 기능적 부분에 포커스 된 컴포넌트들을 제공한다. 서비스 개발자는 컴포넌트의 presentaion 적인 부분만 신경 써서 개발하면 된다.
Web Audio API와 CANVAS로 audio리소스를 시각화하고 탐색할 수 있는 라이브러리다.
Windows XP 운영체제의 몇가지 기능과 간단한 앱들을 React와 hooks를 사용해서 구현한 프로젝트이다. 윈도우에서 친숙한 인터렉션을 어떻게 구현했는지 코드를 통해 살펴볼 수 있다.
이번엔 MacOS 운영체제다. Svelte로 작성되었다. 코드를 통해 MacOS의 인터렉션을 어떻게 구현했는지 확인할 수 있다.