개발 이야기
React에서 우아한 닫기 애니메이션 구현하기 - useExitAnimation 훅 만들기
React에서 우아한 닫기 애니메이션 구현하기 - useExitAnimation 훅 만들기
2024.08.24React에서 팝오버나 모달 같은 컴포넌트를 만들 때, 사용자 경험을 향상시키기 위해 부드러운 열고 닫는 애니메이션을 적용하는 경우가 많습니다. 하지만 열고 닫음을 상태(state)로 관리할 때 닫기(Exit)에 애니메이션을 적용하는 것은 생각보다 까다로울 수 있습니다.이는 컴포넌트의 존재 여부를 상태로 관리할 때 발생하는 문제인데요. 상태가 "닫힘"으로 변경되면 컴포넌트가 즉시 언마운트되어, 애니메이션을 적용할 시간이 없기 때문입니다.function PopoverContent() { const { isOpen, ... } = usePopoverContext(); // 컴포넌트가 바로 사라져 애니메이션이 적용되지 않는다. return ( {isOpen && ( ..
Polymorphic Component를 만들어보자(ft.타입스크립트)
Polymorphic Component를 만들어보자(ft.타입스크립트)
2024.08.04이번 글부터 많은 분들이 주신 피드백을 반영하여 글의 스타일을 변경해 보았습니다. 앞으로도 더 나은 방식으로 도움이 되는 내용을 전달하기 위해 노력하겠습니다. 감사합니다.안녕하세요. 최근에 헤드리스 컴포넌트를 개발하면서, 비즈니스 도메인과 상관없이 재사용 가능하고 유연하게 확장할 수 있는 UI 컴포넌트에 대해 많은 고민을 하고 있는데요. Polymorphic Components(다형성 구성요소)는 호출하는 쪽에서 해당 컴포넌트의 시맨틱 요소를 결정할 수 있게 하는 React 패턴으로, UI 컴포넌트의 재사용성을 높이는 데 매우 유용한 기술이기 때문에 소개해드리고자 합니다. 특히 타입스크립트와 함께 사용하면 안전하고 쉽게 Polymorphic Components를 구축할 수 있어서, 재사용과 확장성이 용이..
복잡한 애플리케이션을 위한 프론트엔드 아키텍처
복잡한 애플리케이션을 위한 프론트엔드 아키텍처
2024.07.20프론트엔드가 점점 복잡해지면서 프론트엔드 코드베이스를 아키텍처 수준에서 구조화하고 관리하는 것의 중요성이 점점 높아지고 있다. 필자도 이 주제에 대해 굉장히 오랫동안 고민해 왔는데, 특히 백엔드와 달리 프론트엔드에는 3-계층 아키텍처나 클린 아키텍처와 같은 정형화된 아키텍처가 없었기 때문이다. 물론 프론트엔드와 백엔드는 소프트웨어의 본질적인 내용을 공유하기 때문에, 여러 아키텍처의 핵심 논리를 프론트엔드에도 충분히 적용할 수 있다. 하지만 프론트엔드의 특수성 때문에 백엔드 아키텍처를 그대로 적용하기는 어려울 뿐더러, 비효율적이다. 따라서 핵심 논리를 기반으로 프론트엔드만의, 그리고 해당 프로젝트의 복잡성을 고려한 아키텍처를 구축하는 것이 가장 현실적이고 효율적인 방법일 것이다. 이번 포스팅에서는 필자가 ..
프론트엔드 렌더링 패러다임의 변화와 의미(ft. RSC, Streaming SSR, PPR)
프론트엔드 렌더링 패러다임의 변화와 의미(ft. RSC, Streaming SSR, PPR)
2024.07.09렌더링 패턴은 DOM을 언제, 어디서 생성할지를 결정하며, 선택된 전략에 따라 사용자 경험에 직접적인 영향을 미치기 때문에 프론트엔드 개발에서 매우 중요한 요소이다. React와 같은 현대 웹 라이브러리의 등장으로, 프론트엔드의 렌더링 방식은 많은 발전을 이루었다. 최근 렌더링 패턴의 발전을 지켜보며 가장 크게 느낀 점은, 렌더링 단위가 페이지 수준에서, 컴포넌트 수준으로 변화하고 있다는 것이다. 사실 프론트엔드 개발이 페이지 단위에서 컴포넌트 단위로 전환된 지는 꽤 오래되었다. 우리는 더 이상 페이지 단위가 아닌 컴포넌트 단위로 작업한다. 그러나 렌더링 패턴은 오랫동안 페이지 단위에 머물러 있었다. React 18에 등장한 RSC와 Suspense의 조합으로 스트리밍 SSR 아키텍처를 구축하거나, Ne..
프론트엔드, 서버로부터 독립을 선포하다(2) - 뷰 모델로 데이터 모델 의존성 줄이기
프론트엔드, 서버로부터 독립을 선포하다(2) - 뷰 모델로 데이터 모델 의존성 줄이기
2024.06.30프론트엔드는 애플리케이션에서 클라이언트 단에 위치하며 비즈니스 로직을 포함한 코드 영역을 말하며, 백엔드는 서버 단에 위치한 코드 영역을 의미한다. 이 두 요소는 각각 독립적으로 변경되고 발전하므로, 대다수의 애플리케이션 개발에서는 물리적으로 분리된 각기 다른 코드베이스를 가지는 경우가 많다. 그러나, 많은 애플리케이션들이 서버에서 데이터를 저장하고 클라이언트에서는 데이터를 캐시 하는 구조를 가지고 있기 때문에, 프론트엔드는 애플리케이션의 목표를 달성하기 위해 필연적으로 서버에 의존적일 수밖에 없다. 그리고 이런 의존성은 프론트엔드 개발과 테스트를 어렵게 하며, 변경에 취약하게 만든다. API 명세는 이러한 의존성을 약하게 만드는 방법이다. 하지만 그 자체로는 충분하지 않다. API 명세를 만드는 데에도..
프론트엔드, 서버로부터 독립을 선포하다(1) - MSW로 개발 및 테스트 의존성 줄이기
프론트엔드, 서버로부터 독립을 선포하다(1) - MSW로 개발 및 테스트 의존성 줄이기
2024.06.26프론트엔드는 애플리케이션에서 클라이언트 단에 위치하며 비즈니스 로직을 포함한 코드 영역을 말하며, 백엔드는 서버 단에 위치한 코드 영역을 의미한다. 이 두 요소는 각각 독립적으로 변경되고 발전하므로, 대다수의 애플리케이션 개발에서는 물리적으로 분리된 각기 다른 코드베이스를 가지는 경우가 많다. 그러나, 많은 애플리케이션들이 서버에서 데이터를 저장하고 클라이언트에서는 데이터를 캐시 하는 구조를 가지고 있기 때문에, 프론트엔드는 애플리케이션의 목표를 달성하기 위해 필연적으로 서버에 의존적일 수밖에 없다. 그리고 이런 의존성은 프론트엔드 개발과 테스트를 어렵게 하며, 변경에 취약하게 만든다. API 명세는 이러한 의존성을 약하게 만드는 방법이다. 하지만 그 자체로는 충분하지 않다. API 명세를 만드는 데에도..
지속 가능하고 효율적인 코드 리뷰를 하는 방법
지속 가능하고 효율적인 코드 리뷰를 하는 방법
2024.06.17아마도 팀 단위의 프로젝트를 경험해본 개발자라면 코드 리뷰를 해본 경험이 있을 것이다. 코드 리뷰는 개발자가 작성한 코드를 다른 동료 개발자들이 검토하는 과정이다. 코드 리뷰는 잘 이루어진다면 코드의 품질을 향상시키고, 예기치 않은 에러를 방지하며, 팀원 간 지식 공유를 활성화하는 아주 유용한 문화가 될 수 있다. 그러나 코드 리뷰 문화를 잘 유지하는 것은 생각보다 쉽지 않다. 코드 리뷰는 시간과 자원이 많이 들 뿐만 아니라, 막상 어떤 부분을 리뷰해야 할지 막연할 수 있기 때문이다. 이런 상황이 계속된다면, 코드 리뷰는 서로 "수고하셨습니다"라는 댓글만 남기는 아무런 의미 없는 피상적인 행동으로 남게 된다. 이번 포스팅에서는 효율적이고 유용한 코드 리뷰 문화를 유지하기 위한 리뷰어와 리뷰이의 역할에 대..
Cypress로 E2E 테스트 작성하기(ft. App action vs Page object model)
Cypress로 E2E 테스트 작성하기(ft. App action vs Page object model)
2024.06.12저번 포스트인 프론트엔드는 무엇을 테스트해야 하는가?에서는 프론트엔드에서의 유닛 테스트와 통합 테스트에 대해 집중적으로 다루었다. 이번 포스트에서는 프론트엔드의 또 다른 테스트 유형인 E2E 테스트에 대해 알아보고, E2E 테스트 도구인 Cypress를 활용하여 필자가 실제 진행 중인 사이드 프로젝트에서 E2E 테스트를 작성해 봄으로써, 이를 통해 E2E 테스트 작성 방법까지 다루어 보려고 한다. 1. 왜 E2E 테스트를 해야 하는가?E2E(End-to-End) 테스트는 애플리케이션의 흐름을 처음부터 끝까지 검증하는 것으로, 앞서 언급한 유닛 테스트와 통합 테스트와는 또 다른 의미를 가진다. 유닛 테스트와 통합 테스트가 개발자 관점에서 개발한 모듈이 정상적으로 작동하는지를 검증하는 반면, E2E 테스트..
프론트엔드에서 로깅은 왜 필요할까?(ft. 의존성 주입과 선언형 프로그래밍)
프론트엔드에서 로깅은 왜 필요할까?(ft. 의존성 주입과 선언형 프로그래밍)
2024.06.04모든 소프트웨어는 비즈니스를 위해 존재한다. 특히, 프론트엔드는 사용자와 가장 밀접하게 연결되어 있으므로, 비즈니스 로직 외에도 비즈니스 관련 요구사항을 처리해야 하는 경우가 많다. 이 중에서 대표적인 것이 바로 로깅이다. 로깅이 필요한 이유는 간단하다. 더 나은 비즈니스 결정을 내리기 위함이다. 비즈니스를 구체화하면서, 추상적인 개념들이 구체화되어 특정 기준을 정해야 하는 경우가 많다. 초기에는 사람의 감각에 의존할 수밖에 없지만, 비즈니스가 계속되면서 감각에만 의존하는 것은 위험성이 매우 크다. 따라서, 의사결정에 도움이 될 데이터를 수집하기 위해 로깅이 필요한 것이다. 따라서 로깅은 직접적인 비즈니스 로직은 아닐지라도, 비즈니스 성공과 직결된 매우 중요한 요소이다. 로깅에는 다양한 종류가 있지만, ..
프론트엔드는 무엇을 테스트해야 하는가?
프론트엔드는 무엇을 테스트해야 하는가?
2024.05.28"프론트엔드에서도 테스트를 해야 하는가?"라는 짧은 질문에 대한 답은 분명하게 "예"이다. 그러나 내 경험에 따르면, 테스트 코드를 작성하는 프론트엔드 개발자는 아직도 소수이다. 내가 진행하는 프로젝트에서는 테스트가 작성되지 않은 코드를 '순살 코드'라고 부른다. 이는 최근 화제가 되었던 철근이 빠진 '순살 아파트'에 비유하여 부르는 말이다. 순살 아파트와 순살 코드의 공통점은 언제 무너져도 이상하지 않다는 것이다. 오직 잘 짜인 테스트 코드 만이 변경으로부터 소프트웨어가 안전하게 원하는 의도대로 동작할 수 있음을 보장할 수 있다. 부끄럽지만 나도 몇 년 전까지는 테스트 코드의 중요성을 잘 알지 못했다. 특히 프론트엔드와는 무관한 이야기라고 생각했다. 하지만 기능이 안전하게 의도대로 작동함을 보장해야 하..
Turborepo로 모노레포에 엔진을 달아보자
Turborepo로 모노레포에 엔진을 달아보자
2024.05.20최근 개발 업계에서는 모노레포에 대한 관심이 높아지고 있으며, 이는 특히 프론트엔드 분야에서 두드러지게 나타나고 있다. 이는 아마도 폴리레포 방식보다 모노레포 방식이 프로젝트 관리에 있어 여러 가지 이점이 있기 때문일 것이다. 필자 역시 현재 프로젝트에서 모노레포 방식을 채택하고 있다. 그러나 필자의 경험에 따르면, 앞서 언급한 모노레포의 장점은 반정도 만 맞는 말이다. 실제로 모노레포 방식을 기본적으로 채택하면, 프로젝트 관리는 폴리레포보다 더 어려워진다. 그러므로, 모노레포를 통해 프로젝트 관리의 이점을 얻으려면, 모노레포를 효율적으로 사용할 수 있는 도구와의 결합이 필수적이다. 오늘 소개할 Turborepo는 이러한 도구 중 하나로, 모노레포의 이점을 극대화시킬 수 있는 강력한 기술이다. 이번 포스..
실제 사례로 보는 개발자가 좋은 코드를 작성해야 하는 이유
실제 사례로 보는 개발자가 좋은 코드를 작성해야 하는 이유
2024.05.02소프트웨어에서 변하지 않는 유일한 것은 모든 것이 변한다는 사실뿐이다. 고객의 니즈와 요구사항이 변하는 것은 물론, 우리의 문제에 대한 이해도도 변한다. 그리고 이러한 변화는 필연적으로 소프트웨어의 변화를 초래한다. 따라서, 개발자는 변화에 대응해야 하며, 이것이 바로 개발자의 존재 이유이다. 하지만 현실은 어떠한가? 2001년 애자일 매니페스토 이후 20년이 넘었지만, 변화에 대응할 수 있는 역량을 갖춘 개발자는 여전히 매우 소수에 불과하다. 그리고 나는 이러한 이유가 변화에 대응하는 것의 중요성에도 불구하고, 많은 개발자들이 가장 성장하는 초기 단계에서 변화에 대응하는 것을 직접 경험하고 훈련하지 않기 때문이라고 생각한다. 개발을 시작할 때, 많은 개발자들이 프로젝트를 학교 과제나 부트캠프를 통해 접..