Overview React Suspense의 개념적 모델을 다룬 이전 포스팅의 마지막 부분에서 Dan Abramov(React Core Team)의 Suspense에 대한 Comment를 잠깐 언급했습니다. 이 Comment에 대한 구체적인 내용은 아래 인용문과 같습니다. (아래 인용문은 Suspense가 Fallback UI를 처리하기 위해서 throw 된 Promise를 사용한다는 내용을 이해하고 있다는 것을 전제로 합니다. 해당 내용에 대한 이해가 필요하다면 이에 대해 다룬 이전 포스팅을 참고해 주세요) This builds on a React feature called “Suspense”, which is in active development for the data fetching use cas..

Overview React v18의 정식 릴리즈가 나오면서 Automatic Batching, Transition등 여러 Feature들이 소개되었습니다. 그중에는 React v16.6에 Experimental Feature로 등장했다가 이번에 정식으로 탑재된 "Suspense"에 대한 내용도 추가되어 있는데, 이번 포스팅에서는 특별히 이 Suspense라는 기능에 대해서 살펴보려고 합니다. What is Suspense? Suspense lets your components “wait” for something before they can render. In this example, two components wait for an asynchronous API call to fetch some data..

Overview 이번 포스팅에서는 지난 포스팅에서 소개한 대로 프론트엔드에서 통합 테스트(Integration Test)를 구현하기 위한 방법을 설명하고자 합니다. 테스트가 작성되는 프로젝트는 React + Nextjs를 사용한 Server Side Rendering 프로젝트이고, 통합 테스트를 위한 도구로는 가장 유명한 도구 중 하나인 Cypress를 사용하였습니다. 또한 서버사이드 요청을 모킹하기 위해서 MSW(Mock Service Worker)를 사용하였습니다. React + Nextjs로 구성된 프로젝트가 아니더라도(e.g Angularjs, Vuejs) 통합 테스트를 작성하는 핵심 원리와 Server Side Request를 모킹 하는 핵심 원리는 동일하기 때문에 다른 적절한 방법을 찾아 테스..

Overview 2년 조금 넘는 시간 동안 프론트엔드 개발을 해 오면서 애플리케이션 생태계에서의 웹 서비스의 비중이 시간이 지날수록 점점 커지는 것을 실감하고 있습니다. 빠른 주기의 업데이트와 유연한 UI를 제공하기 위해서 많은 앱 애플리케이션들이 웹뷰를 사용해서 서비스를 구현하고 있으며 이에 따라 데스크톱 생태계에서 뿐 아니라 스마트폰 / 태블릿 생태계에서도 웹 서비스는 여전히 서비스의 가장 앞단에서 수많은 사용자에게 접점을 제공하는 중요한 역할을 맡고 있습니다. 이렇게 애플리케이션 내에서 웹, 즉 웹뷰의 사용이 점점 확대됨에 따라 웹뷰에서 제공하는 기능 또한 다양해졌고, 이로 인해 웹뷰 프로젝트의 규모가 커지고, 복잡도가 증가하게 되는 경우가 많아지는 것 같습니다. 여느 큰 규모의 프로젝트들이 그렇듯..

Overview React 공식문서의 Design Principles 부분을 보면, 다음과 같은 문구가 있습니다. Even when your components are described as functions, when you use React you don’t call them directly. Every component returns a description of what needs to be rendered, and that description may include both user-written components like and platform-specific components like . It is up to React to “unroll” at some point in the futur..

Overview 모노레포의 문화적 의의를 다룬 이전 포스팅에 이어, 이번 포스팅 시리즈에서는 실제로 모노레포를 팀에 도입하기 위해 거쳐왔던 여러 기술적인 고려 사항들을 간단하게 이야기해보려고 합니다. "모노레포는 이렇게 운영하는 것이 좋다"라는 가이드라기보다는 프론트엔드 팀이 모노레포로 전환하는 과정에서 겪은 여러 문제들과, 이를 해결해 나가는 과정에 대한 기록에 가까울 것 같습니다. 글은 다음과 같은 순서로 작성되었습니다. Workspaces & Dependencies Global Lint & Prettier Deploy & Branch Management Plugin (Optional) Sparse Checkout Large Files Problem 10명정도 규모의 팀이 하나의 레포에서 개발을 하게..