간단한 블로그

의문 리액트의 훅은 deps값을 저장하고, 이전 값과 비교하여 변화가 있을 때 재실행(갱신)하도록 한다. deps 비교는 당연히 reference 비교라고 생각했기에 아무런 의심 없이 사용해왔다. 하지만 최근 IDE의 자동 완성을 이용해 deps 구문을 작성했을 때 의도했던 갱신이 이루어지지 않았다. 확인해 보니 deps에 등록된 객체의 필드가 문자열이었고, 객체가 변경되었지만 문자열 자체는 변하지 않았기 때문이었다. 이 참에 deps에 대해 짚어보자는 생각으로 리액트의 코드를 확인해 보고, 그 기록을 남긴다. 물론 이 글 역시 너무 오랫동안 글을 쓰지 않아 팀 메신저에 공유했었던 내용을 정리하여 다시 쓰는 글이다... React는 훅의 deps를 어떻게 비교하는가? 먼저 리액트의 코드를 직접 확인해 본..

의문더블클릭과 더블탭. 아주 흔하게 사용하고 핸들링하는 제스쳐 이벤트다. 그런데 생각해보면 이상하다. 클릭하고 또다시 클릭한다는 더블 클릭의 기준은 뭘까? 클릭과 터치는 기기에 따라 다른 이벤트로 구분하지만 이 글에서는 같은 동작에 대해 설명하려 하므로 더블 클릭으로 통일한다. 위키백과에서는위키백과에 따르면 더블 클릭은 움직임 없이 버튼을 두번 '빠르게' 누르는 것이라고 설명한다. 당연하게도 위키백과에 속도에 대한 부분도 있다. 기본 설정의 윈도우에선 500ms 안에 다시 클릭했을 때 더블 클릭으로 판단한다는 내용이다. 심지어 마우스 설정에서 속도를 변경하는 법에 대해 설명하고 있다. 하지만 웹 개발자에게 있어 os는 독립적이며, 브라우저라는 샌드박스 위의 동작에 대해 알아야 하니 다른 이야기이다. W3..

회사에서도, 개인적으로도 최근 진행한 프로젝트는 모두 Next.js를 사용하고 있다. 퍼블리싱을 맡는 부서가 나누어져 있지 않고 SEO와 관련된 문제를 해결하기 위한 것이 크지만, 한편으로는 리액트 진영의 라이브러리들로 편하게 개발하고자 하는 면도 있다. 하지만 Next.js를 사용해도 백엔드의 컨트롤러 부분, 그러니까 클라이언트의 요청을 직접 받는 부분을 개발하기 위한 해답이 명확하지 않다. 작은 규모의 프로젝트에서 서버간 통신을 구현할 때에는 Axios를 이용한 레이어링으로 충분하다. 하지만 API의 개수와 규모가 커지다 보면 Next.js에서 지원하는 api 폴더 내에 코드 뭉치를 욱여넣는 것으로는 부족해진다. 특히 API 엔드포인트들을 관리하고 타입 체크를 하는 것 자체가 엄청난 피로감을 유발한다..

BF캐시와 pageshowBack-Forward Cache. BF캐시는 SPA나 다이나믹한 웹 사이트 등 JS의 영향이 커지고 각 페이지의 '무게감'이 커짐에 따라 중요해졌다. 브라우저가 노출하던 페이지를 메모리에 그대로 유지해두고 다른 페이지로 이동함으로써, 사용자의 뒤로가기/앞으로가기 동작시 유지해둔 페이지와 그 상태를 그대로 노출하는 것이다. 간단하게 각 페이지를 스택 구조로 쌓는다고 보면 될 것이다.사용자 입장에서는 보던 페이지를 빠르게 볼 수 있고 하던 작업을 이어서 할 수 있으니 아주 좋은 경험을 할 수 있다. 특히 초기 동작이 느린 SPA기반 사이트에서는 더 큰 도움이 된다. 하지만 FE개발자의 입장에서는 이 BF캐시가 양날의 검이다. '느리다'는 말 대신 화면이 업데이트 되지 않거나(메모리..

최근에 '인클루시브 디자인 패턴'이라는 책을 읽었다. 아무래도 퍼블리싱-디자인에 가까운 내용이고 대부분의 사용자가 모바일 기기를 사용하며 제공하는 서비스가 아주 다이나믹한(그래서 이 책에서 자주 언급하는 스크린 리더와 전혀 어울리지 않는), 그리고 인터넷 속도의 저점이 매우 높은 우리나라에는 어울리지 않는 내용이 많았다. 하지만 그 중에서도 충분히 주의깊게 읽어 볼만한 내용들이 있었기에 그 내용들을 지금의 내가 가진 생각과 더불어 간략하게 적어두려고 한다. 인클루시브 디자인 인클루시브 디자인이란 타깃이 아니라고 생각되는 소수의 사용자, 그러니까 흔히 말하는 장애인, 고령자, 다른 언어를 사용하는 외국인 등이다. 따라서 우리나라에서는 당연하게 무시하는 스크린 리더 사용자를 포함한다. 이전 어느 웹툰 회사에..

정확한 이유는 알 수 없지만 Vue.js 2.x (3버전대로는 경험하지 못했으니)에서 v-디렉티브 사용시 SSR도중 DOM이 렌더링 되지 않는 현상이 때때로 발생한다. 내가 경험했던 케이스는 모두 vuex 데이터를 가공하는 computed 구문 내의 객체를 v-for 혹은 v-if에 사용했을 때 발생했다. 대략 2.3 ~ 2.4부터 경험했던 문제인데 2.7이 되도록 해결되지 않은 것으로 봐선 해결이 쉽지 않은 문제로 보인다. 이 문제는 정말 골치아픈 것이, computed로 처리하는 객체를 템플릿에 {{ object }} 구문 등으로 직접 노출시에는 데이터가 담겨있지 않지만, 라이프사이클에서 객체를 stdout으로 출력시에는 의도한대로 데이터가 담겨 출력된다. 심지어 data에 computed된 데이터를..

FE 개발자가 자주 사용하지만 직접 구현해보는 사람은 많지 않은 썸네일 서버 로직에 대해 정리한 글이다. 회사에서 팀 내에 공유한 문서였는데 쓰는 글이 없어 허전하길래 다시 정리해서 업로드한다. Thumbnail 썸네일이란? 트래픽 문제 → 용량의 문제 → 비용의 문제 사용자 경험 (UX) 증대도 있지만 클라우드 비용 감소에 있어 아주 큰 영향을 차지한다. 결국 사용자/제공자 모두에게 있어 비용 감소가 주요 목표라고 할 수 있음 최근 IOS에서도 webp가 지원되어 (webm은 아직) 많은 사이트에서 썸네일을 webp로 제공하는 추세 webp/webm: 구글에서 공개한 이미지 코덱(포맷)으로 webp는 정적, webm은 동적(gif) 이미지에 사용됨 대부분의 경우 용량을 아주 큰 폭으로 줄일 수 있지만 ..

컴포넌트에 대해 FE 개발을 할 때 제일 중요한 것은 컴포넌트다. 사실 거의 모든게 컴포넌트다. 막말로 컴포넌트를 대충 끄적이면 프로젝트 개발이 끝난다. 하지만 시간이 지날수록 생산성은 저하되고 심리적 부담감은 커진다. 유지보수와 개발을 진행하며 기능이 추가되고 변경되어 코드가 어려워지는 것은 어쩔 수 없지만, 최대한 그 시점을 늦추기 위해서 나는 아래 내용들을 고려한다. 컨텐츠를 기준으로 구조를 만들자 프론트엔드는 결국 기획과 디자인, 그리고 백엔드에 종속되어 있다. 특히 FE 개발자로서 가장 자주 충돌하는 대상은 기획자다. 그리고 기획자는 개발자가 아니다. 이 버튼을 저리로 옮기는 '단순한' 작업에 왜 그렇게 시간이 오래 걸리는지, 어렵다고 하는지 이해할 수 없다. 컴포넌트의 데이터가 어쩌고 저쩌고 ..

이직하기 전에 말해줬어야 하는 내 개인적인 의견에 대해 정리해봤다. 쓰다보면 별거 없을 거 같아서 다 쓰고 공유해줄지 고민해봐야 할 것 같다. 내가 대단한 사람도 아니고 흔한 개발자 중 하나에 불과하니 이 사람은 이렇게 생각하는구나 정도로 봐 줬으면 한다. FE 프로젝트에 대해 우리는 서비스를 유지보수한다. 개발은 쉽지만 유지보수는 어렵다. 왜 그럴까? 대부분의 경우 유지보수에 대한 생각 없이 개발하기 때문이다. 최근 몇 년 사이 급격하게 생태가 변했고(심지어 채용관련해서도), 상대적으로 룰이 정립되지 않은 프론트엔드에서 그 문제는 더욱 크게 다가온다. 만든지 몇 년, 아니 몇 달만 지나도 단순한 변경에 큰 리소스가 소모되기 시작한다. 나 역시 그리 많은 경험이 있다고 자신할 수는 없지만, 여러 프로젝트..

프론트엔드 프로젝트와 백엔드 프로젝트를 분리하여 개발하는 방법도 있지만, 개발 편의성 혹은 구조상의 문제로 합쳐야 하는 경우가 있다.이 글에서는 Spring boot 프로젝트와 Vue 프로젝트의 소스가 합쳐진 프로젝트를 생성한다.추가로 크롤링을 위해 Prerendering 플러그인도 적용한다. 1. 스프링 부트 프로젝트를 생성한다. Spring Boot 프로젝트를 생성한다 2. 뷰 CLI를 이용하여 뷰 프로젝트를 생성한다. 이 예제는 webpack-simple 템플릿으로 생성했다 3. 뷰 프로젝트 폴더에 만들어진 파일을 스프링 프로젝트로 이동한다. From (Vue project)To (Spring project)비고src./src/main/vue Index.html./src/main/resources/..