TOAST UI

필자는 처음 프로그래밍을 시작했을 때, 디자인 패턴, 파일구조와 같은 추상적인 프로그래밍의 개념과 중요성을 전혀 몰랐다. 하지만 호텔 관련 어플리케이션을 만들면서 그 중요성에 대해 알게 되었다. 어플리케이션의 주요 기능은 호텔 고객의 영수증 인쇄를 도와주는 것이었다. 1년 후, 호텔 경영진은 어플리케이션에 몇 가지 새로운 기능 구현을 요청했다. 불행히도, 기존 어플리케이션의 구조가 너무 형편없었기 때문에 어플리케이션 전체를 다시 작성해야 했다.

자바스크립트 코드 베이스가 다소 복잡하더라도, 배포(production) 모드와 개발(development) 모드의 코드를 다르게 번들링하고 실행할 수 있다. 배포 모드와 개발 모드의 코드를 다르게 번들링하고 실행시키는 것은 매우 강력한 기능이다. React의 개발 모드는 버그로 이어질만한 많은 부분을 미리 경고해주는 검증 코드가 포함되어 있다. 하지만, 이런 코드는 번들 크기를 증가시키고 앱 속도를 느리게 할 수 있다.

필자는 TOAST UI의 라이브러리 중 하나를 개발하고 있고 그동안 쌓은 경험과 노하우를 대방출하고자 한다. 이 글은 UI 라이브러리를 만드는데, 라이브러리의 목표와 기능, 사용한 기술 스택 그리고 웹팩 설정까지 바로 적용할 수 있는 실용적인 내용으로 구성하였다. UI 라이브러리를 만드는 방법과 노하우 A to Z를 알고 싶다면 노트북을 준비하고 차근차근 따라해보자.

유저들은 반응이 빠른 UI를 선호한다. 100ms 미만의 UI 응답 지연은 유저들이 즉시 느낄 수 있고, 100ms에서 300ms가 지연되면 이미 유저들은 상당한 지연으로 느낀다. UI 성능을 증가시키기 위해, React는 고차 컴퍼넌트(Higher Order Component, HOC) `React.memo()`를 제공한다. 렌더링 결과를 메모이징(Memoizing)함으로써, 불필요한 리렌더링을 건너뛴다.

React.memo, PureComponent 또는 shouldComponentUpdate 를 사용하지 않고 최적화하는 방법. 필자는 리액트의 리렌더링과 관련된 주제로 블로그 글을 준비하다가 당신이 감사할만한 이 작은 보석같은 리액트 지식을 발견했다. 이 글을 읽고 난 후, Brooks Lybrand는 이 트릭을 적용하였고 아래와 같은 결과를 얻었다. 흥미롭지 않은가? 그럼 인위적으로 작성한 간단한 예제를 보고 실제 앱에서 어떻게 적용할 수 있을지 이야기 해보자.

최근 React Native는 React Native for web을 발표하면서 또 하나의 플랫폼을 추가했다. Expo도 이에 발 맞추어 6월이 릴리즈된 SDK 33버전에서 Expo Web 베타 버전을 지원하기 시작했다. Expo Web은 모바일 웹을 구현할 수 있도록 해주고 PWA를 지원한다. React Native와 Expo가 제공하는 컴포넌트로 네이티브 앱을 개발할 수 있지만 웹에서도 같은 컴포넌트로 돌아갈 수 있게 만든 것이다.

자바스크립트의 객체와 함수가 참조형이라는 개념은 React의 성능에 직접적인 영향을 끼침에도 불구하고 많이 다뤄지지 않고 있다. 예를들어, 내용이 완전히 같은 함수를 두 개 만들더라도 두 함수는 절대 같지 않다. 다음과 같이 작성해보자. 다른 언어들을 사용해본 경험이 있다면 포인터라는 개념이 친숙할 것이다. 객체를 만들거나 기기의 메모리에 무언가를 할당할 때 마다 어떤 일이 일어나는 것일까?

이번 글에서는 Redux-Saga의 Channel(이하 채널)에 대해 정리해보고자 한다. 채널은 Redux-Saga의 초기 버전에서부터 고려했던 API는 아니다. 그런데 Stackoverflow에서 외부 이벤트를 Saga와 어떻게 연결하냐는 질문에서 채널의 필요성이 표면적으로 나타나기 시작했다. 핵심은 Push 기반과 Pull 기반 동작이다.

1부에서는 HOF(Higher Order Function)의 개념부터 시작해서 HOC(Higher Order Component)의 개념이 무엇인가와 어떤 상황에 이용될 수 있는지에 대해 알아보았다. 하지만 1부의 내용만 읽어서는 HOC를 실제 프로젝트에 어떻게 활용할 수 있는지에 대한 감이 잘 잡히지 않았을 것이다. 2부에서는 실제로 간단한 HOC를 만들어보고, 그 과정에서 발생할 수 있는 문제들과 이를 어떤 식으로 해결하는지, 그리고 지켜야할 컨벤션에 어떤 것들이 있는지에 대해 살펴보도록 하겠다.

지난 글에서 Redux-Saga와 사이드 이펙트를 가지고 공부 겸 정리 겸 글을 작성했다. 이번 글에선 Redux-Saga에서 사용하는 제너레이터함수, 이펙트에 대해 정리해보려 한다. 제너레이터함수는 협력적이고,run-to-completion이 아니며, 그렇다고 비동기도 아닌 그런 함수다. 그리고 이펙트는 Redux-Saga의 가장 중심이 되는 특징이다. 마치 Redux의 Action처럼 단순한, 일반적인 객체인데 개발자에겐 어마어마한 마법을 보여준다. 그리고 대부분의 서비스 로직을 이 이펙트로 작성한다. 이 두 가지를 이해한다면 이제 Redux-Saga는 뭔지 모르겠는데 엄청 대단해 보이는 것에서 엄청 대단한 건데 난 이해함ㅋ이 될거라 생각한다.