캐시 옵션을 사용하여 특정 뷰포트에 대한 서버 측 렌더링

반응형

과거에는 대부분의 고객들이 엄격한 규칙을 가지고 있고, 그들 중 일부는 실제로 쉽게 구부릴 수 없거나(예: SEO 요건) 제 과제를 납득할 시간이 더 필요하기 때문에 저는 모든 것을 수행하는 하나의 프레임워크를 좋아하지 않았습니다.

여러분 중 일부는 알겠지만, 저는 모든 애플리케이션이 단일 모노레포에 NextJS와 핫 리로드되고 앱/구성 요소/서비스/타입/글씨체/페이지/등용 패키지가 있는 전자 상거래 다중 테넌트 웹 사이트를 마칩니다. 분리된 패키지가 완전히 입력되었습니다.

이번에는 고객이 NextJS를 원했고(과거에는 빠른 설정을 위해 POC에서 주로 사용했음) 매우 적은 수의 팀이 있었기 때문에 매우 쉬웠습니다. 그들이 그것을 하지 않는 방법을 알았기 때문에 또한 쉬웠다 :).
멀티 테넌시(Multi-tenancy)를 통해 모든 테넌트를 위한 단일 기능에 매우 쉽게 집중할 수 있어 보다 쉽고 비용 효율적으로 작업을 수행할 수 있습니다.

멀티 테넌트(Multi-tenant) 웹 사이트를 만드는 것은 결국 축복이었습니다. 비즈니스 논리가 프런트엔드에 있어서는 안 되는 이유를 설명하는 데 시간을 할애할 필요가 없었기 때문입니다. 공동 개발자들에게 그들의 프로젝트를 멀티 테넌트 프로젝트가 될 수 있는 것처럼 다루라고 조언하고 싶습니다 :). 우리가 이미 다국어를 당연하게 여기는 것처럼 (고객은 쉽게 글로벌 언어를 목표로 삼아야 한다.)

NextJS 12는 미들웨어 기능 이후로 정말 멋졌습니다. 이 기능 덕분에 제 고객의 모든 SEO 요구사항을 처리할 수 있었습니다. 그것은 기본적으로 정적인 힘을 사용하면서도 역동적인 유연성을 가지고 있습니다.
하지만 코드베이스로 작업하는 개발자들이 많아지자마자 저는 이전 버전에서는 할 수 없었던 한 가지 기능을 싫어하게 되었습니다.

 

이것은 렌더링해야 할 때 실제 Viewport 사용에 대한 것으로, 이 경우 대부분 모바일과 관련이 있습니다.

따라서 기본적으로 아래 예와 같이 구성 요소를 재사용하여 중단점/구성별로 올바른 레이아웃을 제공할 수 있습니다. 뷰포트별로 패딩/플렉스/등등을 설정할 수 있는 것을 볼 수 있습니다. 그래서 우리 부품들이 매우 유연해졌습니다.

처음에 당신은 내가 이 뷰포트에 대해 말하는 것을 많이 들었다. 이 뷰포트는 무엇입니까?

여기에 정의된 열거형이 있으며 모든 구성 요소에서도 처리됩니다(위의 예 {base: 4, md: 8 } 참조). small 뷰포트에 대한 테마 크기 4와 md: 8 }은 중간 이상에서 시작하는 테마 크기 8을 의미합니다). 뷰포트:

먼저 미들웨어 도우미가 사용자 에이전트를 수락하고 라이브러리 모바일 탐지를 사용하여 모바일/데스크톱/기타인지에 따라 크기를 반환하겠습니다.

 

그런 다음 NextJS 응용 프로그램 src/pages/_middleware.ts에서 뷰포트 매개변수가 Params(로캘 등)의 일부로 도입되고(#ln23) 어느 페이지에서나 선택할 수 있습니다!

이제 뷰포트 프로포트는 모든 페이지 서버 측에서 페이지 프로포트로 사용할 수 있습니다. 다시 쓰기에서 볼 수 있듯이 페이지 구조는 다음과 같습니다.

src/pages/internal/[viewport]/[viewport]/index.tsx 등

뷰포트(#ln3)를 다음과 같이 ViewportProvider에 제공할 수 있습니다. src/pages/_app.tsx에서 말입니다(이 샘플이 단지 우리의 다음 앱에서 흐름을 보여주고 싶어 한 후에 제공자가 표시됩니다)

뷰포트가 초기 상태로 ViewportProvider에 전달되는 것을 볼 수 있습니다. 즉, 서버 측에서 공급자에게 전달합니다. ViewportProvider와 useViewport hook은 이와 같습니다.

 

추가 혜택은 우리의 테스트 파트이기도 합니다. 우리는 간단한 유닛 테스트를 할 수 있는 e2e 구성 요소 테스트로 너무 많은 아이템을 이동했습니다. MockedViewportProvider를 제공함으로써 구성요소 테스트는 매우 쉬워졌습니다. 여기 있습니다.

그런 다음 useViewport 후크를 사용하여 구성요소를 테스트할 수 있습니다. 그러면 Dummy 구성 요소의 예는 다음과 같습니다.

내 조언은 만약 당신이 최신의 위대한 것을 따르지 않았다면 NextJS 12를 다시 보는 것이다. 이제 매우 빠른 서버측 캐시 페이지가 있고 로케일 및 뷰포트에서와 마찬가지로 미들웨어를 사용하여 기능 전환 및 a/b 테스트도 처리할 수 있습니다.

NextJS의 모든 것이 좋은가요? 이 고객에게는 그렇습니다. 개인적으로 레이아웃에 대한 데이터를 가져오는 기능이 누락되는 것을 싫어합니다. 머리말과 바닥글입니다. 지금까지의 유일한 현실적인 선택은 모든 페이지에 내용을 넘기는 것입니다. 그러나 미들웨어 기능은 저를 정말 놀라게 했고 언젠가 그들이 우리가 가지고 있는 마지막 문제에 대한 해결책도 제시해 주길 바랍니다.