"React" 태그로 연결된 9개 게시물개의 게시물이 있습니다.

이전 글에서 Container 중심 구조의 한계와 Feature-Sliced Design(FSD)으로의 전환 이유를 정리했습니다. 이번 글에서는 실제로 FSD를 프로젝트에 도입하면서 고민했던 내용들을 공유합니다.

이전 글에서 SOLID 원칙 중 O에 해당하는 OCP를 충족하는 React 개발에 대해 다루었습니다. 이번에는 L에 해당하는 리스코프 치환 원칙(Liskov Substitution Principle, LSP)에 대해 이야기해보려 합니다. React 개발에서 이 원칙이 어떻게 적용될 수 있는지 함께 살펴볼게요.

이전 글에서 SOLID 원칙을 간단하게 소개하고, 그 중 S에 해당하는 SRP를 충족하는 React 개발에 대해 다루었습니다. 이번에는 O에 해당하는 개방-폐쇄 원칙(Open-Closed Principle, OCP)에 대한 소개와 함께, React 개발에 어떻게 적용될 수 있는지 구체적인 예시를 통해 살펴보겠습니다.

프론트엔드 아키텍처를 설계할 때 가장 어려운 점은 규모가 커졌을 때도 유지 가능한 구조를 만드는 것이라고 생각합니다.

이 글에서는 제가 사용했던 Container 중심 아키텍처의 의도와 개념, 그리고 그 구조가 확장되며 드러난 한계를 정리하고, 왜 Feature-Sliced Design(FSD)을 다음 선택지로 정하게 되었는지를 이야기해 보려고 합니다.

혹시 SOLID 원칙에 대해 들어보셨나요? 개발을 접하신 분이라면 자세히는 몰라도 한 번쯤 이름은 들어보셨을 거예요. SOLID 원칙은 객체지향 설계에서 지켜야 할 5가지 소프트웨어 개발 원칙(SRP, OCP, LSP, ISP, DIP)을 말합니다.

• SRP(Single Responsibility Principle): 단일 책임 원칙
• OCP(Open Closed Principle): 개방 폐쇄 원칙
• LSP(Liskov Substitution Principle): 리스코프 치환 원칙
• ISP(Interface Segregation Principle): 인터페이스 분리 원칙
• DIP(Dependency Inversion Principle): 의존 역전 원칙

이런 원칙들을 지키면 좋은 객체지향 설계에 가까워질 수 있습니다. 그런데 'React에 객체지향이라니?' 하고 의아하게 생각하실 수도 있을 것 같아요. 하지만 우리는 이런 원칙들을 조금 더 넓은 시야로 바라볼 필요가 있다고 생각합니다.

Front-end 개발을 하다 보면 필연적으로 마주치는 상황이 있습니다. 바로 DB 데이터와의 연동입니다. 대부분의 프로젝트는 이 과정을 BE REST API에 의존하고 있습니다.

BE API가 완성되지 못하면 FE 프로젝트도 완성되지 못하고, 인터페이스가 변경되면 FE 프로젝트도 변경되어야 합니다. 여러분들은 이 의존성을 잘 관리하고 계신가요?

이 글에서는 BE API 의존성을 관리하면서 겪었던 시행착오와 함께, 현재 저희가 나아가고 있는 방향을 소개해드리려고 합니다.

Next.js App Router로 전환하면서 가장 혼란스러운 부분은 렌더링 방식의 변화입니다.

Page Router에서 SSR/SSG 기반 렌더링을 사용했다면, App Router에서는 RSC+Client Component 기반 렌더링을 사용하도록 변경되었습니다.

이 글에서는 두 방식의 동작 원리를 비교하고, App Router는 Page Router의 개선 버전이 아닌 서로 다른 패러다임을 가진 Next.js의 렌더링 방식임을 설명하려고 합니다.

디자인 시스템은 일관된 사용자 경험을 제공하고, 효율적인 디자인 및 제품 개발을 위해 디자인 원칙과 스타일 가이드, 구현 코드를 집약한 시스템입니다. 디자인팀과 개발팀의 공통 언어이자 지침이죠.

그래서 많은 회사에서 디자인 시스템을 구축해 관리하고 있습니다. 저희도 기존 디자인 시스템이 존재했습니다. 엄밀히 말하면 디자인 시스템이라고 불리던 코드는 존재했지만, 팀 전체가 공유하는 시스템으로서는 제대로 작동하지 않고 있었습니다.

이 글에서는 어떤 계기로 디자인 시스템 v2를 새로 만들게 되었는지 공유하려 합니다.

프론트엔드 개발을 하다 보면 빠짐없이 등장하는 주제 중 하나는 어떤 기준으로 컴포넌트를 나눌 것인가라고 생각합니다. 마찬가지로 카카오페이지 웹 파트도 이 주제로 여러 가지 시행착오를 겪어 왔습니다. 현재는 Harry가 소개해 주신 Atomic Design Pattern을 적용해 UI 컴포넌트를 나누는 기준으로 활용하고 있습니다. (https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/)

개인적으로 이 디자인 패턴의 가장 큰 장점을 꼽아보자면 컴포넌트별 역할이 잘 분리되고 높은 재사용성을 가진다는 것입니다. 재사용성이 뛰어난 컴포넌트들을 미리 잘 준비해 놓으면 추후 화면 전체를 개발할 때 속도 향상에 큰 도움이 되는 것을 체감하고 있습니다. 그래서 현재 프로젝트의 UI 컴포넌트를 개발할 때는 재사용성에 공을 상당히 많이 들이고 있습니다.

그렇게 컴포넌트들을 만들던 도중 하루는 Dialog Modal 구현이 필요하다는 디자인 팀의 요구사항이 들어왔습니다. 첨부된 이미지처럼 제목, 확인 버튼이 있는 안내 메시지였습니다. 이 컴포넌트도 역시 재사용성이 높게 만들고 싶어졌습니다. 어떻게 구현해볼 수 있을까요?