다음 단계는 어떻게 포석을 하지 않습니까?js

이 글은 처음에 제 사이트에 발표되었으니 마음대로 읽으세요. [https://sampotter.me/tech/how-not-to-do-layouts-in-nextjs]
다음 단계에서 레이아웃을 처리합니다.js는 이상한 놈이야.
간단하고 지속적인 레이아웃은 brilliant React framework의 주요 기능이 아니다.그러나 단일 페이지 애플리케이션(SPA)의 주요 기능입니다.근데 왜 다음은?js팀은 이 관건적인 웹 페이지를 어두운 구석에 숨기기로 결정했습니까?솔직히 나는 모른다.그렇게 지도 모른다, 아마, 아마...혹은 어떤 유형의 입문 장애로 초보자가 다음 단계에 배울 수 있도록 한다.js?글쎄.
이 문서의 목적은 다음과 같습니다.

왜 지속성 레이아웃이 좋은가

다음은 흔하다.사용할 수 없는 js 레이아웃 모드

왜 이런 패턴이 작동하지 않는지

그리고 아주 좋은 문장을 소개해 드릴게요. 그중에 몇 가지 좋은 해결 방안이 있어요.
내가 해결 방안을 제시하지 않은 이유는 내가 필요하지 않기 때문이다.솔직히 말해서, 이것은 내가 두 번째로 이 글을 쓰려고 시도한 것이다.나의 첫 시도는 무의미하다.제목은'How to do persistent layouts in Next.js'로, 기본적으로 구글 검색에서 찾은 모든 글의 통합이다.이 문제의 해결 방안은 매우 좋은 문서 기록이 있다.그러나 왜 이 문제가 발생했는지는 더욱 까다로운 문제다.나는 또 이 문제를 진정으로 깊이 이해하면 네가 문제를 해결하는 데 도움을 줄 수 있다고 생각한다.

왜 오래가는 포석이 좋은지.
내가 말한 지속적인 포석은 도대체 무슨 뜻입니까?대부분의 페이지는 어떤 구조를 가지고 있다. 즉, 그것들의 맨 위에는 내비게이션 표시줄이 있고, 밑에는 페이지 꼬리가 있을 수 있으며, 중간에는 한 무더기의 내용이 있을 수 있다.모든 페이지에서 통용되는 구성 요소는 레이아웃의 일부분 (예를 들어 이 예의 네비게이션 표시줄과 스크립트) 이며, 일반적으로 레이아웃 구성 요소로 추상화됩니다.이렇게 하면 개발자의 생활을 더욱 가볍게 할 수 있다.
그렇다면 지속적인 점은 무엇을 의미하는가?이것은 사용자가 한 페이지에서 다음 페이지로 내비게이션을 할 때, 우리가 페이지 레이아웃 구성 요소를 다시 불러오는 것을 피하는 방법과 관련이 있다. 왜냐하면 우리는 이러한 내비게이션 표시줄과 스크립트 구성 요소가 한 페이지에서 다음 페이지로 전환되지 않는다는 것을 알고 있기 때문이다.그리고 각 페이지의 내용을 다시 불러올 걱정만 하면 된다. 왜냐하면 이것은 다르기 때문이다.
좋은 레이아웃 지속성은 페이지 내비게이션에서 레이아웃이 지속되지 않을 때만 알아볼 수 있는 힘겨운 특성이다.가장 흔히 볼 수 있는 지속력이 떨어지는 예는 다음과 같다.

측면 탐색 모음이 스크롤 위치를 잃었습니다

내비게이션 표시줄의 검색 입력이 값을 잃어버렸다

초기 페이드 애니메이션을 재실행할 이유가 없음

개발자들은 보통 복잡한 상태 처리 프로그램을 사용하여 이런 문제를 해결하는데 이런 처리 프로그램은 스크롤 위치, 애니메이션 상태와 기타 불필요한 일을 확정하기 어렵다.비록 이런 것들은 나쁜 사용자 체험 문제일 뿐이지만, 보통 웹 응용 프로그램의 기능을 손상시키지는 않는다.그것들은 사이트가 확실히 웹 응용 프로그램이라는 느낌을 없애고 사용자로 하여금 전통적인 사이트처럼 느끼게 한다. 사이트는 모든 상태를 잃게 하고 당신이 어떤 일을 할 때마다 전체 페이지를 갱신한다.
간단히 말하면 레이아웃의 지속성은 사용자에게'더 깨끗하다', 개발자에게는 유지보수가 더욱 쉽다.

작용하지 않는 흔한 반모드
이 내용을 읽을 때 다음 글에서 사용하는 패턴을 보았다면js 응용 프로그램, 당신은 분명히 나쁜 개발자입니다.농담입니다.나는 단지 이러한 반모드만 안다. 왜냐하면 나는 다음 문장에서 어느 때 그것들을 사용했기 때문이다.js 여행.

각 시트 어셈블리에 레이아웃 배치하기

const AboutPage = () => (
  <Layout>
    <p>This is an about page.</p>
  </Layout>
);

export default AboutPage;

고급 어셈블리 사용(HOC)

const withLayout = Component => props => (
  <Layout>
    <Component {...props} />
  </Layout>
);

const AboutPage = () => <p>This is an about page</p>;

export default withLayout(AboutPage);

포장 기본 내보내기

const AboutPage = () => <p>This is an about page</p>;

export default (
  <Layout>
    <AboutPage />
  </Layout>
);

이 모드들은 레이아웃의 지속성을 만들지 않습니다.
문제는 모든 상황에서 우리는 페이지 구성 요소 파일에서 페이지의 레이아웃에 대한 책임을 처리한다는 것이다.왜 이게 문제인지 설명해 드릴게요.

왜 이런 패턴들이 작용하지 않는가
이 해석을 유추하여 시작하겠습니다./pages 디렉토리의 각 파일을 상자로 취급합니다.딱딱한 종이 상자너의 /about.js 서류는 하나의 상자이고, 너의 /dashboard.js 서류도 하나의 상자이다.상자마다 라벨이 하나씩 있는데 첫 번째 상자의 라벨About, 두 번째 상자의 라벨Dashboard이 적혀 있다.다음.js 그리고 파일마다 작성한 모든 코드를 표시된 상자에 넣습니다.
현재 사용자가 /about에서 /dashboard까지 내비게이션을 할 때 그 다음은 다음과 같다.js는 React에 페이지를 업데이트해야 한다고 알려 줍니다.기본적으로 React는 각 상자의 라벨을 보고 About 상자를 버리고 새 요청Dashboard 상자로 바꾼다.
React는 상자 안에 무엇이 있는지 모르지만, 그것은 개의치 않는다.React가 하는 일은 모든 상자에 있는 탭을 보고 새 요청의 탭을 넣을 수 있도록 교환하는 것입니다
사용자를 위한 준비.
이게 어떻게 우리의 포석을 망칠 수 있습니까?위의 세 가지 모드 중 모든 상자의 내용은 <Layout> 구성 요소로 시작됩니다.그러나 React는 개의치 않기 때문에 첫 번째 상자가 던져질 때, 레이아웃은 DOM에서 마운트 해제되고, 스크롤 위치를 포기하고 입력 값을 삭제한 다음, 새 상자가 제자리에 있을 때 바로 다시 마운트합니다.
이제 제자리에 놓으라고.
우리가 말한 모든 물리 상자는 사실상 하나의 조립품일 뿐이다.코드를 포장해서 상자에 넣는 것이 아니라, 더 큰 페이지 구성 요소에 하위 구성 요소를 넣는 것입니다.함께 배치된 모든 어셈블리는 어셈블리 트리를 생성합니다.
전체 과정을 reconciliation라고도 부르고 때로는'확산'이라고도 부른다.사용자가 /about에서 /dashboard까지의 전체 과정을 살펴봅시다.
사용자가 About 페이지를 볼 때 어셈블리 트리는 다음과 같습니다.

// App component tree while looking at the About page
<App>
  <AboutPage>
    <Layout>
      <p>This is an about page</p>
    </Layout>
  </AboutPage>
<App>

다음에 언제?js는 React에 페이지를 업데이트해서 /dashboard 표시하라고 알려 줍니다. React는 새로운 트리를 구축해야 합니다.이 과정은 rendering라고 불리는데 그 중에서 React 호출 루트 구성 요소(기본적으로 호출App()는 본질적으로 하나의 함수이기 때문에)와 동시에 모든 후속 하위 구성 요소를 다음과 같은 방식으로 끝낼 때까지 호출한다.

// App component tree for the newly requested Dashboard page
<App>
  <DashboardPage>
    <Layout>
      <p>This is a dashboard page</p>
    </Layout>
  </DashboardPage>
<App>

React에 두 개의 렌더링 트리가 있다면, 그 트리의 차이점을 확인해야 합니다. 그러면 프로그램에서 필요한 내용을 업데이트할 수 있습니다.이것은 대장 위치, 차별화 위치, 상자 교환 위치이다.루트 구성 요소 ((<App> 부터 React는 트리를 따라 아래로 옮겨다니며 단계마다 구성 요소가 다른지 확인합니다.React가 첫 번째 차이<AboutPage>와 <DashboardPage> 구성 요소를 얻으면 전체 <AboutPage> 트리를 삭제하고 <DashboardPage> 트리와 교환합니다.너는 지금 우리<Layout>가 어떻게 이 소동에 휘말렸는지 볼 수 있을 것이다.React는 레이아웃 구성 요소에 관심이 없고, 위의 두 페이지 구성 요소만 교환합니다.
지속적인 레이아웃 구성 요소의 해결 방안이 더욱 뚜렷해지기를 바란다.레이아웃이 폐기되고 다시 설치되는 것을 방지하기 위해서, 우리는 그것을 페이지 구성 요소의 외부에 두어야 한다. 즉, 페이지 구성 요소가 레이아웃 구성 요소의 하위 구성 요소가 되어야 한다.이렇게:

// About page component tree
<App>
  <Layout>
    <AboutPage>
      <p>This is an about page</p>
    </AboutPage>
  </Layout>
</App>

// Dashboard component tree
<App>
  <Layout>
    <DashboardPage>
      <p>This is a dashboard page</p>
    </DashboardPage>
  </Layout>
</App>

만약 우리의 구성 요소 트리가 이렇게 설정된다면, 이 두 트리 사이의 첫 번째 차이는 여전히 페이지 구성 요소 자체이지만, 우리의 <Layout> 는 더 이상 그들의 교환에 얽매이지 않을 것이다.이것이 바로 지속성을 창조하는 원인이다.

해결하다
이제 우리가 페이지 구성 요소와 레이아웃 구성 요소를 교환해야 하는 순서를 아는 것은 좋지만, 코드에서 이 점을 어떻게 할 것인가.내가 약속한 바와 같이, 나는 너희들에게 내가 가장 좋아하는 이 화제에 관한 문장을 전달할 것이며, 또한 너희가 유일하게 필요로 하는 문장이기도 하다.
Persistent Layout Patterns in Next.js - Adam Wathan
아담은 너에게 좋은 해결 방안을 줄 뿐만 아니라, 또 다른 시각을 제공하여 문제가 발생한 원인을 설명할 것이다.만약 당신이 그의 글을 읽은 후에도 여전히 곤혹스러우면 트위터에 DM이나 다른 것을 보내주세요.니가 날 찾을 수 있는 곳이야.
이렇게만약 피드백이 있다면, 다른 반모드적인 조언이 있거나, 단지 채팅을 하고 싶을 뿐이다.언제든지 연락 주세요.
샘.