디자이너가 설계한 서비스의 플로우와 UI를 자연스럽게 구현하는 것은 프론트엔드 개발자의 중요한 역할입니다.이번 글에서는 motion (구 framer-motion) 라이브러리를 통해 다양한 시나리오의 UI를 구현해 보면서, motion 라이브러리의 주된 사용법을 간단히 살펴보고자 합니다.Motion 라이브러리에 대해아마 일부 프론트엔드 개발자들은 "framer-motion" 이라는 이름으로도 기억하실 "motion" 은 컴포넌트에 복잡한 애니메이션을 쉽고 선언적으로 부여할 수 있도록 도와주는 라이브러리입니다.라이브러리명이 "Framer-motion" 이던 시기에는 React만을 지원했으나 motion으로 리브랜딩된 지금은 Vue를 지원하고 있어, 앞으로의 예제들은 제가 주로 다루는 Vue를 기반으로 진행해보려 합니다.motion이 Vue를 지원하기 전까지는 @vueuse/motion 이라는 이름으로 Framer-motion과 ‘비슷한’ 기능을 제공하는 라이브러리를 사용할 수도 있었으나 React의 그것과는 꽤나 다른 문법으로 구현해야 했는데요,motion이 공식적으로 Vue를 지원하게 되면서 React에서와 Vue에서의 애니메이션 코드를 거의 유사한 방식으로 구현할 수 있게 되었습니다.Vue 프로젝트에서 motion을 사용하려면 라는 이름의 패키지를 설치해야 합니다.먼저 많은 내용을 효과적으로 표시하기 위한 UI 유형 중 하나인 Expand - Collapse 형태의 UI를 개발해 보겠습니다.이번에 만들 UI는 직무명을 선택하면 관련 설명이 나타나는 간단한 UI입니다.그런데 내용이 뚝뚝 나타나고 사라지는 것보다 약간의 애니메이션을 추가해 보면 어떨까요?먼저 Vue의 컴포넌트를 활용해 약간의 애니메이션을 부여해본 모습입니다.이번에는 Motion을 사용해 유사한 애니메이션을 구현해 보겠습니다.눈으로 보았을 때는 비슷하게 부드러운 화면이 완성되었지만, 내부의 코드는 꽤나 다른 모습을 띄게 됩니다.코드의 구조가 살짝 다른 것이 느껴지시나요?역시 Vue에서 제공하는 매우 강력한 기능이지만, motion을 사용했을 때의 장점도 분명합니다.• None 첫 번째 코드에서는 상태가 로 변할 때 영역에 max-height를 200px로 늘려주는 코드가 필요합니다.• None 그러나 motion을 사용하면 영역 내에서 컴포넌트 생애주기별로 적용할 애니메이션을 선언적으로 명시할 수 있고, ‘max-height’ 를 사용하지 않고도 ‘height’ 와 같은 discrete animated property 에도 애니메이션을 적용할 수 있다는 강력한 장점이 있습니다.이번에는 둘 이상의 요소가 있는 리스트에서 요소의 순서를 바꾸는 동작입니다.영상을 잘 보면 Before 영역의 A, B, C, D, E가 반전되고 있는데, 애니메이션을 적용하지 않아 티가 잘 나지 않습니다.요소들의 순서가 바뀌는지 잘 확인할 수 있도록 애니메이션을 부여해보고 싶은데요,GSAP 등의 애니메이션 라이브러리를 사용하면 순서가 바뀌는 애니메이션도 구현할 수 있겠으나 애니메이션 코드가 motio

안녕하세요. 에이닷에서 프론트엔드 개발자로 일하고 있는 스카이입니다.오늘은 사용자의 편의성을 위해 이탈 방지 팝업을 서비스에 적용하면서 했던 경험을 정리하여 글로 남깁니다.에이닷 회원 가입 과정에서 사용자가 실수로 페이지를 벗어날 때 입력한 정보가 유실되는 문제가 발견되었습니다.이 문제는 사용자 경험을 저해하는 중요한 이슈로, 이탈 방지 팝업을 통해 해결하고자 했습니다.가끔 사이트에서 아래와 같은 팝업을 마주하게 될때가 있습니다.앞서 보여드린 팝업을 노출 시키는 방법은 매우 간단합니다.beforeunload 이벤트를 추가하면 됩니다. 해당 이벤트는 페이지를 벗어나려고 할때 이벤트가 트리거 됩니다.그런데 이벤트 적용 했을때 다음과 같은 문제점이 있었습니다.페이지에 사용자 제스처(클릭/터치)가 없으면 이벤트는 트리거 되지 않습니다.이전 페이지와 현재 페이지의 도메인 주소가 다를때만 동작합니다.에이닷은 Vue.js 기반의 SPA(Single Page Application)입니다. 라우터를 기반으로 화면이 이동되다보니 상위 도메인 경로가 동일합니다.이럴때는 동작하지 않는 문제가 발견되었습니다.브라우저 고유 confirm만 사용 가능해당 이벤트를 사용하면 오직 각 브라우저에서 제공하는 형태의 confirm이 노출됩니다.이전에는 메세지 내용을 변경할수 있게 제공되었으나 현재는 메세지 내용을 바꿀수가 없습니다.onBeforeRouteLeave 이벤트는 Vue.js에서 사용하는 이벤트로 해당 페이지를 벗어나려고 할때 트리거 됩니다.이벤트 사 다음과 같은 문제점이 있었습니다.SPA 환경에서만 동작당연한 말이지만 라우터를 통하면 페이지 이동의 경우에만 발생합니다.의 발생 조건인 이전 페이와 현재 페이지의 도메인이 다른 경우에는 동작하지 않습니다.이벤트가 이벤트 보다 나은 점은 다음과 같습니다.beforeunload 경우 사용자의 동작이 있어야 이벤트가 트리거 되는 조건이 있었습니다.그러나 onBeforeRouteLeave는 사용자 동작 유무와 무관하게 이벤트가 트리거 됩니다.는 각 브라우저에서 제공하는 confirm만 사용이 가능합니다. 메세지 내용을 수정할수 없습니다.는 문구를 변경할수 있습니다. 또한 async/await 제공하는 confirm UI 만들어서 제공할수도 있습니다.에이닷은 다른 도메인을 통해 이동되는 경우와 라우터를 통해 이동되는 경우 2가지가 혼재 합니다. 그래서 두가지 경우를 모두 커버할수 있도록 구현했습니다.효과적인 이탈 방지 팝업 구현을 위해서는 기술적 제약을 이해하고, 다양한 시나리오를 고려한 유연한 접근이 필요합니다.Vue.js 환경에서는 라우터 이벤트와 브라우저 이벤트를 조합하여 최적의 사용자 경험을 제공할 수 있습니다.두 이벤트가 지원하는 브라우저

굳이 Svelte 를 선택한 이유왜 하필 Svelte 인가요? 아직 시기상조 아닐까요?Javascript 가 Web 표준 개발 언어기 때문에, 자연스럽게 해당 언어에 기반한 Web Framework (혹은 Library) 는 짧은 시간 내 굉장히 많이 생기고, 동시에 많이 사라지고 있는 것 같습니다.Web Framework 를 선택하는 것이 더욱 어려운 이유는, Frontend 분야의 트렌드가 다른 개발 분야에 비해 비교적 빠르게 변화하고 있기 때문입니다.실제로, 지난 10년 사이에 크고 작은 지각 변동이 수차례 있었던 것 같습니다.2010년대 초반에는 jQuery, 2010년대 중반에는 Angular, 2010년대 후반 이후에는 React 와 Vue 가 Web Framework 핵심 트렌드였던 것 같습니다.개인적으로는 대부분의 기간을 Frontend 분야와 친숙하게 지내지 않았기 때문에, 위와 같이 빠르게 변하는 Frontend 업계 트렌드를 그저 '옆동네 불구경' 정도로 생각했던 것 같습니다.막상 Web 개발 공부를 시작하려다 보니 꽤나 많은 선택지 앞에서 당황했고, 실제로 공부하고자 하는 Web Framework 를 선택하는 과정에서 많은 고민을 하게 되었습니다.현재 시점에서 Javascript 기반의 Web Framework 를 선택할 때, 가장 안정적인 옵션은 의심의 여지없이 React 혹은 Vue 입니다.Frontend 분야에서 이미 전세계에서 큰 비중으로 활용되고 있기에, 개발 안정성이나 확장 가능성은 보장되었다고 해도 무방합니다.실제로, Frontend 분야의 채용 시장도 모두 React, Vue 중심으로 열려 있고, 온라인과 오프라인 구분할 것 없이 대부분의 학습 자료는 해당 Web Framework 위주로 구성되어 있습니다.또한, 현실적으로 개발자들에게 굉장히 중요한 요소로 작용하는 커뮤니티 성숙도 측면에서 압도적인 모습을 보이고 있습니다.직면한 문제가 무엇이든, 대부분 Google 혹은 Youtube 에 이미 해당 문제를 경험하고 해결한 사례가 존재하기 때문에React, Vue 에 익숙하지 않은 개발자더라도 풍부한 Reference 를 통해 어렵지 않게 궁금증을 해결할 수 있습니다.심지어, ChatGPT 도 다른 Web Framework 와 관련된 질문보다는 React, Vue 와 관련된 질문에 보다 명쾌한 해결책을 제시하는 경우가 많습니다.처음 Svelte 를 접하게 된 계기는 '노마드 코더' 라는 유튜버의 Svelte 소개 영상이었습니다.Frontend 분야에 대한 기본 지식이 부족했기에, Svelte 를 추천하는 다양한 이론적인 (Virtual DOM 을 사용하지 않는다든가, 경량화 되었다든가, 실질적인 의미의 Reactive 특성이 구현된 형태다든가 하는) 강점보다는,초심자 입장에서 가시적으로 느낄 수 있을 정도의 간결한 Code 형태가 굉장히 매력적으로 다가왔습니다.이를 계기로, Svelte 라는 Web Framework 에 관심을 가지고 다양한 자료를 찾아보기 시작했습니다.하단에 첨부된 이미지와 같이, 20

안녕하세요. 오랜만에 인사드립니다.올 상반기에 에이닷 앱의 웹 뷰 서비스를 새로 구축하는 업무를 맡게 되었습니다.Nuxt.js 프레임웍(이하 Nuxt) 기반으로 빠르게 서비스를 출시 할 수 있었는데 그 이야기를 해보려고 합니다.에이닷 앱 웹 뷰는 2018년도 기술로 구축 된 레거시 프로젝트가 존재합니다.6년이라는 시간이 흐르는 동안 Front-End 진형의 기술은 크게 발전했습니다.기술 부채가 많은 레거시 프로젝트 위에서 서비스를 확장하려면 여러 불편함이 존재했는데, 이는 최신 기술을 사용하면 대부분 해결될 문제였습니다.바꾸고 싶다는 생각은 여러 번 했지만 시간과 자원이 많이 들어가는 일이라 결정이 필요했습니다.담당님의 지원으로 프로젝트 세팅, 빌드/배포, 서버 구축까지 새로 할 수 있게 됐습니다.현재 가장 인기가 많은 라이브러리는 React.js(이하 React)입니다. 그런데 왜 Vue.js(이하 Vue)의 Nuxt를 선택했을까요?가장 큰 이유는 "러닝 커브(Learning curve)가 낮다"를 이유입니다.저는 React로 4년, Vue로 4년 개발했습니다. React를 먼저 배우고 나중에 Vue를 배웠습니다. React의 개념이 있는 상태에서 Vue를 배우는 건 어렵지 않았습니다.양방향 바인딩의 개념을 이해하고 잘 사용할수 있으면 오히려 편하다는 느낌을 받았습니다.신규 프로젝트 세팅과 신규 서비스 출시 기간이 짧지 않은 상태에서 러닝 커브가 높은 React보다 낮은 Vue를 선택하는 게 맞다고 판단했습니다.또 React는 단방향 바인딩만 가능하기 때문에 부모 컴포넌트의 상태를 바꾸려면 handler를 구현해서 자식 컴포넌트에 props로 내려 줘야 하는데 이것은 props drilling의 고통을 가중합니다.Vue의 경우 양방향 바인딩을 지원하기 때문에 이를 깔끔하게 처리 할수 있다는 장점도 크게 다가왔습니다.React 생태계만큼 Vue도 디버깅 도구, 빠른 업데이트, Nuxt를 지원하고 있어 서비스를 운영하는데 문제가 없다고 판단했습니다.기존 레거시는 jQuery 라이브러리가 코어 모듈이었습니다.jQuery의 경험이 있는 분은 알겠지만, HTML 요소의 변경을 주려면 요소를 선택하고 제공하는 속성에 접근해서 값을 하나하나 변경해야 합니다. 정말 귀찮은 일입니다.데이터 기반의 라이브러리를 사용하면 데이터 변경 시 라이브러리에서 알아서 변경해 주기 때문에 불필요한 DOM 요소 조작이 필요 없습니다.아래 예는 Vue 방식입니다.아주 단순한 코드라 별 차이가 없다고 느낄 수 있으나 DOM 요소를 찾는 일을 100번 반복한다고 상상하면 크게 다가오실 겁니다.이 장점은 Nuxt의 장점이라기보다 Vue의 장점이지만 레거시 프로젝트와 비교해서 가장 큰 장점이라 먼저 이야기합니다.프레임웍의 장점은 수많은 논의 끝에 정규화된 규칙이 존재하고 사용자는 그 규칙에 맞게 세팅하면 자동으로 해결되는 게 많다는 점입니다.프레임웍을 사용하지 않고 프로젝트를 구성하려면 프로젝트의 구조, 사용할 코어 라이브러리, 폴더 이름 하나까지도 논의가 이뤄져야 합니다.프레임웍을 도입함으로써 결정의 시간을 줄일 수 있었습니다.빌드 설정은 자주 하는 게 아니다 보니 늘 복잡하고 헷갈립니다.Nuxt는 대부분의 설정을 알아서 해줍니다. 몇 가지 필요한 부분만 문서를 통해 이해하고 추가하면 되기 때문에 간편합니다.복잡한 Webpack 문서를 읽을 필요가 없습니다.Nuxt에서 제공하는 유틸리티 함수들이 있습니다.서버의 API 호출을 하려면 대게는 라이브러리를 사용합니다. Axios가 대표적입니다.Nuxt는 Ajax 호출을 할 수 있는 내장 유틸리티 함수를 제공합니다. fetch 함수인데 사용 방법이 간단합니다.개발하다 보면 필요한 모듈들을 import 해서 상단이 지저분해지는 경험을 했을겁니다.순서도 개발자마다 스타일이 달라서 논쟁이 되죠.nuxt는 특정 폴더의 파일들을 알아서 import 해주기 때문에 신경 쓰지 않고 개발할 수 있습니다.Nuxt로 프로젝트를 기본 틀을 설정한 후, 실무에서 필요한 몇 가지를 추가했습니다.Nuxt에서 제공하는 디렉터리 외에 필요한 디렉리가 있어서 추가했습니다.• None constants : 상숫값을 등록하는 디렉터리입니다.• None dto : DTO(Data Transfer Object)가 모여 있는 디렉터리입니다.• None type : 타입스크립트의 타입이 모여 있는 디렉터리입니다.• None stores : 서버 API를 호출하고 pinia를 사용한 상태 관리를 위한 디렉터리입니다.기존 레거시 프로젝트의 문제점 중의 하나였던 부분이 코딩 컨벤션이 제각각 달랐다는 점입니다.IDE 설정을 하지 않고, 코드 리뷰도 하지 않으면 코딩 컨벤션을 지키게 할 방법이 없기 때문에 이를 강제할 수 있는 수단이 필요했습니다.husky를 사용하여 git commit을 할 때 자동으로 prettier 검사가 되고 자동으로 수정 됩니다. prettier 맞게 수정해야 commit을 할수 있도록 강제했습니다.gitlab runner를 활용해서 MR(Merge Request)을 올리면 자동으로 eslint, test가 동작하도록 구성했습니다. 모두 pass 해야 MR을 Merge 할 수 있도록 강제했습니다.nuxt.config.ts 는 Nuxt의 설정을 세팅을 변경할 수 있는 파일입니다. 서비스에 적용하면서 몇 가지 추가한 내용을 남깁니다.아래와 같이 app 하위에 head에 들어갈 정보를 수정할 수 있습니다.server side rendering이 기본으로 true가 되어 있기 때문에 ssr 옵션을 false로 변경해 줘야 정적 파일로 빌드됩니다.서버 환경 구축에 따라 옵션을 설정하면 됩니다.신규 프로젝트를 구성하는데 어떤 라이브러리와 프래임웍을 사용할지 결정하는 것은 쉽지 않습니다.많은 서비스가 운영되고 있다는 사실을 알고 있지만, 실제 내 서비스에 도입할 때는 상황에 따라 고려해야 하는 부분이 다를 것입니다.이 글이 새로운 프로젝트를 구성하는 데 의사결정을 하는데 도움이 되었으면 좋겠습니다.