TOAST UI

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

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

현재 팀 내부에서는 시니어들이 팀 인력 채용 프로세스를 개선하고 있다. 프로세스 중에서도 현재는 필기시험 문제를 재출제하는 중인데 이게 생각보다 쉽지 않아 매일 매일 서로 의견이 분분하다. 그러던 어느 날 프리미티브에 대한 의견을 나누던 중 자바스크립트의 프리미티브를 객체 같이 사용된다고 설명해도 되느냐 안되느냐의 문제를 놓고 토론을 하게 되었는데 내 의견은 표면적으로 객체처럼 사용할 수 있기에 객체 같이 취급된다고 표현해도 된다는 의견이었고 다른 한 멤버는 중간에 프리미티브 래퍼가 관여하는 내용이기 때문에 그렇게 설명하면 안 된다는 것이었다.

웹 워드프로세서(이하 웹 워드)는 브라우저만 있으면 어디서나 문서 편집을 할 수 있다는 장점이 있어 매력적인 소프트웨어이다. 아직 네이티브 워드프로세서로 할 수 있는 모든 기능을 다 지원하는 것은 아니지만 가까운 미래에는 가능하리라고 믿는다. 2년 동안 웹 워드를 만드는 동안 가능성을 믿고 험난한 과정을 헤쳐 나갔고, 기능을 구현해 나갈 때마다 느꼈던 흥분과 희열은 아직도 강하게 남아있다. 이 글을 읽는 여러분 또한 그런 느낌을 받게 되기를 소망한다.

TOAST UI Editor는 2015년 3월에 첫 커밋이 이루어진, 대략 3년이 된 프로젝트이다. 2017년 12월 30일 이 프로젝트의 버전을 1.0으로 올리고 npm에 배포하기 위해 연말에 출근을 했었고, 당시 이 프로젝트의 저장소는 연말 사무실의 풍경만큼이나 한산했다. 3년간 정확히 160개의 github 스타를 받았었으며, PR은 기대하기 힘들었다. 이슈는 몇 달에 한 번씩 나타나 "이 프로젝트는 오픈소스야"라는 정체를 희미하게 알리는 정도의 역할을 하였다.

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

웹 워드프로세서(이하 웹 워드)분야는 생각보다 오래된 역사를 가지고 있다. 구글 독스가 2006년에 소개되면서 많이 알려졌으니 벌써 십여 년의 역사가 있는 소프트웨어 분야이다. 씽크프리는 자바 애플릿 기반으로 브라우저에서 구동되는 웹 워드를 표방했지만, 자바스크립트와 같은 웹 언어로 작성되지 않았기 때문에 웹 워드라고 보기는 어렵다. 네이티브 워드프로세서는 각 OS를 기반으로 독자적인 그래픽 툴킷과 C++이나 자바와 같은 프로그래밍 언어로 구현되어 있다. 반면에 웹 워드는 브라우저에서 구동되기 때문에 지원되는 브라우저만 있으면 어느 컴퓨터에서나 문서 편집을 할 수 있는 장점이 있다.

이번 글은 웹 컴포넌트 소개 연재 5번째로 웹 컴포넌트를 react처럼 코딩하기를 해보겠다. 사용하는 예제 전체 코드는 Todo Web Components에서 참조할 수 있다. 이 예제를 통해 지난 연재에서 알아보았던 커스텀 엘리먼트, 쉐도우 돔 그리고 lit-HTML]을 사용하여 웹 컴포넌트 애플리케이션을 어떻게 만들 수 있는지 확인해보자.

몇 해 전, 필자가 대학 졸업반일 때 웹 개발 과정은 두 가지의 기술에 초점을 두었다. 한가지는 기본적인 것들 즉, HTML과 CSS, 그리고 다른 한 가지는 Adobe Flash였다. 필자는 포트폴리오에 추가하기 위해 Action Script3.0로 사용자와 상호작용하는 웹사이트를 작성하는데 많은 시간을 들였다. 대학을 졸업한 뒤 몇 개월이 지나, 필자는 Flash로 고객의 웹사이트를 만들어 주었고 그것이 처음이자 마지막이었다. Flash는 죽어가고 있었다. 그리고 필자의 이력서나 포트폴리오에서도 사용하지 않게 되었다. 그것은 바뀌는 기술의 변화 속도에 대한 첫 번째 교훈이었고, 졸업 후 이제 막 실무로 뛰어드는 사람에게는 매우 두려운 깨달음이었다. 그 후 7년 후인 지금, 필자는 Microsoft Edge팀에서 디자인을 돕고, 필자가 느꼈던 불안감을 줄여줄 도구(Sonarwhal)를 개발한다.

지난 1년 6개월 동안 리액트, 리덕스를 공부하고 활용해 웹 애플리케이션을 개발했다. 지금도 개발하고 있고, 여전히 비동기 처리와 같은 사이드 이펙트(Side effects)를 고민하고 있다. 리액트, 리덕스는 함수의 응용, 순수 함수, 불변성 등 함수형 프로그래밍을 지향한다. 그리고 사이드 이펙트를 원하지 않는다. 하지만 세상일은 뜻대로 되지 않는다는 말을 증명하듯 서비스는 사이드 이펙트 없이 개발할 수 없었다. 사실 처음에는 사이드 이펙트라는 개념도 몰랐다. 그냥 무언가 개발에 어려운 점이 있는데, 그 무언가가 무엇인지 표현도 못 했다.