[오픈소스]CustomSwipe 개발 후기.

프런트엔드 swipe 기능의 경우 이미 swiper 같은 좋은 오픈소스가 많이 존재한다. 다만 swiper 같은 오래 관리되고 여러 기능을 지원해 주는 오픈소스의 특징상 커스터마이징에 적합하고 경량화되었다고 보기 힘든데 인터넷 환경이 좋지 않은 사용자들을 대상으로 지원할 swipe 기능에 대한 관심에서부터 시작한 react-custom-swipe라는 토이 오픈소스에서부터 개선점 및 아이디어를 추가해서 개발을 하다가 최종적으로 custom-swipe라는 오픈소스를 개발하게 되었다.

swipe라는 기능을 커스터마이징 가능하게 Headless Components라는 개념으로 제공하는 오픈소스이며 가벼움과 간단함, 커스터마이징이라는 3가지 특징에 중점을 두고 만들었다. 사실 가볍게 Toy느낌으로 시작해서 Toy느낌으로 끝나는 프로젝트다 보니 뭔가 거창한 내용은 없지만 기본적인 swipe 기능을 custom, light, simple이라는 3가지 개념에 충실하기 위해서 시간을 조금 들였고 지속적으로 오픈소스를 관리한다는 목적성을 가지고 있다 보니 지속적인 개선과 홍보 등을 해볼 생각이다.

 

https://github.com/yoonjonglyu/custom-swipe

GitHub - yoonjonglyu/custom-swipe: Swipe Headless Components

 

1. vue-custom-swipe.

아무래도 본인이 리액트를 중점적으로 다루다보니 리액트기반으로 개발한 기존의 react-custom-swipe의 경우 그냥 간단한 스니펫 수준의 코드였는데 개인적으로 한입씩 찍어 먹어보고 버리는 수준에서 멈추지 않고 남들한테 적극적으로 공개하고 사용될 수준까지 끌어올려서 정리하자는 생각으로 타깃으로 삼기에 적당한 프로젝트라고 생각이 들어서 버그 같은 걸 수정하고 사용성이나 코드 퀄리티를 리팩터링 하다 보니 swipe라는 기능과 react라는 라이브러리 등을 재정의하게 되었는데 swipe 기능 자체가 그 특징상 리액트에서 말하는 비제어 컴포넌트. 즉 dom을 직접 조작하는 방식으로만 작동할 수 있는 기능이라는 점이 사실 react와의 종속성이 없다는 것을 느꼈고 그를 리팩터링 하기 위해서 core라는 부분으로 따로 정리해서 패키지화했다. 그리고 core(swipe-core-provider)를 따로 구분하게 되면서 이걸 프런트엔드에서 자주 사용되는 라이브러리나 프레임워크 환경에 맞게 똑같은 기능을 한번 개발해서 맞춰보는 게 어떨까라는 생각이 들었다.

 

프로젝트 규모상 그 과정이 그렇게 어렵지 않을거라는 판단하에 몇 가지 후보군을 검토해 보았다. 프런트엔드 라이브러리나 프레임워크 생태계상 리액트와 거의 절반(실제로는 레거시 영향으로 아니지만)  차지하고 있는 vue, solid, angular, svelte 등을 후보군 삼았고 그중 리액트 다음으로 생태계가 큰 vue를 대상으로 삼았다. (사실 vue의 경우 swipe headless 라이브러리가 이미 많은 편이라 실용성은 별로 없다고 느꼈지만)

 

vue-custom-swipe의 경우 개발에서 큰 어려움은 없었는데 원래도 개인적으로 기존에 튜토리얼 수준의 간단한 앱을 개발해 본 전적이 있었고 vue3로 버전업이 되면서 변경된 부분들이 공식문서에 잘 정리되어 있었기에 공식문서를 한번 쭈욱 훑어본 후 필요한 부분들을 검색해 보는 걸로 충분했던 거 같다.

실제로 라이프사이클 자체도 리액트와 유사해서 그런지 조금 더 템플릿 엔진 느낌의 문법이라는 것. hook을 composable 같은 용어로 부른다는 점, (컴포지션 개념도 꽤 재미있어 보였다.) children 개념 대신 slot이라는 개념을 채용한다는 점 정도가 특이사항이었던 거 같다. 이 과정에서 필연적으로 vite 번들러를 처음 사용하게 되었는데 진짜 잘 만들어진 번들러 오픈소스라는 생각이 들어서 앞으로 뭔가 만들 때 webpack 대신 vite를 쓰는 걸 고려해 봐야겠다는 것 정도가 느낀 점들이다.

 

특히 개인적으로 vite의 lib 빌드 모드가 매우 인상적이었다. 웹팩에도 이런 기능을 만들거나 찾아보면 있을 수도 있겠지만... 원시인처럼 npm에 배포할 때마다 프로젝트 구성과 demo를 개별적으로 가져가던 입장에서는 이런 편리한 기능이!라는 느낌.

https://github.com/yoonjonglyu/custom-swipe/tree/main/packages/vue-custom-swipe

2.svelte-custom-swipe.

vue를 개발한 이후에는 모든 라이브러리나 프레임워크를 지원하는 것은 그다지 좋은 생각이라는 생각이 안 들어서 한 가지 프런트엔드 라이브러리를 선택해서 custom-swipe 패키지를 만들어보자고 결정하고 solid와 preact 그리고 svelte 사이에서 자료를 수집하면서 고민을 해보았다. 여러 검토과정이 있었지만 결과적으로는 평소에 관심을 가지고 있던 svelte를 그 대상으로 정하고 svelte-custom-swipe 패키지를 제작하기로 결정. 번들러로는 기존에 vue를 사용하면서 좋은 경험을 줬던 vite가 공식적으로 startkit으로 추천되길래 그대로 정하고 진행해 보았다. sveltekit을 기본으로 시작을 해서 그런지 svelte 자체는 기존에 홍보되던 매우 쉬운 난이도와 간단하고 가볍고 빠르다는 광고와는 사뭇 다른 느낌을 줬는데 기본을 ssr로 진행하다 보니 설정이나 빌드 과정에서 next.js 느낌도 났고 라이프 사이클이 존재하지만 실제 런타임에서 구동되는 코드와 빌드 전에 작성되는 코드 간의 격차가 크다 보니 소스 의존성이나 번들러 설정등에서 나름 에러사항이 있었다.

 

스벨트 자체가 쉬운 건 맞지만 기존의 react, vue 모던 프런트엔드 생태계를 기반으로 보았을 때는 조금 이질감이 드는 라이브러리라는 게 개인적인 체감이다. 작동원리 같은 게 비슷하면서도 다르기에 사실 vue에서도 느꼈지만 react가 jsx라는 바닐라 js느낌으로 uiux를 컨트롤하는 느낌이라면 vue는 반쯤 기존의 pug나 타임리프 같은 템플릿엔진에 가까웠고(문법이 다른 컴파일러) 스벨트는 8할 이상 템플릿 엔진에 가까운 느낌?

 

그래서 기존의 벡엔드 개발에 익숙한 사람이라면 이쪽이 오히려 더 편할 수도 있겠다는 생각이 들었다. vue도 비슷한 이유에서 벡엔드 개발자들이 react보다 선호하는 것으로 보이고 물론 개인적인 판단이니 정확하다고 단언할 순 없겠지만 벡엔드 개발자 특히 많은 자바 개발자들이 자바스크립트를 를 혐오한다는 점과 기존 기성 웹개발자들이나 모놀리스식 방식의 개발을 하는 사람들 입장에서 템플릿엔진 방식이 모던 SPA앱 개발보다는 익숙하니 그렇지 않을까?

https://github.com/yoonjonglyu/custom-swipe/tree/main/packages/svelte-custom-swipe

3.custom-swipe

그렇게 개발을 마치고 나니 문득 이런 생각이 들었다. 어차피 swipe기능 자체가 네이티브 dom을 조작하는

방식으로만 돌아간다면(순수한 프런트엔드 영역) 바닐라 js로 웹컴포넌트를 개발하고 그에 대한 타입추론 정도만 라이브러리나 프레임워크 별로 제공하는 게 낫지 않을까?라는 생각 그게 좀 더 간단하고 어디에서나 편하게 사용한다는 목적에 더 부합하지 않나라는 생각이 들었고 내가 개발하는 중인 디자인시스템을 HTML에서 제공하는 웹컴포넌트 표준으로 작성하는 것도 나쁘지 않지 않을까라는 생각이 들어서 실험적으로 web components라는 API를 사용해서 custom-swipe라는 순수한 바닐라 js 패키지를 하나 개발해서 custom-swipe라는 프로젝트를 통합해 보기로 결정했다.

이 과정에서 기존에 얕게 알고 있던 웹컴포넌트에 대한 학습이 필요했는데 MDN문서가 잘 정리되어 있다보니

그것에 많은 도움을 받았다. 실제로 예상했던바와 같이 웹컴포넌트 API를 이용해서 커스텀 컴포넌트를 제작하고 그것에 대한 타입추론만 라이브러리나 프레임워크 별로 따로 해주는 정도(타입추론이 아니라면 오류가 날 만한 상황이 없으니)는 크게 어렵지 않았고 그 과정에서 web components와 jsx 즉 js 기반 컴포넌트들의 차별점을 느꼈다.

 

js기반 웹컴포넌트들의 경우 html을 사용한다 할지라도 그 본질은 jsx 즉 자바스크립트 객체인데 웹컴포넌트의 경우 커스텀 컴포넌트를 제작할 경우 그를 사용할 때는 해당 컴포넌트는 본질적으로 HTML이고 아직까지 js와 연결해서 dom property를 확장하는 부분이 적어도 내가 아는 선에서는 없다는 것이고 그렇다 보니 간단한 javascript 함수나 객체등을 넘기기 위해서 custom events 같은 다른 수단을 사용해야 한다는 점이다.

이를 통해서 dom을 직접 조작하고 커스텀 이벤트를 핸들링해서 흔히 말하는 props를 주고받아야 하는 방식으로 진행되었는데 그게 아니라면 컴포넌트를 define 하는 과정에서 개입을 하거나 해야 하는데 그러나 사실 이건 웹컴포넌트 API가 추구하는 방향성에 맞다고 보기 힘들다. 굳이 비슷하게 하자고 한다면 define 하기 전에 기존 웹 컴포넌트 class를 상속받아서 새로운 컴포넌트로 해당 컴포넌트를 확장하는 방식으로 define 하는 방식이 더 적절하였다. (물론 이방식도 매우 제한적이다.)

 

즉 기존의 jsx와 다르게 js와의 연결성이 떨어지는 편이였다.

당연한 말이지만 HTML라는 중간 단계가 끼어있다 보니 어쩔 수 없는 점으로 보였고, 그로 인해서 복잡한 동작 수행이나 컴포넌트 확장성 자체가 제한적으로 느껴졌는데 정말로 순수하게 HTML 태그를 확장하는 정도의 수준의 컴포넌트들에나 사용할법하지 기존의 복잡한 웹앱의 컴포넌트를 대체하기에는 불편한 요소가 더 많다고 보였다. 웹컴포넌트 API 자체도 내부 라이프 사이클 콜백이 존재하지만 해당 콜백들이 args로 js 인자를 줄 수는 없었고 그나마 수월한 방식으로 내부적으로 커스텀 이벤트를 발생시켜서 해당 이벤트를 리스닝해서 외부에서 조작하는 방법 외에는 찾지 못했다. web components api보다는 custom elements api라는 이름이 더 적합하다는 게 개인적인 소감이고 간단한 UI의 경우 web components api를 사용하고 프로그램 자체는 기존처럼 jsx 기반으로 처리하는 게 더 적절한 전략일 거라 보인다.

https://github.com/yoonjonglyu/custom-swipe/tree/main/packages/custom-swipe

4. etc

기존에 정말 무성의하게 만들어 둔 데모버전을 정리해서 모바일 SNS 콘셉트의 UI로 다듬었고 간단한 스위치들을 제공해서 패키지 옵션들을 손쉽게 조작해서 확인할 수 있도록 개선했다.

https://yoonjonglyu.github.io/custom-swipe/

custom-swipe-demo

오픈소스로 사용자를 유인하기 위해서 기본적인 브랜딩을 해야겠다는 생각이 들었고 그를 위해서 무료 디자인툴의 도움을 받아서 로고 이미지를 제작했다. (canva라는 서비스를 활용)

https://www.canva.com/ko_kr/

스와이프 브랜딩 로고

 

또한 CHAT GPT의 도움을 받아서 README 내용을 작성해 보았다.

마찬가지로 chatgpt를 통해서 작성할 예정인 미디엄 블로그 소개글이 있는데
그 외 코드 리팩토링등 어느 정도 정리가 끝난 후 이를 해외 개발 커뮤니티에 소개해서 홍보를 진행해 볼 예정이다. 애초에 이런 식으로 홍보를 한 적이 처음이라 잘될지는 모르겠지만 ㅎㅎ

개인적으로 chat + chatgpt SDK로 오픈소스 및 saas를 기획 중이다 보니 이를 통해서 좋은 레퍼런스를 얻을 수 있길 기대해 본다.

 

#깃허브링크

https://github.com/yoonjonglyu/custom-swipe

GitHub - yoonjonglyu/custom-swipe: Swipe Headless Components