최근에 모노레포에 대한 생각이 많이 있었는데 어느정도 정리가 된 것 같아 글을 조금 끄적여봅니다. 어쩌면 역설적이지만 좋은 모노레포는 모든 코드를 한 레포에 모아두지 않는다.모노레포의 장점은 코드를 공유할 수 있다는 점이라고들 많이 알려져있습니다. 그러나 제 생각에 코드를 공유할 수 있는 것은 득이 되는 경우보다 실이 되는 경우가 훨씬 많습니다.모노레포는 코드를 공유할 수 있다는 특성으로 인해 코드간의 경계가 흐려지기 쉽고 이를 해결하기위해 모노레포를 위한 툴링과 정책이 필요합니다. 그러나 아무리 잘 세운 정책도 항상 강제되고 항상 준수되기는 어렵습니다. 이게 가능하려면 누군가는 큰 노력을 쏟아야하죠.더 큰 문제는 이 코드의 구획이라는 관점에서의 위기의식은 모노레포가 발전하는 초기단계에는 모두가 같은 ..
Animate Presence란?Presence의 사전적 정의는 "존재" 입니다. Framer Motion과 같은 애니메이션 라이브러리에서는 AnimatePresence 기능을 제공하는 경우가 많은데요 이 기능은 리액트의 동작 방식에서의 한계와 밀접한 관련이 있습니다. Dialog , Toast 등의 UI Interaction을 수행하는 컴포넌트를 직접 작성해본 개발자라면 이런 경험을 해봤을 것입니다. 등장 애니메이션은 문제없이 줄 수 있는데 퇴장 애니메이션을 주는게 불가능한 현상을 말입니다. Animate Presence는 이러한 문제를 해결하기 위해 퇴장 애니메이션을 적절히 줄 수 있게 만들어주는 기능입니다. 본 포스트에서는 Animate Presence가 필요했던 리액트 생태계의 배경과 Radix ..
1. 개발 역량을 쌓는게 진짜 중요한 일일까? 물론 개발자인 입장에서 아름다운 구조 , 견고한 테스트 코드, 읽기 쉬운 코드로 이루어진 프로젝트를 만드는 일이나 그러한 프로젝트를 만드는 방법을 학습하는 것은 매우 재미있는 일입니다. 그러나 그런 기술적으로 아름다운 프로젝트를 만드는 일이 곧 돈으로 직결되지는 않는 경우가 많습니다. 기술적으로 매우 큰 도전을 성공해낸 프로젝트보다 사람들이 필요로하는 프로젝트가 더 돈이 잘 될 확률이 높죠 코드를 아무리 아름답게 짜봐야 사용자가 아무도 없다면 그 코드는 가치를 창출할 수 없을 것 입니다. 그렇게 생각을 하고나니 개발 역량이라는 것 자체가 중요한것일까? 라는 생각이 듭니다. 제품을 잘 만들수 있는 "일정 수준 이상의 기술력"만 갖추어졌다면 그 이상이 필요할까요..
무언가를 결정할 때 데이터를 기반으로 결정하자는 방법인 데이터 주도 의사 결정은 꽤 중요한 의미를 가집니다. 무언가를 다른 사람들에게 설득하고 이해시키기 위해서는 주장 뿐만아니라 근거가 필요하죠 데이터는 그 자체로 근거가 되어준다는 점에서 조직의 의사결정을 투명하고 납득가능하게 만들어줍니다. 그 외에도 1. 성과 측정 2. 개선 방향성 탐색 3. 유저 페르소나 정의 등등 데이터가 있으면 그 데이터를 기반으로 여러가지 기획을 내놓을 수도 있고 개선 방향을 잡아나갈수도 있죠 이제 프론트엔드 개발자의 관점에서 이벤트 로깅을 생각해보겠습니다. 프론트엔드 개발자는 프로덕트의 최전선에서 사용자와 직접 의사소통하는 포지션을 가집니다. 사용자는 백엔드의 api와 직접 소통하는 것이 아니라 백엔드의 api를 적절하고 쉽..
😙 HighOrderComponent란? 고차 컴포넌트란 컴포넌트 로직을 재사용하기 위한 기술입니다. 리액트 문서의 정의에 따르면 고차 컴포넌트는 "컴포넌트를 가져와 새 컴포넌트를 반환하는 함수" 라고 해요 const EnhancedComponent = higherOrderComponent(WrappedComponent); 예제를 보면 다음과 같은데 구조만 보면 꽤나 익숙합니다. React에서 제공하는 forwardRef , memo와 같은 함수들의 사용형태와 같은데 redux의 connect 함수도 생각이 나네요 😇 횡단 관심사(cross cutting concerns) 이러한 고차컴포넌트 패턴은 리액트에서 횡단관심사를 통하여 로직을 바라볼 수 있게 도와줍니다. 이전에는 mixin을 사용하여 구현하였으..
🐁 퍼널 써보니까 좋은데..? 라이브러리로 한번 만들어보자 https://www.youtube.com/watch?v=NwLWX2RNVcw 위 영상에서 본 퍼널의 접근방식이 마음에 들어서 회사 서비스에도 간단하게 구현하여 적용을 해봤습니다. 적용을 해두고보니 DX가 매우 좋았어서 이것을 다른 프로젝트에서도 사용하고 싶어졌는데요. 한가지 사소한(큰) 문제가 있다면 구현이 next.js의 next/router 라이브러리의 useRouter훅에 의존하고있다는 것이었습니다. 즉 next.js 위가 아니면 돌아갈 수 없는 프로젝트라는 것이 가장 큰 문제였고 토스의 toss/slash 라이브러리의 구현에서도 next/router 라이브러리에 의존하고있는것을 확인할 수 있었습니다. 따라서 제 목표를 크게 next.js..
😚 이거 왜 필요한가요? 최근 팀 차원에서 jira를 도입하게 되었는데 기왕 사용하는 거 조금 더 편하고 잘 사용해보고자 개발 환경을 구성해보았습니다. 지라의 이슈는 이런 형태로 구성되어있는데요 이렇게 이슈를 생성하게 되면 자동으로 해당 이슈에 대하여 이슈번호가 할당됩니다. 이런 형태입니다. 여기에서 이슈번호는 WPA-91이 되며 이슈번호의 알파벳 프로젝트 차원에서 관리할 수 있습니다. 이렇게 만들어진 이슈는 이슈번호를 통해서 브랜치 , 커밋과 연동이 가능합니다. 하지만 그렇게 브랜치, 커밋을 연동하기 위해서는 깃허브와 지라를 먼저 통합하는 과정이 필요합니다. 깃허브와 지라의 통합은 Github for Jira 라는 앱을 통하여 할 수 있습니다. chrome에서는 무한로딩 -> 에러가 발생하는 문제가 있..
💫 이전글에서 내부 구현을 간단히 다루었습니다. https://xionwcfm.tistory.com/422 따라서 이번에는 위 구현방식을 참고해서 제가 필요한 기능만 뽑은 커스텀 useFunnel을 제작해보겠습니다. 사실 그냥 토스의 useFunnel 훅을 갖다쓰고 싶은 마음이 더 컸지만 사용에 꽤 많은 애로사항이 있어서 그냥 필요한 기능만 들어간 커스텀훅을 만들기로 했습니다. 토스의 구현 방식에서 얻을 수 있었던 인사이트를 나열해보면 다음과 같습니다. 1. nextjs의 shallow routing을 통해 뒤로가기를 구현하면서도 상태를 유지할 수 있다. (pages router에서는 쉘로우라우팅이 잘 지원되는데 앱라우터는 이슈가 많더라구요 앱라우터 쓰시는 분들은 참고하셔야겠습니다.) 2. 뒤로가기의 히..
