export async function getStaticProps(context) {
  return {
    // Unlike `getInitialProps` the props are returned under a props key
    // The reasoning behind this is that there's potentially more options
    // that will be introduced in the future.
    // For example to allow you to further control behavior per-page.
    props: {}
  };
}

props 내에 포함될 수 있는 것 이외의 추가 데이터를 반환해야 하는 상황을 확인하는 데 관심이 있습니다. "페이지당 동작을 추가로 제어하기 위한" 인라인 설명이 약간 모호하다는 것을 알았습니다.

매우 흥미롭게 보입니다! getInitialProps 대신할 것인가 아니면 함께 할 것인가? 예를 들어 우리의 사용 사례에서 데이터 가져오기 API는 공공 서비스입니다. 따라서 클라이언트 측 탐색에서는 클라이언트가 API 계층을 직접 호출하는 반면 SSR에서는 서버가 호출할 것으로 예상합니다. 앞으로 이 사용 사례는 이전 방법으로 계속 해결됩니까?

props 내에 포함될 수 있는 것 이외의 추가 데이터를 반환해야 하는 상황을 확인하는 데 관심이 있습니다. "페이지당 동작을 추가로 제어하기 위한" 인라인 설명이 약간 모호하다는 것을 알았습니다.

나중에 필요한 경우 확장할 수 있도록 방법을 미래에 증명하는 것이 더 중요합니다.

매우 흥미롭게 보입니다! getInitialProps 대신할 것인가 아니면 함께 할 것인가? 예를 들어 우리의 사용 사례에서 데이터 가져오기 API는 공공 서비스입니다. 따라서 클라이언트 측 탐색에서는 클라이언트가 API 계층을 직접 호출하는 반면 SSR에서는 서버가 호출할 것으로 예상합니다. 앞으로 이 사용 사례는 이전 방법으로 계속 해결됩니까?

일반적으로 이러한 동작에는 전 세계의 특정 지역에서 느릴 수 있는 폭포수 가져오기와 같은 몇 가지 단점이 있습니다. getServerProps 접근 방식을 사용하면 응답을 보다 효율적으로 캐싱할 수 있습니다.

이것은 정말 흥미롭게 보입니다! 멋진 아이디어!

배포에 대한 우려가 있지만...

내가 Now를 호스팅한다고 상상해 봅시다.
첫 번째 배포의 경우 전체 응용 프로그램이 배포를 기반으로 구축된다는 것이 분명합니다.

그런 다음 CMS에서 일부 콘텐츠를 변경하고 SSG 페이지의 재구축만 트리거하려고 하지만 애플리케이션 코드는 변경되지 않았습니다.

즉시 알람이 울립니다. 이 경우 빌드를 트리거하면 두 가지 가능한 솔루션이 있습니다.

1) 모든 것이 캐시되므로 아무 것도 다시 빌드되지 않습니다. 코드가 변경되지 않았으며 blabla.
2) --force , 이제 "모든 것"이 다시 빌드되지만 SSG 페이지만 다시 빌드해야 했습니다.

_이것은 빌드 시스템 자체에 따라 달라지므로 가설일 뿐입니다.

이것은 다른 호스팅 솔루션에 영향을 줄 수 있습니다.

다음 자체에는 .next/cache ... 이 문제를 해결하려면 어떻게 해야 합니까?

@joltmode 는 기본적으로 현재 모든 정적 사이트 생성기의 경우입니다. .next/cache 는 Now의 배포와 재사용 간에 보존됩니다. 현재 이 경우에 캐싱(https://zeit.co/blog/serverless-pre-rendering)과 함께 getInitialProps를 사용 중일 수 있다는 점을 명심하십시오. 이 캐싱은 서버리스 기능에서 동적으로 렌더링한 다음 CDN에 캐시합니다. 동작은 여전히 ​​괜찮으며 getServerProps 를 사용하면 계속 작동합니다.

정말 굉장합니다. 고객 프로젝트에 Next를 사용하는 방법에 잘 맞고 복사하는 일부 상용구 코드를 제거합니다.

한 가지 고려해야 할 사항은 getStaticProps 및 getServerProps의 이름 지정입니다. { props } 및 향후 잠재적인 다른 옵션을 반환하는 경우 *Props가 혼동되지 않을까요? getStaticConfiguration, getStaticSetup, getStaticOptions가 더 일반적일까요?

@kibs 반환 값은 항상 소품이 처리되는 방식과 관련이 있습니다. 그래서 네이밍이 좋다.

이것은 단순히 굉장합니다! 이것은 내가 최근에 가지고 있거나 개인 및 전문 웹 앱을 개발하는 동안 생각할 수 있었던 모든 사용 사례와 필요를 해결합니다. 당신은 내가 하이브리드 사이트 생성기를 시작하는 것을 막았습니다. 감사합니다!

나는 또한 새로운 방법이 이전 getInitialProps() 및 exportPathMap() 보다 낫다는 것과 관련될 수 있습니다. 이것은 처음에 Next.js를 사용하기 시작하고 SSR/SSG를 파헤쳤을 때 약간 혼란스럽게 들렸습니다. 페이지당 접근 방식이 나에게도 더 의미가 있습니다.

이것을 시도하기 위해 기다릴 수 없습니다!

참고 사항: 마지막 예에서 getServerProps() 에 context 매개변수가 누락된 것 같습니다.

참고 사항: 마지막 예제에서 getServerProps()에 컨텍스트 매개변수가 누락되었다고 생각합니다.

결정된!

이것은 좋은 소리입니다! TypeScript 사용자 관점에서 getStaticProps , getStaticPaths 및 getServerProps 를 페이지 구성 요소의 정적 메서드(예 getInitialProps )로 사용하면 더 쉽게 입력/사용할 수 있습니다.

const Page: NextPage<Props> = (props) => ...

// Explicit types needed here
export const getStaticPaths: NextGetStaticPaths<Params> = () => ...
export const getStaticProps: NextGetStaticProps<Props, Params> = (context) => ...
export const getServerProps: NextGetServerProps<Props> = (context) => ...

export default Page

// vs.

const Page: NextPage<Props, Params> = (props) => ...

// Static method types come from NextPage<Props, Params>
Page.getStaticPaths = () => ...
Page.getStaticProps = (context) => ...
Page.getServerProps = (context) => ..

export default Page

@herrstucki 그 접근 방식의 문제는 나무를 흔드는 것이 훨씬 더 어려워진다는 것입니다(읽기: 불가능에 가깝습니다). 이는 불필요한 코드가 브라우저에 전달될 것임을 의미합니다.

@timneutkens 좋은 지적 ... 하지만 별도의 파일이 더 의미가 없을까요? 아니면 이와 같은 것이 _안정적으로_ 나무를 흔들 수 있습니까?

// This should all be removed in client-side code …
import {fetchQuery, queryTag} from 'big-data-fetching-lib';
const query = queryTag`...`
export const getStaticProps = async () => ({ props: await fetchQuery(query) })

// Only this should be included client-side
export default (props) => ...

@herrstucki 우리는 그것을 안정적으로 흔들 수 있지만, 우리는 여전히 별도의 파일을 갖는 것에 대해 논의하고 있습니다. 개인적으로 단일 파일 접근 방식을 선호합니다.

매우 흥미롭게 보입니다! getInitialProps 대신할 것인가 아니면 함께 할 것인가? 예를 들어 우리의 사용 사례에서 데이터 가져오기 API는 공공 서비스입니다. 따라서 클라이언트 측 탐색에서는 클라이언트가 API 계층을 직접 호출하는 반면 SSR에서는 서버가 호출할 것으로 예상합니다. 앞으로 이 사용 사례는 이전 방법으로 계속 해결됩니까?

일반적으로 이러한 동작에는 전 세계의 특정 지역에서 느릴 수 있는 폭포수 가져오기와 같은 몇 가지 단점이 있습니다. getServerProps 접근 방식을 사용하면 응답을 보다 효율적으로 캐싱할 수 있습니다.

물론, 하지만 반응 서버에 대한 RTT를 전혀 피하는 것에 대해 이야기하고 있습니다. 서버의 SSR 출력이 CDN/캐시 서버 프록시에 캐싱되는 경우를 생각해 보자. 다른 API 레이어(웹/앱/모든 클라이언트에 공통)를 직접 호출하는 클라이언트 탐색을 위한 데이터 가져오기와 함께 사용하면 트래픽이 많은 시나리오에서 Next.js 서버 레이어를 확장할 필요가 없습니다.

폭포수 가져오기의 요점을 이해하지만 소비자에게 다음 서버를 데이터 소스와 비교하여 SSR 계층으로 취급할 수 있는 기능을 제공하면 훨씬 더 나은 확장 설정이 가능합니다.

매우 흥미롭게 보입니다! getInitialProps 대신할 것인가 아니면 함께 할 것인가? 예를 들어 우리의 사용 사례에서 데이터 가져오기 API는 공공 서비스입니다. 따라서 클라이언트 측 탐색에서는 클라이언트가 API 계층을 직접 호출하는 반면 SSR에서는 서버가 호출할 것으로 예상합니다. 앞으로 이 사용 사례는 이전 방법으로 계속 해결됩니까?

일반적으로 이러한 동작에는 전 세계의 특정 지역에서 느릴 수 있는 폭포수 가져오기와 같은 몇 가지 단점이 있습니다. getServerProps 접근 방식을 사용하면 응답을 보다 효율적으로 캐싱할 수 있습니다.

물론, 하지만 반응 서버에 대한 RTT를 전혀 피하는 것에 대해 이야기하고 있습니다. 서버의 SSR 출력이 CDN/캐시 서버 프록시에 캐싱되는 경우를 생각해 보자. 다른 API 레이어(웹/앱/모든 클라이언트에 공통)를 직접 호출하는 클라이언트 탐색을 위한 데이터 가져오기와 함께 사용하면 트래픽이 많은 시나리오에서 Next.js 서버 레이어를 확장할 필요가 없습니다.

폭포수 가져오기의 요점을 이해하지만 소비자에게 다음 서버를 데이터 소스와 비교하여 SSR 계층으로 취급할 수 있는 기능을 제공하면 훨씬 더 나은 확장 설정이 가능합니다.

이 새로운 동작은 CDN이 동적 응답을 지원하는 경우 실제로 전체 결과를 CDN에 캐시할 수 있음을 의미한다고 오해하고 있는 것 같습니다. 이것은 이전에 getInitialProps를 사용하여 안정적으로 가능하지 않았습니다.

@timneutkens babel-plugin-preval 코드를 getStaticProps 로 이식하려고 하는 카나리아를 가지고 놀았습니다. fs 문제가 생겼습니다.

내 ./pages/blog/ 디렉토리의 .md 파일을 읽고 루프를 통해 모든 게시물이 포함된 블로그 색인 페이지를 만들려고 합니다.

import React from 'react';
import Link from 'next/link';
import fs from 'fs-extra';

const Index = ({ posts }) => (
  <div>
    Hello World. <Thing msg="hello" />
    <Link href="/thing">
      <a>About</a>
    </Link>
    {posts.map(p => (
      <div key={p.title}>{p.title}</div>
    ))}
  </div>
);

Index.getStaticProps = async () => {
  const items = await fs.readdir('./pages/blog');
  items.forEach(path => /* .... do some stuff ... */ )
  return { props: { posts: items } };
};

export default Index;

이 코드는 다음 오류로 이어집니다.

Module not found: Can't resolve 'fs' in '/Users/jared/Downloads/nextjs-typescript-template/node_modules/fs-extra/lib'

Razzle의 IIRC에 따르면 이 오류는 webpack의 파일 시스템 스텁(또는 그 부족)과 관련이 있습니다. 나는 이것을 webpack 구성에 추가하여 Razzle로 한 번 이것을 수정했다고 생각합니다.

node: {
  fs: "empty";
}

이 next.config.js를 시도했지만 오류가 사라집니다. fs / fs-extra 가 실제로 작동하지 않거나 작동하지만 아마도 경로가 작동하지 않는 것으로 보입니다(나에게 명확하지 않음). 그것에 대한 생각이 있습니까?

더 일반적으로 내 다른 질문은 getStaticProps 에서 import 대 require를 사용하는 모범 사례가 무엇이라고 생각하는지입니다. 내가 틀리지 않았다면 위의 스니펫은 fs-extra 를 React에서 동형적으로 가져오려고 시도합니다??. 따라서 이와 같이 인라인 요구 사항으로 가져오기를 변경하는 것이 더 낫습니까?

js Index.getStaticProps = async () => { const fs = require('fs-extra'); // only require when needed at SSG const props = await fs.readdir('./pages/blog'); return { props: { posts } }; };

이 새로운 동작은 CDN이 동적 응답을 지원하는 경우 실제로 전체 결과를 CDN에 캐시할 수 있음을 의미한다고 오해하고 있는 것 같습니다. 이것은 이전에 getInitialProps를 사용하여 안정적으로 가능하지 않았습니다.

아, 무슨 말인지 알 것 같아요. 그것은 첫 번째 SSR 생성의 getServerProps 가 고유한 끝점을 생성한다는 것을 의미합니까? 콘텐츠 주소 지정 가능한 해시에서 아마도 URL에 있을 수 있으며 그런 다음 CDN에 캐시할 수 있습니까? 이것의 유일한 단점은 캐시가 비 Next 앱(android/ios)과 Next 앱 간에 공유할 수 없다는 것입니다. 또한 외부 데이터 소스의 경우 캐시 제어 지시문이 업스트림이지만 Next가 데이터 제공을 담당하므로 생성된 데이터 끝점에 대한 API 또는 소품을 지정하기 위해 API 또는 소품이 필요합니다.

@jaredpalmer 나는 https://github.com/zeit/next.js/issues/9524#issuecomment -558628066 ( 안정적인 트리 흔들림 가능성에 대한 내 우려 포함)이 완전히 별도로 컴파일되는 별도의 파일을 가짐으로써 해결될 것이라고 가정합니다. 클라이언트 번들 코드? 예

pages/
    foo.js
    foo.data.js (<- exports getStaticProps etc.)

or:

pages/
    foo.js
pages-data/
    foo.js (<- exports getStaticProps etc.)

@jaredpalmer 트리 쉐이킹은 카나리아에서 아직 구현되지 않았습니다.

항상 그렇듯이 모든 일에 감사드립니다. Next.js는 작업하는 데 있어 절대적인 기쁨을 누렸습니다. 앞서 말씀드린 것처럼 거의 모든 기능 릴리스를 통해 제가 관리하는 코드베이스의 크기를 _감소_시킬 수 있습니다. 놀랍다.

이 RFC는 작성된 대로 많은 응용 프로그램에 즉시 유용하기 때문에 이 RFC를 비판하기 어렵습니다. 그러나 나는 내가 동의하는지 확신할 수 없는 한 줄을 말하고 싶습니다.

" getStaticPaths 는 exportPathMap 가 있어야 하는 필요성을 대체하고 페이지별로 작동합니다."

일부 응용 프로그램에서는 빌드 시 경로를 아는 것이 비현실적이거나 불가능합니다. 몇 가지 예는 다음과 같습니다.

• 사용자 프로필 페이지
• 제품 페이지(재고가 빠르게 변화하는 회사의 경우)
• 판매 주문 세부 정보 페이지

이와 같은 페이지의 경로는 /entity-name/entity-id 것이며 Next의 동적 경로는 router.push('/customers/[customerId]', '/customers/baer') 와 같은 작업을 수행할 수 있기 때문에 정말 잘 작동합니다. 아직 함정이 있습니다. Serve, Netlify, NGINX 등과 같은 것으로 이러한 파일을 정적으로 제공할 계획이라면 사용자가 페이지 새로 고침에서 404를 얻지 않도록 리디렉션 세트를 생성해야 하며 그렇게 하려면 여전히 exportPathMap 가 필요합니다.

다음은 내가 정기적으로 작업하는 코드베이스에서 거의 그대로 복사됩니다.

const buildServeConfig = redirects => {
  const config = {
    public: `dist`,
    trailingSlash: true,
    rewrites: redirects
  };

  const outputPath = `${__dirname}/serve.json`;

  fs.writeFile(outputPath, JSON.stringify(config, null, 2), err => {
    if (err) {
      throw err;
    }
    // eslint-disable-next-line no-console
    console.log(`Generated: ${outputPath}`);
  });
};

...

exportPathMap: function(defaultPathMap, { dev, outDir }) {
  const redirects = Object.entries(defaultPathMap)
    // No need to create a redirect rule for `/dirname/` or `/dirname/index.html`
    .filter(([url]) => url !== `/` && url !== `/index`)
    .map(([url, { page }]) => ({
      // Replaces /[customerId] with /:customerId
      source: url.replace(/]/g, ``).replace(/\[/g, `:`),
      destination: `${page}/index.html`
    }));

  // By default, the routes are sorted such that a route like `/order/:orderId`
  // comes before `/order/new`. Since the `:orderId` portion of `/order/:orderId` 
  // is a wildcard, the route `/order/new` will be a match and consider `new` 
  // as a value for `:orderId`. To get past this, we sort the redirects by the 
  // number of parameters in ascending order.
  const sortedRedirects = [...redirects].sort(
    (currentRedirect, nextRedirect) =>
      currentRedirect.source.split(`:`).length >
      nextRedirect.source.split(`:`).length
  );

  buildServeConfig(sortedRedirects);

  return defaultPathMap;
}

나는 이 RFC가 API를 더 이상 사용하지 않거나 제거하지 않는다는 것을 이해하고 빌드 디렉토리를 순회하여 이러한 리디렉션을 빌드할 수 있다는 것을 알고 있으므로 더 이상 사용되지 않는 경우에도 멋진 탈출 해치를 가지고 있습니다. 그러나 " getStaticPaths 대한 필요성을 제거"하지는 않습니다.

다시 한 번, 이 프로젝트를 수행하는 방식에 대해 사려 깊게 생각해 주셔서 감사합니다.

getStaticProps / getStaticPaths 및 getServerProps 상호 배타적입니까? 즉, 미리 렌더링된 부품과 동적 부품을 동시에 가질 수 있습니까?

예, 하나는 정적 생성이고 하나는 서버 측 렌더링입니다.

이것은 우리가 Next로 마이그레이션하기 전에 Gatsby에서 놓친 큰 것 중 하나를 수정합니다.

변경되지 않는 페이지를 렌더링하기 위해 데이터를 가져오는 모놀리식(100kbs) JSON 파일이 있습니다. Gatsby에서 JSON 파일을 GraphQL 스키마에 로드하고 이에 대해 쿼리하여 주어진 페이지를 렌더링하는 데 필요한 데이터만 가져왔습니다. Next를 사용하여 이를 수행하는 가장 쉽고 깨끗한 방법은 사용자가 전체 JSON 파일을 다운로드해야 하는 import monolith from './monolith.json' 입니다.

이 RFC 100%는 이 사용 사례를 해결하고 Gatsby가 빛나는 영역에서 Gatsby와 동등한 수준에 한 걸음 더 다가가도록 합니다(분명히 Gatsby는 런타임 SSR을 수행할 수 없으므로 정적 빌드 타임 렌더에 대해서만 이야기하고 있습니다).

@timneutkens , RFC에 감사드립니다!

최근에 @rauchg와 논의한 Next.js의 사용 사례가 있습니다.

Next.js는 매우 부드러운 DX와 몇 가지 합리적인 기본값을 제공합니다. 그래서 저는 클라이언트 측 전용 렌더링 애플리케이션인 Smart TV 앱에 Next.js를 사용하는 데 관심이 있습니다.

스마트 TV 앱은 TV의 브라우저 엔진에서 실행되는 거의 고전적인 웹 앱입니다.

1. 앱은 스타일, 스크립트, 이미지, _index.html_, 인증서 및 TV 구성 파일과 같은 번들로 패키징됩니다.
2. 번들은 검토를 위해 플랫폼의 앱 스토어에 제출됩니다.
3. 그런 다음 번들은 스토어에서 앱으로 설치되고 사용자가 실행합니다.

문제는 번들이 TV 장치 자체에 의해 정적으로 호스팅되고 서버에서 로드되지 않는다는 것입니다. 따라서 SSR 옵션은 불가능합니다(Node.js는 이러한 목적으로 개발자에게 노출되지 않습니다). 그러나 앱 자체는 동적입니다(예: Netflix).

따라서 정적 웹 서버에서 호스팅하는 SPA를 실행해야 합니다.

getServerProps (또는 getInitialProps )를 선택 해제하면 SSR을 방지하는 데 완전히 도움이 됩니다. 그러나 클라이언트에서 동적 렌더링은 어떻게 됩니까? 이 경우 라우팅은 어떻습니까? 이 RFC 에 따르면 문제는 아직 해결되지 않았습니다. @timneutkens ,

추신: 이 사용 사례에 대해 별도로 논의하는 것이 더 낫다고 생각하는 경우 이 사용 사례에 대한 문제를 만들 수 있습니다.

@grushetsky 는 다른 문제를 만들 수 있습니다. 이것은 RFC에서 논의되는 것과 완전히 다른 질문입니다 👍

@timneutkens 이 RFC의 약속은 제가 Next! 그래도 명확히 하자면 getInitialProps 도 여전히 존재하겠죠?

올바른 @outdooricon -- getInitialProps 는 당분간 계속 유지됩니다.

RFC에 따라:

이 RFC는 API 추가에 대해 독점적으로 설명합니다. 모든 새로운 기능은 이전 버전과 완전히 호환되며 점진적으로 채택할 수 있습니다. 이 RFC는 더 이상 사용되지 않습니다.

훌륭한 RFC, 이에 대해 매우 기대됩니다!

특정 사용 사례와 관련하여 getServerProps 에 대해 생각하고 결과를 캐시에 저장했습니다. 이것이 API-endpoint로 바뀌고 그 결과가 props로 컴포넌트에 전달되기 때문에 Redux, GraphQL-cache 등과 같은 외부 캐시에 결과를 클라이언트 측으로 넣는 규정된 방법이 있습니까?

getInitialProps 올바르게 이해하면 정적 및 비동기식이므로 Next는 구성 요소를 처음으로 렌더링하기 전에 완료될 때까지 기다릴 수 있습니다. 이를 통해 외부 캐시에 물건을 넣을 수 있습니다. getServerProps 는 서버에서 실행되기 때문에 해당되지 않으며 구성 요소 수명 주기의 캐시에 항목을 넣는 것은 아직 캐시에서 데이터를 사용할 수 없는 렌더링이 있어야 함을 의미하는 것 같습니다. , props에서 사용 가능하더라도?

이것은 물론 의도적일 수도 있고 접근 방식을 놓치고 있을 수도 있지만 고려한 사항인지 묻고 싶다고 생각했습니다.

편집: getStaticProps 에도 적용되는 것 같습니다. 😄

어딘가에서 놓쳤을 수도 있지만 콘텐츠가 캐시되었지만 db에서 업데이트되거나 새 블로그 게시물이 생성되는 상황을 어떻게 처리합니까? 새 빌드를 자동으로 수행할 필요가 있습니까? 그런 것 같아요.

가장 먼저! 훌륭한 제안입니다. 대부분의 사람들의 사용 사례에서 exportPathMaps 보다 크게 개선되었습니다. 정말 감사합니다. 그렇긴 한데, 나는 우리가 어떻게 그것을 경로 국제화와 함께 작동시킬 수 있을지 이해하기 위해 고군분투하고 있습니다.

i18n 접두사 경로를 처리하는 방법에 대한 제안 사항이 있습니까? 내 특정 사용 사례는 다른 국가 언어 접두사 및 URL이 있는 페이지에 수천 개를 구축해야 합니다.

/nl/brillen
/gb/glasses
/es/gafas
...

getStaticPaths 는 귀하의 예( /blog/[id].js )와 같이 url의 접두사가 잘 알려져 있을 때 정말 도움이 될 것 같습니다. 그러나 동적 접두사(country-lang)와 동적 경로를 모두 사용하여 루트 수준에서 경로를 생성해야 하는 경우 getStaticPaths 구현이 어떻게 보일 것 같습니까?

@reaktivo pages/[lang]/blog/[id].js -> getStaticPaths 에서 정적으로 렌더링할 모든 URL을 제공합니다.

@timneutkens 이것이 언제 사용 가능하거나 테스트 가능한지 알 수 있습니까?

일반적으로 우리는 솔루션이 올바른지 확인하기 위해 프로덕션 앱에 대해 기능을 광범위하게 테스트하기 때문에 ETA를 제공하지 않습니다.

이 개선 사항으로 인해 "유지되지 않는" 현상적 프로젝트(나 외에는 아무도 사용하지 않는 react ssg)가 더 이상 사용되지 않습니다. 이 누락된 부분을 추가하는 Next.js를 보니 정말 기쁩니다!

궁금증을 해소하고자 합니다. WordPress와 같은 CMS 사용을 고려하십시오. 내가 이해하는 것처럼 getStaticPaths 메서드를 사용하여 모든 게시물을 가져오고 다음과 같은 목록을 전달합니다.

export async function getStaticPaths () {
  return [
    // This renders / blog / hello-world to HTML at build time
    {params: {slug: "hello-world"}}
  ];
}

각 게시물의 슬러그는 콘텐츠를 가져오기 위해 getStaticProps 메서드에서 사용됩니다.
이것은 npm 빌드에서 발생합니다.
내 질문은 빌드 후에 추가될 새 게시물에 관한 것입니다.
getStaticProps 메서드를 사용하여 이 새 게시물을 슬러그로 가져오나요?
이 새 게시물에 이전 빌드의 파일과 같은 .html 파일이 있습니까?
나는 다음과 함께 일하는 것을 좋아하고 여러 프로젝트에서 이것이 매우 좋을 것입니다.

직접적인 관련은 없지만 지원팀에서 내 질문과 일치하는 답변을 제공할 수 없습니다.

여기에서 제안하는 것이 해결책이 될 수 있지만 그 동안 webhook 변경 사항을 기반으로 JAMSTACK을 빌드하도록 nextJS를 만들 수 없습니다.

getInitialProps가 있으면 서버에서 렌더링됩니다.
그렇지 않으면 나는 단지 CDN화되지만 사전 렌더링 없이는 그렇지 않습니까? 그리고 XHR이 반환되지 않는 한 페이지는 콘텐츠가 없을 것입니다(안녕하세요 SEO)

nextJS가 포함된 Jamstack의 현재 실행 중인 예제가 있습니까? netlify에서 할 수 있습니다.

감사 해요,
안드레아스

Hey @ScreamZ - 이 변화가 next export 를 사용하여 nextjs 사이트를 정적으로 컴파일할 수 있었지만 여전히 getInitialProps 사용하여 클라이언트 측 경로 전환에 대한 데이터를 가져옵니다. getStaticProps 를 사용하는 기능을 사용하면 추가 데이터를 가져오지 않고도 클라이언트 측 전환을 실행할 수 있습니다. getStaticProps 에서 가져온 모든 데이터는 빌드 시 한 번만 가져오고 다시 구축하지 않는 한 라이브 사이트. 이것은 데이터 기반 정적 사이트의 고전적인 아키텍처이며 웹훅을 통해 데이터 소스를 호스트에 연결하고 데이터 소스가 변경되면 호스트에게 사이트를 다시 빌드하도록 지시합니다.

완전히 정적인 nextjs 웹사이트의 기존 예제가 많이 있으며 netlify에서 nextjs 사이트를 실행하는 것은 간단합니다. 우리 회사의 웹사이트 는 현재 nextjs에서 실행되고 있으며 netlify에서 호스팅하고 있습니다. 이것이 좋은 예가 되기를 바랍니다.

zeit의 호스팅 서비스도 강력하게 고려해야 할 가치가 있다는 점은 주목할 가치가 있습니다. 가격은 매우 비슷하고 nextjs 사이트와의 통합은 타의 추종을 불허합니다. 말 그대로 아무 것도 구성할 필요가 없습니다. github에 연결하기만 하면 zeit의 호스팅이 nextjs를 실행 중임을 인식하고 자동으로 구성 및 배포합니다. 모든 것.

이것은 결코 광고가 아니며, 나는 zeit를 위해 일하지 않으며, 단지 진정한 보증입니다. netlify를 사용하면 절대적으로 작동하게 만들 수 있으며 개인적으로 여러 사이트에 대한 증거를 가지고 있습니다. 그러나 nextjs가 어떻게 작동하는지 철저히 이해해야 하며 netlify에서 원활하게 실행되도록 모든 것이 올바르게 구성되었는지 확인해야 합니다. nextjs 사이트를 위한 가장 간단하고 확실한 호스팅을 찾고 있다면 zeit's 호스팅을 시도해 볼 것입니다.

@jescalan 좋은 나눔 감사합니다 🙏🏻

Publish directory 를 사용하여 out 폴더를 지정할 수 있기 때문에 Netlify와 함께 NextJS를 사용하는 데 문제가 없습니다. 그러나 지금은 SSR을 사용하지 말고 next export 사용하여 완전히 고정하십시오.

@ScreamZ 이것은 일종의 사실이지만 "전체 정적" 사이트를 정확히 정의하는 방법에 따라 다릅니다. zeit의 호스팅 서비스가 있는 모든 페이지에 getStaticProps 를 사용하면 next export 실행하지 않더라도 실제로 얻을 수 있는 것은 정적 사이트와 동일합니다 getStaticProps 는 사이트가 배포될 때만 구축되며 그 이후에는 CDN에서 직접 제공됩니다.

디 차이 트 최근에 이렇게 포함 된 설정 어떤 사이트가 있음을 변경 : 가장 큰 차이점은 나는 디 차이 트의 호스팅에 정적으로 모든 페이지를 강제 할 수있는 방법이 아니라는 것을 알고 멀리로 (편집이다 exportPathMap 실행됩니다 완전히 정적 사이트이므로 더 이상 사실이 아닙니다.) getStaticProps 가 있는 페이지는 next export 의해 생성된 페이지와 정확히 동일하게 작동합니다. 페이지의 단일 정적 사본은 모든 조회에 대해 CDN에서 직접 제공됩니다. 그러나 getServerProps 또는 getInitialProps 일부 페이지를 실행할 수도 있으며 서버 렌더링 페이지로 작동합니다. 개인적으로 저는 이것을 이점으로 봅니다. SSR 경로가 필요한 경우 단순히 다른 데이터 가져오기 방법을 사용할 수 있으며 해당 단일 경로는 이제 SSR이고 다른 모든 경로는 정적으로 유지될 수 있습니다.

@jescalan 감사합니다.

따라서 이것이 구현되기를 기다려야 합니다. 그 동안 정적에 netlify를 사용할 것입니다.

SSG 구성에 대한 이야기가 있습니까? 특히 우리는 공유 빌드 아티팩트를 사용하고 싶지만 QA/제품에 대해 다른 구성으로 next export 를 실행하고 싶습니다. 이러한 구성 값은 getStaticProps 에서만 읽을 수 있습니다. serverRuntimeConfig 또는 publicRuntimeConfig 또는 process.env 직접 사용합니까?

@ScreamZ @jescalan 저는 오늘 @Timer 와 함께 Now에서 제로 구성 next export 지원을 받았습니다 (그는 모든 크레딧을 받을 자격이 있습니다). 넌 할 수있어:

"build": "next build && next export"

그리고 그것은 자동으로 작동합니다.

어떻게 되는지 알려주세요🙏

네, 저는 지원을 요청한 사람이었고 그들은 이것이 아직 구현되었다고 말했습니다 😅 제가 볼 수 있는 한, 구성에서 내보내기 맵을 정의해야 합니까?

@ScreamZ 아니요 위에 표시된 대로 next build && next export 를 추가하면 됩니다.

@timneutkens getInitialProps 를 getServerProps 바꾸면 Server Pre Rendering 를 활성화하기 위해 구성 파일에 target: 'serverless' 를 추가해야 합니까? 감사 해요.

우리는 이것을 어떻게 시도할 수 있습니까?

우리는 이것을 어떻게 시도할 수 있습니까?

이 모든 방법이 현재 인식되려면 unstable_ 접두사가 필요합니다.

예: unstable_getStaticProps

@timneutkens

@ScreamZ @jescalan 저는 오늘 @Timer 와 함께 Now에서 제로 구성 next export 지원을 받았습니다 (그는 모든 크레딧을 받을 자격이 있습니다). 넌 할 수있어:

"build": "next build && next export"

그리고 그것은 자동으로 작동합니다.

어떻게 되는지 알려주세요🙏

내 빌드 스크립트는 더 많은 작업을 수행하지만 매력처럼 작동하는 것 같습니다.

"build": "graphql codegen && next build && npm run export",

게다가 대단해! 내가 찾던 바로 그거야 😂 (Goodbye GatsbyJS, 내가 가장 좋아하는 프레임 워크는 이제 당신만큼 강력합니다!)

그러한 반응에 대해 대단히 감사합니다.

저도 9.1.6 업그레이드했는데 놀랍게도

나는 그 쓰레드가 RFC라고 생각했는데, 그것은 이미 우리에게 열린 것 같다 아아, 그렇지?
그러나 Typescript 유형은 9.1.6에서 활성화되지 않습니다.

젠장, 나 지금 너무 흥분돼! 🤣

마지막 질문:

• 내가 그것을 얻는다면, getInitialProps 는 미래에 더 이상 사용되지 않을 것입니까? 아니면 어떤 경우에는 여전히 관련성이 있습니까? 예를 들어?
• next export 는 getStaticProps 및 next build 만 있는 페이지를 위해 더 이상 사용되지 않을 수 있습니까?

좋은 도구 감사합니다🙏🏻

내가 그것을 얻는다면, getInitialProps는 미래에 더 이상 사용되지 않을 것입니까? 아니면 어떤 경우에는 여전히 관련성이 있습니까? 예를 들어?

초기 RFC에서 말했듯이 :

이 RFC는 API 추가에 대해 독점적으로 설명합니다. 모든 새로운 기능은 이전 버전과 완전히 호환되며 점진적으로 채택할 수 있습니다. 이 RFC는 더 이상 사용되지 않습니다.

나는 그 쓰레드가 RFC라고 생각했는데, 그것은 이미 우리에게 열린 것 같다 아아, 그렇지?

그렇지 않습니다. 우리는 ZEIT 응용 프로그램에서 그것을 시도하고 있으며 가시성 표면화의 일부는 이미 착륙했습니다(예: 본 페이지 트리).

다음 내보내기는 getStaticProps 및 다음 빌드만 있는 페이지를 위해 더 이상 사용되지 않을 수 있습니까?

맞습니다. 일반적으로 next export 사용하지 않게 됩니다. 이전 버전과의 호환성을 위해 유지되지만 일반적으로 API 경로와 같은 다른 기능을 지원하고 일부 페이지에 대해 서버 측 렌더링을 선택하여 내보내기의 모든 이점을 제공하므로 하이브리드 앱을 만들고 싶을 것입니다.

우리는 이것을 어떻게 시도할 수 있습니까?

이 모든 방법이 현재 인식되려면 unstable_ 접두사가 필요합니다.

예: unstable_getStaticProps

아직 사용하지 않는 것이 좋습니다. 실험적이며 릴리스 사이에 중단될 수 있습니다.

그래서 저는 이 기능을 가지고 놀았고 페이지 데이터를 포함하는 JSON 파일은 다른 페이지에서 SSG 페이지에 액세스한 후 항상 가져오는 것을 관찰했습니다.

JSON 파일에 대한 사전 로드 최적화 계획이 있습니까?
아마도 사용자가 페이지로 이동하려고 할 때 미리 로드하거나(즉, 사용자가 SSG 링크를 가리키고 있을 때) 링크 구성 요소에서 참조되는 다른 js 페이지를 미리 로드하는 것처럼 미리 로드할 수 있습니다.

그건 그렇고 그 기능을 사랑 해요!

JSON 파일에 대한 사전 로드 최적화 계획이 있습니까?

예.

그만한 가치가 있기 때문에 저는 별도의 파일보다는 이러한 함수의 트리 흔들림 내보내기를 선호합니다.

이 기능의 상태는 무엇입니까? 그것의 차단제는 무엇입니까?

@mikestopcontinues 이 RFC는 현재 우리 팀과 일부 선별된 파트너에 의해 내부적으로 과중하게 테스트되고 있습니다. 위에서 언급한 것처럼 unstable_ 접두사 를 사용하여 고도로 실험적인 동작 을 선택할 수 있습니다! 😄

API를 계속해서 업데이트할 수 있으므로 프로덕션 워크로드를 새로운 방법으로 마이그레이션하지 마십시오.

개인적으로 8~20K 페이지의 정적 사이트 생성에 사용합니다(일부 페이지에 동적 요청이 있을 수 있음). 매우 잘 작동합니다(Now의 10K 파일 제한 제외). 내가 부끄럽게 생각하는 유일한 것은 getStaticPaths 메서드가 없으면 다시 로드할 때마다 getStaticProps가 호출된다는 것입니다. 좋은 동작 중 하나는 첫 번째 호출에서 json 파일을 만들고 다음 호출에서 이를 사용한다는 것입니다.

증분 빌드가 계획되어 있습니까? 그래서 새로운/변경된 콘텐츠만 재구축됩니까?

위에서 언급한 것처럼 unstable_ 접두사 를 사용하여 고도로 실험적인 동작 을 선택할 수 있습니다!

unstable_getServerProps 메서드를 테스트하고 싶지만 현재로서는 무시되고 zeit/next.js 리포지토리에서 찾을 수 없습니다. 아직 구현되지 않았습니까, 아니면 제가 잘못하고 있습니까?

증분 빌드가 계획되어 있습니까? 그래서 새로운/변경된 콘텐츠만 재구축됩니까?

구현은 증분 재구축을 염두에 두고 설계되었지만 아직 지원되지 않습니다(이 RFC에서도 다루지 않음).

안심하십시오. 아키텍처가 준비되었으며 이러한 기능이 안정화된 후 이를 탐색할 것입니다.
이것이 getStaticProps 가 전체 애플리케이션에 대해 한 번이 아니라 페이지당 정의되는 이유입니다!

불안정한_getServerProps 메서드를 테스트하고 싶지만 현재로서는 무시되는 것 같습니다 [...]

getServerProps 은(는) 아직 미리 보기에서 사용할 수 없습니다. 죄송합니다.

getServerProps 은(는) 아직 미리 보기에서 사용할 수 없습니다. 죄송합니다.

감사합니다. 나는 확실히 이 스레드를 볼 것입니다. 왜냐하면 그 땅에 도착하면 단일 함수의 이름을 바꾸는 것으로 대체할 수 있는 _다발_ 코드가 있기 때문입니다! 😍

getServerProps / getStaticProps 를 현재 사용할 수 있는지 여부는 100% 확실하지 않습니다.

이 스레드 기반: 아니요

그러나 그렇다면 next build 를 실행할 때 내 터미널이 아직 사용할 수 없는 경우 이를 언급한 이유가 무엇입니까? 메시지를 보고 이러한 방법이 프로덕션 단계에 있다는 초기 작업 가정이 남았고 그렇지 않다는 것을 발견하는 데 시간이 걸렸습니다. 이유가 궁금하거나 제가 잘못 이해하고 있는 부분이 있는지 궁금합니다.

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)
●  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)

(다음 버전 9.1.6에서)

감사 해요

@stevenjchang pages/**/*.js 에서 다음 구문을 사용하여 사용할 수 있습니다.

export function unstable_getStaticPaths() {} // return [{params: {...}}, ...]
export function unstable_getStaticProps({params: {...}) {} // return {props: {...}}

그리고 추가해야 할 것은 훌륭하지만 dev 서버를 사용할 때 여전히 가장자리가 약간 거칠기 때문입니다.

dev 서버를 사용할 때 여전히 가장자리가 약간 거칠지만.
@mikestopcontinues

이에 대해 자세히 설명해 주시겠습니까? 다른 누구도 dev 서버 경험에 대해 부정적인 피드백을 제공하지 않았으며 우리는 이 문제를 해결하고 싶습니다!

@Timer 새로운 API가 정말 마음에

"모든 로드 시"는 페이지 로드를 의미합니까? 아니면 재건? 또는...?

@mmmeff 같은 경로로 이동할 때마다 json을 다시 요청합니다. 따라서 두 페이지 사이를 앞뒤로 클릭하면 데이터를 기다리는 데 많은 시간을 할애하게 됩니다.

@mikestopcontinues 이것은 가장 최신 데이터가 개발 단계에서 선호되는 경우가 많기 때문에 의도된 동작입니다. 새로운 문제에서 더 나은 발견적 방법에 대해 논의할 수 있습니다!

@timneutkens 이 RFC는 매우 유망해 보입니다. 보안과 정확히 어떻게 작동하는지에 대한 몇 가지 질문/우려 사항이 있습니다.

SSR과 SSG 모두에 의존하는 일반적인 비즈니스 사례를 살펴보겠습니다.

문맥

우리는 웹사이트(일명 "앱")에 일부 정보를 표시하고자 합니다.
이러한 정보는 GraphQL API를 통해 액세스할 수 있는 BDD에 저장됩니다.
이러한 정보 중 일부는 공개되고 일부는 비공개입니다(예: 사용자 이메일/비밀번호).

앱은 두 단계를 사용합니다.

• 고객이 스테이징 앱에서 실시간 변경 사항을 볼 수 있는 "스테이징" 단계(백오피스 등을 통해 이러한 정보를 업데이트함)
• 고객이 액세스 권한이 없고 스스로 업데이트할 수 없는 "프로덕션" 단계입니다. 프로덕션 앱을 업데이트하려면 새로 배포해야 합니다. (백오피스에서 새로운 프로덕션 배포를 요청함)

이 시나리오에서는 SSR과 SSG를 모두 사용합니다.

• 스테이징 앱은 GraphQL API에서 실시간으로 데이터를 가져오기 때문에 SSR을 사용합니다(페이지 빌드 시).
• 프로덕션 앱은 SSG를 사용합니다. 새로운 배포가 이루어지면 GraphQL API에서 데이터를 가져와서 정적 페이지를 생성하기 때문입니다. 런타임 시(적어도 페이지를 로드할 때는 아님))

이 시나리오는 충분히 일반적이어야 하며 (IMHO) SSG 사용의 주요 사용 사례 중 하나여야 합니다.
프로덕션 앱은 스테이징 앱의 스냅샷에 불과합니다.

몇 가지 질문:

1. 이 RFC로 가능 합니까? 동일한 앱이 주어진 "단계"(프로덕션/스테이징)에 따라 다르게 작동하도록 하는 것
2. GraphQL API에서 가져온 데이터는 어떻게 주입됩니까?
   
   
   
   • 스테이징에서는 사용자가 페이지를 탐색할 때 SSR 또는 CSR을 통해 동적으로 가져옵니다(CSR 중에 가져온 경우 브라우저에서 사용할 수 있음).
   
   
   • 프로덕션에서는 빌드 시 가져오지만 JS 전역 변수에 저장되므로 누구나 읽을 수 있습니까? (보안 문제, CSR을 사용할 때 수행되는 방식과 유사하게 브라우저에서 사용할 수 있는 민감한 데이터를 가져오지 않도록 주의해야 함)
   
   
3. 혼합 SSR/SSG를 사용하는 이 접근 방식에 대해 우려 사항이 있습니까? (보안, 성능, 유지보수성 등)

이거 언제 출시할 예정인가요? 주요 업데이트(v10)가 될 것입니까, 아니면 이전 버전과 호환되는 업데이트가 될 것입니까?

이봐,

사용자 정의 서버로 이 솔루션을 시도하고 작동시키는 사람이 있습니까?

예시:

// server.js

const express = require('express');
const next = require('next');

const port = parseInt(process.env.PORT, 10) || 3000;
const dev = process.env.NODE_ENV !== 'production';
const app = next({ dev });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();

  server.get('/blog/:id', (req, res) => {
    console.log('My params needed be passed to page:', req.params);
    return app.render(req, res, '/blogDetail', { id: req.params.id });
  });

  server.listen(port, err => {
    if (err) throw err;
    console.log(`> Ready on http://localhost:${port}`);
  });
});

// blogDetail.js
export async function unstable_getStaticProps(props) {
  console.log('What is passed', props);

  return {};
}

const BlogPostPage = ({ post }) => {
  return <div>Hey</div>;
}

export default BlogPostPage;

# Terminal output

My params needed be passed to page: { id: 'test' }
What is passed { params: undefined }

getStaticProps 에 쿼리 문자열을 포함할 수 없는 이유는 무엇입니까? 현재 다시 렌더링하지 않고 쿼리 매개변수를 얻기 위해 SSR을 수행해야 하는 페이지가 있습니다. useRouter 후크를 사용하면 쿼리가 처음에 빈 개체이기 때문에 여러 번 다시 렌더링됩니다. 이것은 전환 추적에 사용되는 페이지이므로 당연히 시작 단계가 아닙니다.

@pjaws RFC는 getStaticProps 가 정적 생성을 위한 것이라고 구체적으로 언급합니다. 정적 HTML은 쿼리 문자열을 받을 수 없습니다.

그렇다면 동적 URL 매개변수를 수신할 수 있는 이유는 무엇입니까? 그게 어떻게 다른가요?

2020년 1월 14일 화요일 오전 1시 30분 Tim Neutkens [email protected]
썼다:

@pjaws https://github.com/pjaws 특별히 언급하는 RFC
getStaticProps는 정적 생성을 위한 것입니다. 정적 HTML은 수신할 수 없습니다.
쿼리 문자열.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/zeit/next.js/issues/9524?email_source=notifications&email_token=AMVRRIQCKDJNF4MPWSLYNV3Q5WA2NA5CNFSM4JRPBEL2YY3PNVWWK3TUL52HS4DFVREXG43VMXHJ63LDNMV
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AMVRRIRJXLYC4MC4U7DH7NDQ5WA2NANCNFSM4JRPBELQ
.

getStaticPaths 에서는 빌드 시 렌더링될 페이지를 반환해야 하기 때문입니다.

이러한 변화는 언제나처럼 매우 유망하고 훌륭한 작업으로 보입니다! 👍

페이지 간에 공유되는 데이터 요구 사항을 충족하기 위해 getInitialProps in _app.js 를 사용하는 경우(예: 컨텍스트 제공자 설정)에 대해 궁금합니다. 같은 방식으로 getStaticProps 를 사용할 수 없다는 것을 올바르게 이해하고 있습니까? 개별 페이지에서만 정의할 수 있습니까?

페이지 간에 공유되는 데이터 요구 사항(예: 컨텍스트 공급자 설정)을 충족하기 위해 _app.js에 getInitialProps가 있는 사용 사례가 궁금합니다. getStaticProps를 같은 방식으로 사용하는 것이 불가능하다는 것을 올바르게 이해하고 있습니까? 개별 페이지에서만 정의할 수 있습니까?

맞습니다. 처음에는 개별 페이지에만 적용됩니다. 나중에 다시 생각해 볼 수도 있습니다. _app의 getInitialProps는 정적 HTML로 내보낼 때 계속 호출되므로 getStaticProps로 점진적으로 이동할 수 있습니다.

안녕하세요 여러분, 관련 질문 하나 - 자산은 어떻게 처리됩니까? 헤드리스 CMS(심지어 wordpress 또는 graphcms 등)를 사용하는 경우 자산 URL이 정적 html에서 사용된다는 것을 지금 보고 있기 때문입니다.

여기에는 자산 링크가 그대로 사용되는 두 가지 기본 설정이 있습니다.
그러나 더 가능성이 높습니다. 자산을 다운로드하고 html을 빌드(로컬로 링크)한 다음 앞에 CDN을 계층화합니다. 이것은 훨씬 더 수용 가능한 관행입니다.

이것은 또한 Netlify와 같은 배포 시스템을 사용하는 것과도 매우 잘 연결됩니다. Netlify는 DatoCMS 또는 Graphcms와 같은 것보다 훨씬 더 적합한 전 세계적으로 사용 가능한 인프라를 갖추고 있습니다. 따라서 Netlify를 배포로 사용하는 경우 Netlify 도메인에서 모든 것이 제공되고 마법이 작동하도록 하고 싶습니다.

@sandys https://github.com/zeit/next.js/issues/9054#issuecomment -570427085에서 올바르게 이해했다면 자산을 다운로드하고 .next/static 아래에 저장하고 링크를 구축해야 합니다. getStaticProps 있습니다.

정적 API 경로가 있다는 아이디어도 있지만 이를 사용하여 브라우저 캐싱 동작을 제어하는 ​​방법을 정확히 모르겠습니다.

@Janpot 링크

이 기본 제공에 내 요청을 추가하십시오. 아마도 #9054가 더 일반적이지만 SSG의 관점에서 생각하고 있으며 이것은 매우 중요합니다.

언급하는 것을 잊었지만 자산 해싱도 SSG에 필수적입니다.

@homoky , 그 동안 제대로 작동하지 않았습니까?

@homoky , 그 동안 제대로 작동하지 않았습니까?

불가능하고 계획도 없습니다: #10071

😢

@sandys 실제로 솔루션은 https://github.com/zeit/next.js/issues/9081 을 사용하여 예를 들어 /images 에서 CMS로 재작성을 추가할 때 훨씬 간단합니다. 예: ZEIT에서 이제 올바른 헤더가 추가되면 결과를 이미 캐시하므로 추가 다운로드가 필요하지 않습니다(빌드 시 막대한 오버헤드).

@timneutkens 답변
당신이 의미하는 바를 완전히 확신하지 못합니다. 그래서 우리는 netlify를 사용합니다. CMS URL을 그대로 유지하고 그 위에 CDN 레이어를 앞에 두라는 제안입니까?
netlify(우리가 사용할 클라우드프론트)가 이러한 모든 서비스와 원활하게 작동할 수 있는지 확신할 수 없습니다.

이미지가 다운로드되어 배포의 일부가 되면 이 전체 문제가 크게 단순화됩니다. 기본 URL(내 경우에는 s3에서 제공됨)에서 캐시하도록 CDN을 설정했기 때문입니다.

Zeit NOW를 사용하여 귀하의 솔루션이 저에게 근거한 것인지 완전히 확신할 수 없습니다.

이미지가 다운로드되어 배포의 일부가 되면 이 전체 문제가 크게 단순화됩니다. 기본 URL(내 경우에는 s3에서 제공됨)에서 캐시하도록 CDN을 설정했기 때문입니다.

이것은 실제로 빌드 프로세스를 훨씬 더 복잡하고 10배 더 느리게 만듭니다. 확실히 단순하지는 않습니다.

Zeit NOW를 사용하여 귀하의 솔루션이 저에게 근거한 것인지 완전히 확신할 수 없습니다.

전 세계의 모든 프록시와 함께 작동합니다. 클라우드 프론트 포함.

@timneutkens 우리는 실제로 빌드 프로세스 시간에 불가지론적입니다. 더 오래 걸리더라도 상관 없습니다. 그러나 여러 가지 이유로(알려진 기본 URL에서 제공되는 모든 자산을 포함하여) 이를 빌드에서 굽는 것이 매우 바람직합니다.

모든 사람을 위해 이 기능을 켜야 한다고 주장하는 것은 아닙니다. 많은 사람들이 CMS로의 딥링킹에 만족할 것입니다. 그러나 우리는 트래픽이 많은 사이트를 운영하고 있으며 이것은 확실히 우리와 같은 사이트에 필요한 것입니다.

또한 나를 용서하지만 나는 당신의 해결책을 이해하지 못했습니다. 이것을 어떻게 구성해야 합니까? CMS가 사용하는 URL을 제어할 수 없습니다. 예를 들어, Datocms는에서 제공 시작 www.datocms-assets.com/ . #9081의 솔루션을 어떻게 사용합니까?

우리는 실제로 빌드 프로세스 시간에 불가지론적입니다. 더 오래 걸리더라도 상관없어

이것은 귀하의 응용 프로그램에 해당될 수 있지만 대부분의 응용 프로그램에는 해당되지 않습니다.

그러나 여러 가지 이유로(알려진 기본 URL에서 제공되는 모든 자산을 포함하여) 이를 빌드에서 굽는 것이 매우 바람직합니다.

실제로 말한 대로일 필요는 없습니다. /images/* 를 cms URL로 프록시하는 재작성을 사용할 수 있습니다(예 www.datocms-asset.com/* 또는 이와 유사한 것). 그런 다음 /images 사용하여 모든 이미지를 연결합니다.

이것은 주제에서 벗어나기 시작했습니다.

@sandys 실제로 솔루션은 #9081을 사용하여 예를 들어 /images에서 CMS로 다시 쓰기를 추가할 때 훨씬 간단합니다. 예: ZEIT에서 이제 올바른 헤더가 추가되면 결과를 이미 캐시하므로 추가 다운로드가 필요하지 않습니다(빌드 시 막대한 오버헤드).

@timneutkens 나를 위해 명확하게하기 위해. 이상적인 상황에서는 이미지를 해시하고 브라우저에서 고유한 URL로 영구적으로 캐시하고 콘텐츠 작성자는 CMS에서 동일한 이름으로 원할 때마다 파일을 업데이트할 수 있습니다. 즉, 제안한 설정에서 CMS가 다음을 담당해야 함을 의미합니다.

1. 이미지 최적화
2. 이미지를 해싱하고 이 해시로 제공
3. 이미지 URL에서 getStaticProps 에서 다운로드할 수 있는 해시된 이미지 URL로의 맵을 제공하여 이미지 URL을 CMS의 변경할 수 없는 대응물에 다시 매핑합니다.

불가능하지는 않은 것 같아요. 이것이 제안된 설정인지 확인하고 싶을 뿐입니다.

@Janpot CMS 제공업체는 이미 이미지 등에 고유한 URL을 제공하여 이를 처리하고 있습니다.

이것은 귀하의 응용 프로그램에 해당될 수 있지만 대부분의 응용 프로그램에는 해당되지 않습니다.

다시 말하지만, 나는 여기 혼자가 아닙니다. 비슷한 요청이 많이 있습니다. 나는 당신이 이것을 고려하기를 요청합니다.

https://spectrum.chat/next-js/general/how-would-you-handle-importing-remote-images-on-nextjs-static-export~30b2ba84-bc27-4da7-9ec8-21e4d5d287a3

개츠비 측에서도 - https://github.com/gatsbyjs/gatsby/issues/14076

https://spectrum.chat/gatsby-js/general/adding-remote-images-during-node-creation~e704e6fb-24b2-46c6-b1fc-93189d2e28a4

https://github.com/njosefbeck/gatsby-source-stripe/#다운로드 파일

@sandys 이것은 SSG RFC와 관련이 없으므로 릴리스되면 새로운 문제를 자유롭게 생성하십시오.

그러나 우리의 모든 생각에서 이것은 SSG와 밀접하게 관련되어 있음을 언급하고 싶었습니다. 이상적인 경우는 SSG 내보내기 명령이 이를 수행하는 것이기 때문입니다. 다른 경우에는 일반적으로 필요하지 않습니다.
가장 좋은 경우는 이것이 다음 내보내기 동안 선택적 기능인 것입니다.

그러나 원하는대로 결정을 존중하십시오.

하지만 지금은 next export 하지 않는 일입니다. 따라서 이것이 완전히 새로운 것이고 이 RFC와 관련이 없는 이유입니다.

또한 getServerProps 및 주문형 렌더링에서는 그렇지 않습니다.

@Janpot CMS 제공업체는 이미 이미지 등에 고유한 URL을 제공하여 이를 처리하고 있습니다.

👍 네, 맞습니다. 그러나 이는 또한 프로젝트에서 이미지를 사용하고 최적화 및 캐시하려는 경우 2가지 선택이 있음을 의미합니다.

1. 사용자 정의 웹팩 설정 빌드
2. 외부 CMS 사용

편집하다:

그리고 내가 올바르게 이해한다면 file-loader 는 이미 CSS에 포함되어 있습니다. JS에서도 가능하게 하는게 문제 아닌가요?

@Janpot Sandeep이 언급한 특정 요점은 URL이 프로젝트 자체가 아닌 외부 소스에서 제공된다는 것입니다. 기본적으로 파일 로더를 포함하는 것은 다른 기능 요청입니다.

ZEIT Now에 배포된 사이트의 경우 새로운 정적 API를 사용하는 동적 URL이 있는 페이지가 있을 때 unstable_getStaticPaths 사용하여 정적으로 생성되지 않은 페이지의 경우 unstable_getStaticProps 는 404를 반환하지 않고 런타임에 서버에서 실행됩니다.

예를 들어 getStaticPaths 가 배열을 반환하는 /blog/[slug].js 페이지가 있습니다.

[{ params: { slug: 'hello' } }]

내 getStaticProps 에는 슬러그를 기반으로 파일을 읽는 논리가 있습니다. /blog/hello 방문하면 페이지가 예상대로 미리 렌더링되지만 /blog/doesnt-exist 와 같은 잘못된 페이지를 방문하면 런타임에 getStaticProps 가 실행되고 오류 500이 발생합니다. a 404. 또는 오류 처리를 추가하면 getStaticPaths 의 출력에 나열되지 않음에도 불구하고 페이지가 404가 아닌 렌더링됩니다.

이 논리가 의도된 것입니까?

이것은 훌륭한 개선 사항입니다. 우리는 이 작업을 수행하기 위해 몇 가지 사전 빌드 스크립트를 작성하려고 했습니다.
Next 9.2에서 사이트 중 하나를 unstable_getStaticPaths 및 unstable_getStaticProps 이동하는 것을 테스트했는데 잘 작동했습니다.

exportPathMap 비해 회귀가 하나 있습니다. exportPathMap 사용하여 경로를 작성할 때 다음과 같이 지정할 수 있습니다.

{
 "/path/to/page": {page: "/index", query: { pageId: 123 } }
}

정적 빌드가 빌드됩니다.

/path
   /to
     /page
       index.html

[slug].jsx 템플릿의 unstable_getStaticPaths 에서 이에 상응하는 값을 반환하면

[{ slug: '/path/to/page' }]

다음 9.2는 중첩된 디렉터리 대신 '%2Fpath%2Fto%2Fpage'를 생성합니다.

/%2Fpath%2Fto%2F
   index.html

디렉토리 구축(기존 exportPathMap 동작과 일치)은 페이지 구축 방식에 중요합니다. 단일 템플릿 파일을 사용하지만 게시된 경로는 임의로 중첩될 수 있습니다.

@dpfavand 이 경우 포괄 경로를 사용하고 싶을 것입니다. https://nextjs.org/blog/next-9-2#catch -all-dynamic-routes

슬래시를 포함하는 경로를 반환하려고 할 때 잠재적으로 경고할 수 있지만 [slug].js 사용할 때 동작은 정확합니다. 귀하의 경우에는 [...slug].js 를 원합니다.

언제 착륙할 것으로 예상됩니까? 9.2 패치에 포함됩니까 아니면 자체 마이너 버전에 포함됩니까?

이 기능에 대한 모든 기대에 감사드립니다. 다른 곳에서 언급했듯이 우리는 일반적으로 기능이 올바른 개발자 경험, 제약 조건 및 미래 보장성을 갖도록 하기 위해 기능에 대한 일정을 공유하지 않습니다.

새로운 기능이기 때문에 마이너가 될 것입니다.

예, 일반적으로 이해하지만 9.1.7 블로그는
그것은 이미 야생에 있었다.

2020년 1월 17일 금요일 오후 5:05 Tim Neutkens [email protected]
썼다:

이 기능에 대한 모든 기대에 감사드립니다. 말한 바와 같이
다른 곳에서는 일반적으로 기능에 대한 타임라인을 공유하지 않습니다.
올바른 개발자 경험, 제약 조건 및 미래가 있는지 확인
증거성.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/zeit/next.js/issues/9524?email_source=notifications&email_token=ADKINGF724256WCEFHBFIH3Q6ITRXA5CNFSM4JRPBEL2YY3PNVWWK3TUL52HS4DFVEXG43VMVBW63LN
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ADKINGBVCG6MFMOG5U2FGMDQ6ITRXANCNFSM4JRPBELQ
.

>

라시터 그레그
[email protected] [email protected]
셀 (832) 495-9903

getStaticProps 것이 있지만 페이지당이 아니라 전체 앱에 대해 한 번만 실행되나요?

내 사용 사례는 여러 페이지에서 사용되는 React Context( PricingPlansContext )가 있고 빌드 시( next export 외부 서버에서 데이터(가격 책정 계획)를 한 번만 검색하기를 원한다는 것입니다. getStaticProps 에 추가하지 않아도 됩니다.

편집: https://github.com/zeit/next.js/issues/9524#issuecomment -574179540에서 관련 댓글을 찾았습니다. 그것이 고려되기를 바랍니다.

나는 그것을 위해 babel plugin-preval`을 사용합니다.
next.config.js를 사용하여 exportPathMa() 내의 json 파일을 가져옵니다.
그들의 코드 내에서.

지금은 npm 스크립트를 사용하여 json 파일을 작성했지만 exportPathMap을 제안해 주셔서 감사합니다.

@dpfavand 이 경우 포괄 경로를 사용하고 싶을 것입니다. https://nextjs.org/blog/next-9-2#catch -all-dynamic-routes

슬래시를 포함하는 경로를 반환하려고 할 때 잠재적으로 경고할 수 있지만 [slug].js 사용할 때 동작은 정확합니다. 귀하의 경우에는 [...slug].js 를 원합니다.

@timneutkens 후속 getStaticPaths , 그것은을 통해 전달되지 않습니다 getStaticProps 전혀. 슬러그 값을 배열로 반환할 때 값이 문자열이어야 하므로 빌드가 실패합니다.

사례 1, pages/[...slug].jsx 파일을 문자열로 가정:

export async function unstable_getStaticPaths() {
    return [{ params: { slug: 'en/about' } }];
}

export async function unstable_getStaticProps({ params }) {
    console.log('params', params);
    return { slug: params.slug };
}

위의 경우 params 의 getStaticProps 는 slug 키가 없는 빈 개체입니다.

사례 2, pages/[...slug].jsx , 슬러그를 배열로,

export async function unstable_getStaticPaths() {
    const allPaths = Object.keys(pathMap).map(slug => ({ params: { slug } }));
    return [{ params: { slug: ['en', 'about'] } }];
}
export async function unstable_getStaticProps({ params }) {
    console.log('params', params);
    return { slug: params.slug };
}

경우 2의 경우 빌드가 실패합니다.

> Build error occurred
{ Error: A required parameter (slug) was not provided as a string.
    at _validParamKeys.forEach.validParamKey (/project/node_modules/next/dist/build/utils.js:21:569)
    at Array.forEach (<anonymous>)
    at toPrerender.forEach.entry (/project/node_modules/next/dist/build/utils.js:21:495)
    at Array.forEach (<anonymous>)
    at Object.isPageStatic (/project/node_modules/next/dist/build/utils.js:17:122)
    at process._tickCallback (internal/process/next_tick.js:68:7) type: 'Error' }

위의 getStaticPaths 예제에는 경로 매개변수만 표시됩니다. 쿼리 매개변수를 포함하는 SSG 경로에 가능합니까? 예를 들어:

/store/widgets/circles-n-squares?sort=price&minWeight=2&color=black

저는 특히 URL의 pathname 에서 제품 검색의 모든 측면을 다루기 어려운 전자 상거래 사이트의 관점에서 생각하고 있습니다.

최근에 여기에 메시지를 게시했지만 답장을 받지 못했습니다. 본질적으로 getStaticProps 는 사이트가 ZEIT Now에 배포될 때 getServerProps 처럼 작동합니다(예: getStaticPaths 무시하고 요청 처리 동적으로) - 이것이 버그라고 생각합니까?

@dpfavand 저도 정확한 경험을 하고 있습니다! CMS의 페이지를 기반으로 하는 동적 페이지 라우팅을 사용하여 agilitycms 및 nextjs 를

@timneutkens 후속 getStaticPaths , 그것은을 통해 전달되지 않습니다 getStaticProps 전혀.

사례 1, pages/[...slug].jsx 파일을 문자열로 가정:

export async function unstable_getStaticPaths() {
  return [{ params: { slug: 'en/about' } }];
}

export async function unstable_getStaticProps({ params }) {
  console.log('params', params);
  return { slug: params.slug };
}

위의 경우 params 의 getStaticProps 는 slug 키가 없는 빈 개체입니다.

BTW, 작은 세계! fastr_conf에서 이야기해주셔서 다시 한 번 감사드립니다.

안녕하세요 @timneutkens 입니다 .

next.js가 정적 사이트 생성기처럼 작동하도록 하는 아이디어에 대해 매우 흥분됩니다.

많은 양의 데이터를 한 번 요청한 다음 다른 페이지를 생성하는 데 사용되는 경우 getStaticProps 및 getStaticPaths 메서드를 어떻게 사용할 수 있는지 묻고 싶습니다.

예를 들어 사용 가능한 모든 개체를 가져오는 메서드가 있는 API 기반 CMS의 JavaScript SDK 클라이언트를 사용하고 있습니다. 이러한 개체 중 일부는 사이트 페이지를 나타냅니다.

const entries = await cmsSdkCient.getEntries();

지금까지 exportPathMap 메서드를 사용하여 CMS에서 모든 항목을 한 번에 가져와 이 페이지의 경로와 해당 데이터 사이의 맵을 생성했습니다. exportPathMap 함수는 두 가지 작업을 수행합니다.

1. 내보낼 때 getInitialProps 에 의해 소비되는 데이터 및 ssr: true 가 있는 페이지 맵을 제공합니다.
2. 모든 페이지의 경로와 일치하는 폴더에 있는 init-props.json 파일에 이번에는 ssr: false 동일한 데이터를 씁니다. 그러면 클라이언트에서 getInitialProps 가 호출되면 일치하는 페이지의 init-props.json 에서 필요한 데이터가 로드됩니다.

module.exports = {
  exportTrailingSlash: true,
  exportPathMap: (defaultPathMap, { outDir }) => {
    // load data from CMS
    const objects = await cmsSdkCient.getEntries();

    // create map between page paths and page data
    return objects.reduce((accum, object) => {

      // if the object does not have a slug, it is not a page
      if (!object.slug) return accum;

      const pagePath = '/' + object.slug;
      const ssrQueryData = Object.assign({ ssr: true }, object);
      const clientQueryData = Object.assign({ ssr: false }, object);

      // generate the map for export phase with {ssr: true}
      accum[pagePath] = {
        // using additional fields from the page object,
        // the pageFromPagePath() computes which page file should
        // be used to render the page object
        page: pageFromPagePath(object),
        query: ssrQueryData
      };

      // write json files that will be loaded by client
      if (outDir) {
        const jsonFilePath = path.join(outDir, _.trim(pagePath, '/'), 'init-props.json');
        fse.outputFileSync(jsonFilePath, JSON.stringify(clientQueryData));
      }

      return accum;
    }, {});
  }
}

Index.getInitialProps = async (context) => {
  const ssr = _.get(context, 'query.ssr', false);
  if (ssr) {
    // we are on server, return the data
    return _.get(context, 'query', {});
  } else {
    // we are on client side, request the data through /init-props.json endpoint
    const url = context.asPath + '/init-props.json';
    return fetch(url).then(response => {
      return response.json();
    });
  }
};

getStaticProps 및 getStaticPaths 메서드를 사용하면 JSON 파일을 저장하고 클라이언트에서 로드하는 것과 관련된 코드를 많이 줄일 수 있다는 큰 이점을 볼 수 있습니다.

// pages/my_page.js
export async function getStaticProps(context) {
  const objects = await cmsSdkCient.getEntries();
  const props = _.find(object, { type: 'my_page' })
  return { props };
}

// pages/blog/[slug].js
export async function getStaticProps(context) {
  const objects = await cmsSdkCient.getEntries();
  const props = _.find(object, { type: 'post', slug: context.params.slug })
  return { props };
}

export async function getStaticPaths() {
  const objects = await cmsSdkCient.getEntries();
  return objects
    .filter(object => object.type === 'post')
    .map(object => ({ params: { slug: object.slug } }))
}

문제는 getStaticProps 또는 getStaticPaths 가 호출될 때마다 항목을 가져오는 대신 모든 항목을 한 번에 가져오도록 워크플로를 최적화하는 방법에 대한 질문입니다.

또 다른 질문은 이 문제와 반드시 관련이 있는 것은 아니지만 우리는 SSG 및 원격 데이터 소스의 세계에 있기 때문에 질문할 가치가 있습니다. next.js가 dev 모드에서 실행된다고 가정하면 원격 데이터를 다시 가져오고 사이트를 다시 빌드하기 위해 어떻게 next.js에 이러한 메서드를 다시 실행하도록 알릴 수 있습니까?

@smnh "그냥 JavaScript"이기 때문에 항목을 한 번 가져오고 데이터 가져오기 방법에 결과를 캐시할 수 있습니다. 다른 페이지의 getStatic* 메소드에서 다시 호출될 때 네트워크는 다시 적중되지 않습니다.

두 번째 질문은 자동으로 수행됩니다. next dev 실행하면 바로 실행됩니다.

위의 getStaticPaths 예제에는 경로 매개변수만 표시됩니다. 쿼리 매개변수를 포함하는 SSG 경로에 가능합니까? 예를 들어:

/store/widgets/circles-n-squares?sort=price&minWeight=2&color=black

저는 특히 URL의 pathname 에서 제품 검색의 모든 측면을 다루기 어려운 전자 상거래 사이트의 관점에서 생각하고 있습니다.

나는 이것이 ssg의 맥락에서 의미가 없다고 생각합니다. SSG는 모든 항목에 대해 파일을 출력합니다. 쿼리 매개변수는 파일 이름의 일부가 아니므로 요청을 실제 파일에 다시 쓰려면 서버 계층이 필요합니다. (위의 예에서 정적 파일 이름은 무엇입니까?) 기본 보기(패싯이 없는 페이지를 방문하면 얻을 수 있는 것)를 사전 렌더링하고 요청에 쿼리 매개변수가 있는 경우 클라이언트 측에서 업데이트하는 것을 고려하는 것이 좋습니다. 그러나 그것은 이 SSG RFC를 넘어서는 문제가 됩니다.

@dpfavand 저도 정확한 경험을 하고 있습니다! CMS의 페이지를 기반으로 하는 동적 페이지 라우팅을 사용하여 agilitycms 및 nextjs 를

@timneutkens 후속 getStaticPaths , 그것은을 통해 전달되지 않습니다 getStaticProps 전혀.
사례 1, pages/[...slug].jsx 파일을 문자열로 가정:

export async function unstable_getStaticPaths() {
    return [{ params: { slug: 'en/about' } }];
}

export async function unstable_getStaticProps({ params }) {
    console.log('params', params);
    return { slug: params.slug };
}

위의 경우 params 의 getStaticProps 는 slug 키가 없는 빈 개체입니다.

BTW, 작은 세계! fastr_conf에서 이야기해주셔서 다시 한 번 감사드립니다.

이봐! Nextjs 팀은 이 문제를 해결하기 시작했으며 현재 카나리아 구현과 관련된 몇 가지 추가 문제를 해결할 수 있는 티켓이 있습니다. https://github.com/zeit/next.js/issues/10190

@smnh 내가 하는 일은 빌드 + 내보내기를 실행하기 전에 공유 콘텐츠를 미리 가져오고 JSON에 저장하는 스크립트를 갖는 것입니다. 그런 다음 해당 JSON을 페이지에서 모듈로 직접 가져오기만 하면 됩니다.

재구축을 위해 관련 콘텐츠가 변경될 때 Netlify 빌드 후크를 트리거하도록 CMS에 웹후크를 설정했습니다. 그런 다음 GetStaticProps는 페이지 특정 콘텐츠를 가져올 수 있습니다.

@zeusdeux 감사합니다
답장:

두 번째 질문은 자동으로 수행됩니다. 다음 개발을 실행하면 됩니다.

모듈에 캐시한 다음 CMS에서 데이터를 변경하면 캐시가 무효화되고 dev 의해 다시 실행되지만 next.js를 중지하고 다시 실행하지 않습니다. :)

모듈에 캐시한 다음 CMS에서 데이터를 변경하면 캐시가 무효화되고 dev 의해 다시 실행되지만 next.js를 중지하고 다시 실행하지 않습니다. :)

getStaticPaths 는 프로덕션 빌드에서만 호출되므로 해당 함수에서 호출될 때 모듈 상태에서 캐시하도록 가져오는 메서드만 알릴 수 있습니다.

이봐, 나는 누군가가 나와 같은 문제에 직면했는지 보지 못했습니다.

unstable_getStaticProps 하여 여러 경로에 동일한 페이지가 있다고 가정해 보겠습니다.

1. /providers/[category]/[city] 
2. /providers/[category] 

소스 코드는 두 페이지 모두 동일하므로 복제할 필요가 없습니다. 따라서 첫 번째 파일에는 논리가 있는 소스 코드가 포함되어 있고 두 번째 파일은 export { default } from './[city]'; 와 같은 첫 번째 파일만 가져옵니다.

그러나 getStaticProps의 데이터가 정의되지 않았다는 오류가 발생합니다. 동일한 코드를 두 파일에 모두 복사하면 작동합니다.

@homoky 메소드를 다시 내

export { default, unstable_getStaticProps } from './[city]';

나는 SSG를 시도했지만 운이 없었습니다.

v9.2.1이 포함된 아래 코드는 SSG를 생성해야 합니까?

function Page({ stars }) {
  return <div>Next stars: {stars}</div>
}

Page.unstable_getStaticProps = async ctx => {
  return { props: { stars: 5 } }
}

export default Page

next build 내 콘솔 출력은 다음을 보여줍니다.

Page                                                           Size     First Load
┌ ○ /                                                          354 B       72.1 kB
...
λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)
●  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)

@joostmeijles unstable_getStaticProps 는 페이지 구성 요소에 첨부되는 대신 내 보내야 합니다. 예:

export const unstable_getStaticProps = async () => {
  return {
    props: { stars: 5 }
  }
}

@joostmeijles unstable_getStaticProps 는 페이지 구성 요소에 첨부되는 대신 내 보내야 합니다. 예:

export const unstable_getStaticProps = async () => {
  return {
    props: { stars: 5 }
  }
}

덕분에 해결되었습니다.

이에 대한 종단 간 작업 예를 보고 싶은 사람이 있으면 포괄 경로 및 SSG를 사용하여 동적 페이지(CMS에서) 생성 https://github.com/agility/agilitycms-next-starter-를 확인

나는 몇 번 당황했고 이것이 다른 사람들에게 도움이 될 수 있다고 생각했습니다.

zeit.co/now에 배포할 때 getStaticProps 빌드하는 동안 다음 API 경로에 액세스하려면 어떻게 해야 합니까? Isomorphic-fetch에는 절대 URL이 필요합니다. 로컬에서는 http://localhost :3000에서 작동하지만 지금 배포에서는 작동하지 않습니다(또는 내가 잘못했습니다 🤷‍♂️). 어떤 아이디어?

내 말이 맞다면 API 경로가 서버리스 기능으로 배포될 것이고 빌드 프로세스 중에 준비되지 않은 것 같습니까?

http를 통해 이동하는 것보다 훨씬 적은 오버 헤드로 API 경로의 기능을 직접 호출하고 싶을 것입니다.

http를 통해 이동하는 것보다 훨씬 적은 오버 헤드로 API 경로의 기능을 직접 호출하고 싶을 것입니다.

해당 주제에 대한 문서에서 읽을 수 있는 리소스가 있습니까? 저는 zeit.co/now로 마이그레이션하는 중입니다 :)

말 그대로 함수를 가져오고 호출합니다.

import MyFunction from '../lib/somewhere'


export async function /* unstable_ */getStaticProps() {
  const result = await MyFunction()
}

또 다른 질문: getStaticProps / getStaticPaths 및 getServerProps 나란히 사용할 수 있습니까? 예를 들어 SSG로 일부 페이지를 미리 렌더링했지만 CDN 캐시에서 찾을 수 없는 경우 요청 시 페이지를 생성하기 위해 SSR로 대체됩니까?

getStaticProps 는 SSR로 대체하고 결과를 캐시에 추가합니다.

getStaticProps 는 SSR로 대체하고 결과를 캐시에 추가합니다.

@lfades , 내가 당신을 올바르게 이해한다면 나는 그것에 대해 매우 😍 왜냐하면 미리 수천 페이지를 찾아 생성하는 대신 인기있는 페이지 몇 개를 미리 렌더링 할 수 있기 때문입니다.

하지만 이해를 돕기 위해... /products/[productId].js 동적 경로 페이지가 있다고 가정해 보겠습니다. 내가 제공하는 경우 getStaticProps , 그리고 결과의 제한된 수의 getStaticPaths 경우, 당신은 말을하는지 /products/123 CDN에 캐시에서 발견되지는 년후 때문에 '( t in getStaticPaths ), SSR로 돌아가 getStaticProps 실행한 다음 결과를 정적 페이지로 캐시합니까?

후속 질문: getStaticPaths 를 전혀 제공하지 않아도 작동합니까?

@flintinatux 예, 그렇습니다 👍

getStaticProps는 SSR로 폴백하고 결과를 캐시에 추가합니다.

getStaticProps 는 res 개체를 변경하는 것을 허용하지 않기 때문에 404를 수행할 방법이 없기 때문에 이것은 문제입니다. 함수 호출 중에 오류가 있으면 200 또는 500이 됩니다.

변경될 예정인가요?

@davidbailey00은 정적 웹사이트를 만들 때 404 페이지에 이미 404 상태 코드가 없습니다.

물론 전체 정적 내보내기를 수행하면 모든 것이 파일일 뿐이므로 상태 코드를 수행할 방법이 없습니다. ZEIT Now에 getStaticProps 를 사용하여 하이브리드 사이트를 배포하는 것에 대해 이야기하고 있습니다. 이것에 관계없이 동적 경로와 일치하는 모든 페이지를 강제로 렌더링하기 보다는 getStaticPaths 존중하고 404페이지를 제공해야 하는 것 같습니다.

Now 에서만 작동하는 것이 아니라 next start 합니다.

하지만 앞서 말한 대로 반복하겠습니다. 이것은 실험적 이며 여전히 동작이 변경될 수 있습니다.

그러나 getServerProps 또는 getInitialProps 404페이지를 제공할 수 있습니다. 응답 코드를 고려할 때 getStaticProps 가 getStaticPaths 무시하면 관심을 갖는 사이트에서는 완전히 실행 불가능합니다. 좋은 SEO.

상태 코드를 처리하는 더 많은 방법을 소개할 것이지만 대부분의 정적 사이트(예: CRA)는 /* 를 index.html 로 라우팅합니다. 여기서 404는 여전히 200입니다.

안녕하세요 여러분, 질문이 있습니다. 새로운 [unstable_]getStaticProps 를 사용하여 일부 페이지를 SSG하는 간단한 웹사이트를 만들고 있습니다. amp 를 제외하고 지금까지 모든 것이 잘 작동합니다.

페이지에 [unstable_]getStaticProps 포함되어 있으면 amp 가 비활성화됩니다. 다음 v9.2.1에서 다음을 확인할 수 있는 간단한 예입니다.

import React from "react";
import { useAmp } from "next/amp";

export const config = { amp: `hybrid` };

const AmpExample = ({ date }) => {
  const isAmp = useAmp();
  return (
    <>
      <p>
        Welcome to the {isAmp ? `AMP` : `normal`} version of the Index page!!
      </p>
      <p>date: {date}</p>
    </>
  );
};
/**
 * If I get the dynamic data from getStaticProps,
 * page is SSG render but AMP is disabled when accessing
 * with `/ampExample?amp=1`
 */
export async function unstable_getStaticProps() {
  return {
    props: {
      date: new Date().toISOString(),
    },
  };
}

/**
 * If I get the dynamic data from getInitialProps,
 * page is SSR render but AMP is disabled when accessing
 * with `/ampExample?amp=1`
 */
// AmpExample.getInitialProps = () => {
//   return { date: new Date().toISOString() }
// }
export default AmpExample;

데이터가 있는 SSG 페이지와 amp 작동하는 방법을 이해하는 데 도움이 되셨나요?

안녕하세요, App 구성 요소( _app.tsx ), 즉 빌드 단계에서 모든 페이지 구성 요소에 대한 공통 데이터를 가져오는 것과 같은 경우에 대해 getStaticProps 를 지원하는 방법은 무엇입니까?

안녕하세요, App 구성 요소( _app.tsx ), 즉 빌드 단계에서 모든 페이지 구성 요소에 대한 공통 데이터를 가져오는 것과 같은 경우에 대해 getStaticProps 를 지원하는 방법은 무엇입니까?

@pkral78 실제 개발 상황에서 해결 방법을 말씀드릴 수 있습니다.

"고차 구성 요소(HOC)로서의 레이아웃" 접근 방식으로 레이아웃을 만들었습니다(더 이상 학습 문서 🤷‍♂️에 없음).

어쨌든 다음과 같은 레이아웃을 만들었습니다(예시).

import React from "react";
import Head from "next/head";

const withSSGLayout = Page => {
  const WithSSGLayout = props => {
    return (
      <>
        <Head>
          <title>My Web Page</title>
          <link rel="icon" href="/favicon.ico" />
          <meta name="viewport" content="width=device-width, initial-scale=1" />
          <link
            href="https://fonts.googleapis.com/css?family=Roboto:400,700&display=swap"
            rel="stylesheet"
          />
        </Head>
        <Page {...props} />
      </>
    );
  };

  WithSSGLayout.unstable_getStaticProps = async () => {
    const pageStaticProps = Page.unstable_getStaticProps
      ? await Page.unstable_getStaticProps()
      : {};

    // Here you can make parent level queries too
    return {
      props: {
        ...pageStaticProps.props,
        parentProp: `dynamic prop-${new Date().toISOString()}`,
      },
    };
  };
  return WithSSGLayout;
};

export default withSSGLayout;

그런 다음 이 접근 방식을 사용하려는 페이지에서 HOC를 간단히 추가할 수 있지만( [unstable_]getStaticProps 및 amp가 함께 작동하지 않는 것을 명시적으로 내보내야 함) 높은 수준의 요청을 갖는 "좋은 방법"을 찾았습니다. 페이지당 SSG 쿼리.

import React from "react";
import withSSGLayout from "../hocs/withSSGLayout";

export const config = { amp: `true` };

const Index = props => {
  const { date, parentProp } = props;
  return (
    <div>
      <h1>Example</h1>
      <h3>Local Prop?: {date}</h3>
      <h3>Parent Prop?: {parentProp}</h3>
    </div>
  );
};

// In theory you could do direct database queries
Index.unstable_getStaticProps = async () => {
  // Here you can make page level queries
  return {
    props: {
      date: new Date().toISOString(),
    },
  };
};
const IndexHOC = withSSGLayout(Index);

export const { unstable_getStaticProps } = IndexHOC;
export default IndexHOC;

좋은 접근 방식이라면 언더핸드하고 싶습니다. 제 경우에는 이 기술을 사용하여 부모의 링크와 페이지 콘텐츠의 페이지 콘텐츠를 쿼리합니다. 도움이 되기를 바랍니다.

@robertovg 코드가 트리 흔들려서 모듈 수준에서 내

@timneutkens 이 작은 예에 대해 더 나은 솔루션을 제안할 수 있습니까? 어떤 식으로든 "레이아웃 수준 SSG 쿼리"와 "페이지 수준 SSG 쿼리"를 모두 사용하려고 했고 이 HOC 레이아웃 접근 방식에 대해 생각했습니다.

나를 위한 주요 제약은 SSG 페이지로 표시하기 위해 각 페이지에 있어야 하는 명시적으로 "[unstable_]getStaticProps 내보내기"였습니다.

amp + SSG 가 호환되는지 여부에 대한 추가 정보도 감사하겠습니다. 이전에 질문한 적이 있습니다.

감사합니다 🙏

@robertovg 먼저 데이터에서 레이아웃을 분리하므로 공유 레이아웃의 경우 다음과 같이 간단합니다.

import Layout from '../components/layout'

const Page = () => (
  <Layout>
    <h1>Hello World!</h1>
  </Layout>
)

export default Page

그리고 getStaticProps 경우 다른 모듈의 메서드를 사용하여 공유 데이터를 가져오므로 전체 예제는 다음과 같을 수 있습니다.

import fetchSharedData from '../lib/fetch-shared-data'
import Layout from '../components/layout'

export const unstable_getStaticProps = async () => {
  const sharedData = await fetchSharedData()
  const pageProps = {...}

  return {  props: { ...sharedData, ...pageProps } }
}

const Page = () => (
  <Layout>
    <h1>Hello World!</h1>
  </Layout>
)

export default Page

@robertovg 먼저 데이터에서 레이아웃을 분리하므로 공유 레이아웃의 경우 다음과 같이 간단합니다.

import Layout from '../components/layout'

const Page = () => (
  <Layout>
    <h1>Hello World!</h1>
  </Layout>
)

export default Page

그리고 getStaticProps 경우 다른 모듈의 메서드를 사용하여 공유 데이터를 가져오므로 전체 예제는 다음과 같을 수 있습니다.

import fetchSharedData from '../lib/fetch-shared-data'
import Layout from '../components/layout'

export const unstable_getStaticProps = async () => {
  const sharedData = await fetchSharedData()
  const pageProps = {...}

  return {  props: { ...sharedData, ...pageProps } }
}

const Page = () => (
  <Layout>
    <h1>Hello World!</h1>
  </Layout>
)

export default Page

이 솔루션을 보고 이해하지만 제가 제기하려고 했던 문제는 공유 데이터 사용량을 확장하는 방법이었습니다.
예를 들어, 경우에 가지고 <Header /> 용도 된 sharedData 링크를 얻기 위해 그가 헤드리스 CMS에서오고있다. <Header /> 를 <Layout /> 의 자식으로 소품이나 다른 솔루션으로 주입해야 합니다. 그리고 사용하려는 모든 페이지에 <Header /> 주입을 반복해야 합니다.

HOC 접근 방식 을 사용하면 <Header /> 한 번만 추가하면 됩니다.

그래서 가능한 한 코드 중복을 피하기 위해 @pkral78 에서 제기한 것이 좋은 지적이라고 생각한 이유입니다.

그래서 가능한 한 코드 중복을 피하기 위해 @pkral78 에서 제기한 것이 좋은 지적이라고 생각한 이유입니다.

그것은 내 마음에 있었다. _app 페이지에는 첫 번째 페이지 렌더링 중에 한 번 호출된 다음 저장된 props 를 다음 렌더링된 페이지로 전달하는 getStaticProps 있어야 합니다. 그러나 나는 그것이 과연 적절한 개념인지에 대해 여전히 생각하고 있다.

이런 종류의 것이 의도된 사용 사례인지 확실하지 않지만 작동하지 않는 것 같습니다.

// /pages/[...slug].jsx
import ReactDOMServer from "react-dom/server";

export async function unstable_getStaticProps({ params: { slug } }) {
  const filePath = "../content/" + slug.join("/") + ".mdx";
  const { default: Component } = await import(filePath);
  const content = ReactDOMServer.renderToStaticMarkup(<Component />);
  return {
    props: { title: slug.join(" "), content }
  };
}

export default function Page({ title, content }) {
  return (
    <div>
      <h1>{title}</h1>
      <div dangerouslySetInnerHTML={{ __html: content }} />
    </div>
  );
}

의도된 사용 사례가 아니더라도 약간 의심스러운 오류를 기록합니다.

[ warn ]  ./pages/[...slug].jsx
Critical dependency: the request of a dependency is an expression

편집하다:

오, 그래, 내가 할 때 해결된다

const { default: Component } = await import(`../content/${slug.join("/")}.mdx`);

https://codesandbox.io/s/happy-oskar-40bug

이것은 가져오기 파일 경로가 동적이라는 불평입니다.

2020년 1월 30일 목요일 00:29에 Jan Potoms [email protected]에서 다음과 같이 썼습니다.

이런 일인지 확실하지 않다.
https://codesandbox.io/s/nifty-cache-jspqr 은 의도된 사용 사례이지만
작동하지 않는 것 같습니다.

// /pages/[...slug].jsximport ReactDOMServer from "react-dom/server";
비동기 함수 내보내기 불안정_getStaticProps({ params: { 슬러그 } }) {
// 이것이 얼마나 안전한가?
const 파일 경로 = "../내용/" + slug.join("/") + ".mdx";
const { 기본값: 구성 요소 } = import(filePath)를 기다립니다.
const 내용 = ReactDOMServer.renderToStaticMarkup(구성 요소);
반품 {
소품: { 제목: slug.join(" "), 콘텐츠 }
};
}
기본 함수 내보내기 페이지({ 제목, 내용 }) {
반품 (

{제목}

);
}

의도한 사용 사례가 아니더라도 다음과 같은 오류를 기록합니다.
약간 의심스러운:

[경고] ./pages/[...slug].jsx
중요 종속성: 종속성 요청은 표현식입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/zeit/next.js/issues/9524?email_source=notifications&email_token=AAADKRKOL34WKTG7J5QFRJ3RAIGPBA5CNFSM4JRPBEL2YY3PNVWWK3TUL52HS4DFVREXG43VMXHJKTNMV0
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAADKRIWNA2DSMWFRGD453DRAIGPBANCNFSM4JRPBELQ
.

그래서 가능한 한 코드 중복을 피하기 위해 @pkral78 에서 제기한 것이 좋은 지적이라고 생각한 이유입니다.

그것은 내 마음에 있었다. _app 페이지에는 첫 번째 페이지 렌더링 중에 한 번 호출된 다음 저장된 props 를 다음 렌더링된 페이지로 전달하는 getStaticProps 있어야 합니다. 그러나 나는 그것이 적절한 개념인지 여전히 생각하고 있습니다.

@pkral78 , 내가 상상하는 대부분의 SSG 사이트에서 Next로 구현

내 유일한 관심사는 _app.js 넣으면 페이지에 따라 하나 이상의 "공통 부분"을 가질 수 없다는 것입니다. 내가 프로토타입을 만들고 있다는 아이디어로 레이아웃에 포함할 수 있기를 원했습니다. 렌더링하려는 페이지 유형에 따라 여러 레이아웃을 가질 수 있기 때문입니다. "그래서 withSSGLayout 를 호출했습니다. 내 HOC는 SSG 페이지뿐만 아니라 SSR과 완전한 클라이언트 기반 페이지, 또는 하나 이상의 SSGLayout을 가질 계획이었기 때문에 레이아웃이 상위 getStaticProps 메서드도 담당할 수 있다면 이 작업을 수행할 수 있습니다.

어쨌든 Next에 SSG가 있으면 모든 종류의 웹 사이트를 위한 도구가 됩니다 🙌

@Janpot 관련 https://github.com/zeit/next.js/issues/9524#issuecomment -580012327

import() 에서 동적 경로를 사용 하지 않는 것이 좋습니다. 경로 아래에 있는 모든 가능한 파일을 JS 번들로 묶고 그렇게 하면 빌드 성능이 크게 저하됩니다.

@timneutkens 물론이죠. 이해가 됩니다. getStaticProps 는 파일 시스템이 아닌 외부 API를 쿼리하기 위한 것입니까?

@Janpot 파일 시스템에서 읽을 수 있지만 종종 외부 API를 쿼리하게 됩니다.

@timneutkens 좋아요, @next/mdx 에 의존하는 대신 @mdx-js/runtime 를 사용하는 것이 더 좋습니다.

import ReactDOMServer from "react-dom/server";
import { promises as fs } from "fs";
import MDX from "@mdx-js/runtime";

export async function unstable_getStaticProps({ params: { slug } }) {
  const mdxContent = await fs.readFile(`./content/${slug.join('/')}.mdx`, {
    encoding: "utf-8"
  });
  const content = ReactDOMServer.renderToStaticMarkup(<MDX>{mdxContent}</MDX>);
  return {
    props: { title: slug.join(" "), content }
  };
}

export default function Page({ title, content }) {
  return (
    <div>
      <h1>{title}</h1>
      <div dangerouslySetInnerHTML={{ __html: content }} />
    </div>
  );
}

@잔팟 네! 일반 마크다운을 사용할 수도 있습니다. 이것이 우리가 nextjs.org/docs에서 하는 일입니다.

https://github.com/zeit/next.js/issues/9524#issuecomment -580207073에 관해서는 현재 SSR과 함께 Next를 사용하는 것과 동일합니다. 레이아웃 수준에서 수행되는 GraphQL 요청이 있으며 해당 콘텐츠는 앱의 공통 구성 요소(Navbar, 바닥글 및 동적 자식)와 공유됩니다. 그런 다음 동적 자식은 일반적으로 페이지별 콘텐츠에 대해 또 다른 GraphQL 요청을 합니다.

따라서 이것을 재사용하는 방법이 중요해 보입니다. 저는 이러한 공통 데이터를 가져오기 위해 각 페이지에 코드를 복제하고 싶지 않을 것입니다.

이봐!
나는 여기에서 아주 새롭다. 앱을 NextJS로 마이그레이션하는 작업을 막 시작했습니다.

이 기능의 이점을 얻을 수 있는 기본 사용 사례가 있습니다(다국어 버전). 내가 작업하고 있는 웹 앱에는 하루에 100,000회 이상의 페이지 조회수가 있는 16개 언어 버전이 있으며 예를 들어 방문 페이지를 정적으로 생성할 수 있다는 것은 환상적이지만 문제는 라우팅입니다.

서버 측 렌더링을 사용하면 요청 헤더 또는 쿠키를 읽고 적절한 언어 버전을 렌더링할 수 있지만 그것 없이는 /en, /de, /fr 및 "/"와 같은 모든 버전에 대한 경로를 생성하고 NextJS가 리디렉션만 하도록 만드는 유일한 솔루션입니까?

ReactDOMServer.renderToStaticMarkup 에 대해 배운 후 이를 unstable_getStaticProps 함수에 추가했으며 대화형 시간 및 최대 잠재적인 첫 입력 지연 시간을 대폭 개선한 덕분에 (모바일) PageSpeed ​​점수가 96에서 100으로 향상되었음을 알았습니다. .

JavaScript 없이 페이지를 방문할 수 있고 잘 로드되므로 SSG를 사용함에도 불구하고 React가 페이지 로드 작업을 수행하는 것으로 보입니다.

이것은 React에 대한 이해가 부족한 것일 수도 있지만 JavaScript를 사용하거나 사용하지 않는 성능은 동일할 것으로 예상하고 구성 요소를 사전 렌더링하는 것이 도움이 될 것이라고 기대하지 않습니다(SSG가 하는 일이라고 생각했습니다).

예상한 것입니까, 버그입니까, 아니면 제가 잘못하고 있는 것입니까?

사전 커밋: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2F5e310826bcf5030008a91209--josephduffynextjs.netlify.com%2Fposts%2Fgathered-1-0-1&tab=mobile
커밋: https://github.com/JosephDuffy/josephduffy.co.uk/pull/54/commits/d23898b874e5088ebcfabf577ee396b476ed97e4
커밋 후: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2F5e3371beda1b8f0009368ef9--josephduffynextjs.netlify.com%2Fposts%2Fgathered-1-0-1&tab=mobile

@JosephDuffy

따라서 React는 SSG를 사용함에도 불구하고 페이지 로드 작업을 수행하는 것으로 보입니다.

DOM에 수분을 공급하고 있습니다. 원래:

1. 브라우저는 브라우저 DOM에서 SSR html을 로드합니다.
2. React는 전체 가상 DOM을 재구축합니다.
3. React는 이러한 DOM을 탐색하고 동기화합니다(수화).

부작용이나 이벤트 핸들러가 없는 것처럼 콘텐츠가 진정으로 정적이라면 2단계와 3단계는 필요하지 않습니다. 귀하의 방법을 사용하면 기본적으로 구성 요소 트리를 1 속성을 가진 1 구성 요소로 줄입니다. 이는 React가 렌더링하고 수화하는 데 매우 빠릅니다. (+ dangerouslySetInnerHTM 는 수화 중 무시)

<div dangerouslySetInnerHTML={{ __html: props.htmlContent }} />

이벤트 핸들러와 부작용은 이 방법으로 작동하지 않습니다.

편집하다:

한 가지 아이디어는 getStaticProps 가 정적 html을 반환하는 경우 페이지에서 기본 내보내기를 생략할 수 있도록 하는 것입니다. 즉

export async function unstable_getStaticProps() {
  // ...
  return {
    props: { dangerouslySetInnerHTML: { __html: '<div>static content</div>' } }
  };
}

클라이언트 측에서 렌더링할 필요가 없기 때문에 next.js는 페이지에서 런타임을 제외하고 getStaticProps 반환한 html을 인라인할 수 있습니다. 그리고 next.js 루트 노드에서 dangerouslySetInnerHTML 가 사용된 것과 같은 방식으로 작동합니다.
나는 그것이 덜 강력하지만 부분적인 수화보다 구현하기가 더 쉬울 것이라고 생각합니다. 여기에서 React 자체의 용어를 재사용하면 이 기능이 작동하는 방식에 대한 혼란을 줄일 수 있습니다.

정적 사이트를 Next.js로 마이그레이션하려고 하며 블로그 게시물의 모든 .html 변형을 .html로 끝나지 않는 버전으로 리디렉션하고 싶습니다. getStaticProps 현재 컨텍스트를 얻지 못하는 것 같아서 들어오는 슬러그 및 리디렉션을 확인할 수 없습니다. getStaticProps 에 전체 컨텍스트가 있으므로 조건부 작업을 수행할 수 있으면 도움이 됩니다.

@nodabladam 사용자 지정 경로 RFC: #9081을 찾고 있는 것 같습니다.

해당 RFC를 사용하면 다음과 같이 정의할 수 있습니다.

// next.config.js
module.exports = {
  redirects() {
    return [
      // Redirect from the old HTML version of a blog post
      {
        source: "/blog/:post.html",
        destination: "/blog/:post",
        permanent: true
      }
    ];
  }
};

현재 experimental 키에서 이 기능을 사용해 볼 수 있습니다.

// next.config.js
module.exports = {
  experimental: {
    redirects() {
      // ...
    }
  }
};

내 프로젝트(약 8K 페이지)에 getStaticProps 및 getStaticPathNames를 구현했습니다.

그러나 출력 파일은 배포당 파일의 10K 제한에 포함됩니다. 8K 페이지의 경우 각 페이지에 json 파일도 있으므로 16K의 출력 파일을 얻을 수 있습니다.

이 한도를 늘릴 계획이 있습니까? 아니면 이 제한을 해결할 수 있습니까?

나도 같은 문제를 안고있어.
그들이 그 한도를 높이려고 한다는 것은 이해하지만 언제 배포될지는 모릅니다.

그래서 저는 모든 페이지에서 getStaticProps를 사용하고 그 중 일부에서만 getStaticPaths를 사용하며 작동합니다(제 제품 페이지는 전체 페이지의 70%를 생성하므로 getStaticPaths를 넣지 않았습니다). 한도에 머물고 있지만 완벽하지 않고 첫 번째로드가 상당히 길고 404 오류를 처리하기가 어렵습니다.

나도 같은 문제를 안고있어.
그들이 그 한도를 높이려고 한다는 것은 이해하지만 언제 배포될지는 모릅니다.

그래서 저는 모든 페이지에서 getStaticProps를 사용하고 그 중 일부에서만 getStaticPaths를 사용하며 작동합니다(제 제품 페이지는 전체 페이지의 70%를 생성하므로 getStaticPaths를 넣지 않았습니다). 한도에 머물고 있지만 완벽하지 않고 첫 번째로드가 상당히 길고 404 오류를 처리하기가 어렵습니다.

나는 그들이 곧 한도를 올리기를 희망하지만 그것이 20K가 아니기를 바랍니다. 장기적으로 나에게 충분하지 않을 것입니다.

getStaticPaths를 사용하여 첫 번째 로드 시간을 피하고 싶습니다. Zeit Now 외에 다른 솔루션을 찾아야 할 수도 있습니다.

Next.js는 getServerProps 호출 결과를 반환하는 API 끝점도 자동으로 노출합니다. [...] Next.js는 이 노출된 API 끝점을 가져와 페이지 클라이언트 측을 렌더링하는 데 필요한 소품으로 변환되는 JSON 데이터를 가져옵니다.

Next.js는 실제 경로 변경을 수행하고 페이지 구성 요소를 렌더링 하기 전에 이 끝점에서 데이터를 가져옵니다(적어도 기본적으로 다른 방법으로는 수행할 수 없음). 따라서 사용자는 특정 페이지가 정적으로 생성되어 매우 빠른 사이트를 경험할 수 있지만 SSR 페이지에 대한 링크를 클릭하면 경로가 변경되기 전에 갑자기 사이트가 잠시 "멈춤"됩니다.

로드 표시기, 애니메이션 자리 표시자 등으로 채울 수 있도록 구성 요소 _first_를 로드하는 권장 방법이 있습니까? (현재 페이지에 추가하는 대신.) 그렇지 않다면 새로 제안된 기능과 관련이 있을 수 있습니까? render 메소드 내부에 getInitialProps와 hooks 조합을 사용하여 달성했지만 지저분한 느낌이 듭니다.

많은 사람들이 이 UX 패턴(즉석 페이지 전환)을 선호한다고 생각하지만(대부분?) Next.js를 사용하는 예제는 아직 본 적이 없습니다. 프레임워크를 사용한지 며칠 되지 않았으니 틀린 부분이 있으면 지적 부탁드립니다.

새로운 기능이 정말 기대됩니다! 작업해주셔서 감사합니다.

@nicoqh , 현재 getInitialProps 에서 중단이 발생하기 때문에 페이지 전환에 대한 귀하의 우려는 SSG에만 국한되지 않습니다. 나는 nprogress 를 사용하여 다음 페이지가 로드되는 동안 최소한 맨 위에 진행률 표시줄을 표시하지만 설명하는 내용에 더 가깝게 들리는 합법적인 페이지 전환이 있는 이 예도 봅니다. 나는 그것을 직접 시도하지 않았지만 당신이 필요로하는 것에 도움이되기를 바랍니다.
https://github.com/zeit/next.js/tree/canary/examples/with-next-page-transitions

반환된 json 파일 /_next/data/BUILD_ID/<file>.json 이 assetPrefix를 존중하지 않는 것 같습니다. 이로 인해 내 프로덕션 환경에서 파일이 404가 됩니다. 왜냐하면 모든 _next가 CDN을 통과하는 자산이 될 것으로 예상하는 설정이 있기 때문입니다. 이러한 json 파일은 궁극적으로 assetPrefix(CDN)를 통해 라우팅되어야 합니다. 맞나요?

나도 같은 문제를 안고있어.
그들이 그 한도를 높이려고 한다는 것은 이해하지만 언제 배포될지는 모릅니다.
그래서 저는 모든 페이지에서 getStaticProps를 사용하고 그 중 일부에서만 getStaticPaths를 사용하며 작동합니다(제 제품 페이지는 전체 페이지의 70%를 생성하므로 getStaticPaths를 넣지 않았습니다). 한도에 머물고 있지만 완벽하지 않고 첫 번째로드가 상당히 길고 404 오류를 처리하기가 어렵습니다.

나는 그들이 곧 한도를 올리기를 희망하지만 그것이 20K가 아니기를 바랍니다. 장기적으로 나에게 충분하지 않을 것입니다.

getStaticPaths를 사용하여 첫 번째 로드 시간을 피하고 싶습니다. Zeit Now 외에 다른 솔루션을 찾아야 할 수도 있습니다.

@erhankaradeniz 및 @ziltosh 우리는 일반적으로 매우 빠른 시일 내에 이를 출시 해야 합니다. 최대한 빨리 도움을 받고 싶다면 저에게 직접 ping을 보내 거나

나도 같은 문제를 안고있어.
그들이 그 한도를 높이려고 한다는 것은 이해하지만 언제 배포될지는 모릅니다.
그래서 저는 모든 페이지에서 getStaticProps를 사용하고 그 중 일부에서만 getStaticPaths를 사용하며 작동합니다(제 제품 페이지는 전체 페이지의 70%를 생성하므로 getStaticPaths를 넣지 않았습니다). 한도에 머물고 있지만 완벽하지 않고 첫 번째로드가 상당히 길고 404 오류를 처리하기가 어렵습니다.

나는 그들이 곧 한도를 올리기를 희망하지만 그것이 20K가 아니기를 바랍니다. 장기적으로 나에게 충분하지 않을 것입니다.
getStaticPaths를 사용하여 첫 번째 로드 시간을 피하고 싶습니다. Zeit Now 외에 다른 솔루션을 찾아야 할 수도 있습니다.

@erhankaradeniz 및 @Ziltosh 우리는 일반적으로 매우 빠른 시일 내에 이를 출시 해야 합니다. 최대한 빨리 도움을 받고 싶다면 저에게 직접 ping을 보내 거나

@kvangundy 감사합니다
이 문제와 관련하여 Twitter에서 연락을 드렸습니다 ;-)

@erhankaradeniz 대신 [email protected]로 이메일을

@flintinatux , 팁 주셔서 감사합니다. 예제를 봤는데 데이터를 로드하기 전에 페이지 구성 요소를 로드하는 데 도움이 되지 않으므로 페이지 내 자리 표시자 등이 불가능합니다. 그래도 흥미로운 예입니다. 감사합니다!

이 문제에서는 다루지 않을 것 같습니다. 즉, 주제에서 벗어났으므로 논의할 다른 곳을 찾아보겠습니다. :)

getInitialProps를 getStaticProps & getServerProps 로 나누는 접근 방식이 훨씬 깔끔하다고 생각합니다! 이것이 우리의 사용 사례에 어떤 영향을 미치는지 질문이 있습니다.
우리는 2개의 개별 빌드를 만들고 싶습니다. 하나는 프로덕션 사이트용 정적 버전이고 다른 하나는 편집 환경용 SSR을 사용하는 버전입니다.

조건부로 getStaticProps vs getServerProps 를 빌드에 따라 정적 메서드로 첨부할 수 있다고 생각했습니다(https://github.com/zeit/next.js/issues/9524#issuecomment-와 유사). 558617056), 그러나 이것이 조건부로 그대로 내보낼 수 있는지 확실하지 않습니다. 빌드에 따라 동적/정적을 지원할 수 있다면 어떤 아이디어가 있습니까?

에 관해서:

• 로드 상태: https://github.com/zeit/next.js/issues/9524#issuecomment -581494508
  
  
  
  • 현재 작업 중입니다(#10424).
  
  
• 미리보기: https://github.com/zeit/next.js/issues/9524#issuecomment -582607806
  
  
  
  • 작업 중이며 추후 PR을 오픈할 예정이다.
  
  

RFC는 나중에 변경 사항을 반영하도록 업데이트되며 앱에서 실제 사용을 계속 반복합니다.

빌드 시 알 수 없는 경로를 잡기 위해 일종의 와일드 카드 경로를 사용하는 방법이 있는지 궁금합니다. 예를 들어 CMS 데이터에서 정적 페이지를 렌더링할 수 있다는 것은 멋진 일이지만 누군가 새 항목을 추가하면 어떻게 될까요? 나는 그것에 대한 정적 페이지가 없습니다. 이 문제는 오랫동안 내 머리를 긁적입니다.

정적 페이지 _pages/[slug].js_를 렌더링하기 위해 동적 경로를 설정했습니다. _getStaticPaths_는 정적으로 렌더링하려는 모든 페이지를 가져옵니다. _getStaticProps_가 있어 데이터를 쿼리하고 이를 렌더 함수에 전달합니다. _getStaticPaths_에 제공된 모든 페이지는 빌드 시 _.next/server/static_ 내부에서 HTML 파일로 렌더링됩니다. 엄청난!

이제 npm run start 및 이 페이지를 실행해야 합니다. 그러나 누락된 URL(예: _/foo_)을 요청하면 _.next/server/static_ 내부에 새로운 정적 HTML 및 JSON 파일이 생성됩니다. 이것은 좋지 않다. 다른 모든 URL을 _pages/_error.js_로 리디렉션하도록 서버를 만들려면 어떻게 해야 합니까?

https://github.com/zeit/next.js/issues/9524#issuecomment -582777067

우리도 그것을 다루고 있습니다.

이제 npm run start 및 이 페이지를 실행해야 합니다. 그러나 누락된 URL(예: /foo)을 요청하면 .next/server/static 내부에 새로운 정적 HTML 및 JSON 파일이 생성됩니다. 이것은 좋지 않다. 다른 모든 URL을 페이지/_error.js로 리디렉션하도록 서버를 만들려면 어떻게 해야 합니까?

이것은 여전히 ​​진행 중이며 현재로서는 예상치 못한 동작이 아닙니다.

실험적인 기능을 사용 중이며 동작은 언제든지 변경될 수 있음을 다시 한 번 알려드립니다. 안정적이지 않을 때 이것을 사용하는 동안 모든 버전 간에 상황이 변경되고 잠재적으로 중단될 수 있습니다.

@timneutkens 감사합니다! 불안정함을 이해합니다. 이것을 관리하는 방법을 알고 있습니까? 코드를 살펴보고 _unstable_getStaticProps_ 내부에 오류를 던지면 오류 페이지가 렌더링된다는 것을 알았습니다. 이것은 좋은 방법이 될 수 있습니다. _pages/_error.js_에 있는 그대로 오류를 전달하는 방법이 필요합니다. 404로 보내고 싶습니다. 이제 500으로 갑니다.

나는 이것을 다른 스레드에서 여러 번 게시했지만 "_error로 가는 것"은 예기치 않은 동작입니다. 현재 귀하의 페이지는 404 상태를 렌더링해야 합니다. 간단히 if(!data.something) { return <My404Component /> } 라고 말한 다음 My404Component 는 noindex 메타 태그를 설정해야 합니다.

진짜? 문서에는 404에 _pages/_error.js_를 사용하도록 명시되어 있습니다.

참조: https://nextjs.org/docs/advanced-features/custom-error-page

@jiv-e는 다음으로 인해 404초 동안 발생합니다.

• 페이지를 찾을 수 없음
• 파일을 찾을 수 없음

동적 경로가 있는 경우 내가 말한 것처럼 "404" 사례를 처리해야 합니다(예: https://nextjs.org/docs/advanced-features/custom-error-page#reusing -the-built-in-error-). 페이지

알았어요! 감사 해요!

getStaticProps 를 사용하여 빌드 시 번역/언어 키를 가져오고 싶습니다. 왜냐하면 그들은 한 달에 1-2번 또는 심지어 매년 변경될 가능성이 높기 때문입니다. 또한 DOM 내에서 JSON/props로 필요하지 않습니다. 문제는 키를 실제로 사용하는 구성 요소로 트리 아래로 전달하고 싶지 않다는 것입니다. 사용 사례에 적합한 접근 방식은 무엇입니까?

컨텍스트가 있는 useTranslation() 후크(또는 HOC)?

AppTree 가 NextGetStaticProps 컨텍스트( getStaticProps({ AppTree }) )의 일부가 되면 좋을 것입니다. 그렇지 않으면 ssg에서 apollos getDataFromTree 와 같은 것을 실행할 수 없습니다.

이 시점에서 우리는 getStaticProps에서 AppTree 탐색을 허용하지 않을 계획입니다. 성능에 매우 좋지 않기 때문입니다(회사의 일관된 피드백). 페이지에 getStaticProps를 추가하면 여전히 _app의 getInitialProps를 통해 점진적 채택을 허용하므로 Apollo와 여전히 작동합니다.

amp: 'hybrid' 와 SSG 기능을 동시에 가질 수 있다면 좋을 것입니다.
이것은 다음과 같은 페이지에 대해 두 개의 파일을 생성하여 달성할 수 있습니다.

• (SSG) index.html
• (AMP) index.amp.html

이렇게 하면 프록시가 ?amp=1 쿼리 매개변수를 기반으로 amp 문서를 확인할 수 있습니다.

amp: 'hybrid' 와 SSG 기능을 동시에 가질 수 있다면 좋을 것입니다.
이것은 다음과 같은 페이지에 대해 두 개의 파일을 생성하여 달성할 수 있습니다.

• (SSG) index.html
• (AMP) index.amp.html

이렇게 하면 프록시가 ?amp=1 쿼리 매개변수를 기반으로 amp 문서를 확인할 수 있습니다.

정확히 @Dacturne , 이것은 제가 이 스레드 시간 전에 언급했던 것처럼 프로젝트에서 이미 SSG를 사용하기 시작하는 유일한 단점입니다.

🤞

@jansedlon 귀하의 질문에 대한 블로그 게시물을 작성했습니다.

빌드 시 알 수 없는 경로를 잡기 위해 일종의 와일드 카드 경로를 사용하는 방법이 있는지 궁금합니다. 예를 들어 CMS 데이터에서 정적 페이지를 렌더링할 수 있다는 것은 멋진 일이지만 누군가 새 항목을 추가하면 어떻게 될까요? 나는 그것에 대한 정적 페이지가 없습니다. 이 문제는 오랫동안 내 머리를 긁적입니다.

https://paqmind.com/en/blog/ssr-is-not-the-future

(너무 커서 여기에 올리지 않습니다)

@ivan-kleshnin 간단히 살펴보았는데 정말 흥미진진해 보입니다! 당신은 나에게 수백 시간을 절약했을 수도 있습니다! 감사합니다. 오늘은 나중에 자세히 살펴보겠습니다.

https://github.com/zeit/next.js/issues/9524#issuecomment -582799948

@jansedlon 앞서 말했듯이 @ivan-kleshnin의 블로그 포스트에서 다루지 않은 이것과 관련하여 작업하고 있습니다. 조만간 이에 대해 더 많은 정보를 공유할 수 있기를 바랍니다.

@timneutkens 지금까지의 변경 사항이 마음에 듭니다 🙏 완전한 정적 + 국제화를 개선/지원할 계획이 있습니까?

우리는 Gatsby에서 Next.js로 tinacms.org를 마이그레이션할 때 새로운 getStaticProps / getStaticPaths API를 사용해 왔으며 지금까지는 훌륭했습니다!

우리가 가진 한 가지 걸림돌은 RSS 피드를 생성하는 것입니다. 참조하는 콘텐츠가 정적으로 생성되기 때문에 이상적으로는 정적으로 생성하고 싶습니다. 현재로서는 이 작업을 수행할 방법이 없습니다. 대신 콘텐츠를 쿼리하고 응답에 XML을 작성하여 서버 측에서 처리하고 있습니다.

HTML이 아닌 콘텐츠 유형에 대한 정적 생성 지원에 대한 논의가 있었습니까?

참고로 우리는 지금 zeit에서 getStaticProps 를 사용하기 시작했고 --prod 플래그를 사용하는 릴리스와 새 릴리스의 json 파일에 대한 캐시가 지워지지 않았습니다. 별칭 기능을 사용하도록 프로덕션 릴리스를 다시 전환하면 캐시가 지워집니다.

우리는 Gatsby에서 Next.js로 tinacms.org를 마이그레이션할 때 새로운 getStaticProps / getStaticPaths API를 사용해 왔으며 지금까지는 훌륭했습니다!

우리가 가진 한 가지 걸림돌은 RSS 피드를 생성하는 것입니다. 참조하는 콘텐츠가 정적으로 생성되기 때문에 이상적으로는 정적으로 생성하고 싶습니다. 현재로서는 이 작업을 수행할 방법이 없습니다. 대신 콘텐츠를 쿼리하고 응답에 XML을 작성하여 서버 측에서 처리하고 있습니다.

HTML이 아닌 콘텐츠 유형에 대한 정적 생성 지원에 대한 논의가 있었습니까?

혼자 생각하다가 이번에 알게 되었어요. 내 스크립트는 다음과 같습니다.

"scripts": {
    "dev": " next",
    "build": "yarn sitemap && next build",
    "start": "next start",
    "sitemap": "ts-node --project ./cli/tsconfig.spec.json ./cli/generateSitemap.ts"
  },

next build 에는 정적으로 사이트맵을 생성하는 yarn sitemap 라고 합니다. 예를 들어 getStaticProps 필요한 모든 데이터를 json에 캐시하기 위해 동일한 기술을 사용할 수 있으며 여러 페이지에서 재사용할 수 있습니다.

은 RFC 업데이트, 변경 getStaticPaths 동작을 조금 (당신이 반환해야 paths , 지금이 거울 키를 getStaticProps 곳은 props 반환해야합니다.이를 변경 사항은 아직 Next.js에 적용되지 않았습니다.

또한 fallback 동작에 대한 설명을 추가했습니다(빌드 시 내보내지 않은 페이지의 온디맨드 백그라운드 생성).

RFC에 대한 또 다른 업데이트를 수행했으며 Loading 상태와 관련된 클라이언트 탐색 변경 사항에 대한 설명을 추가했습니다.

로딩 상태가 React 후크를 통해 렌더링되고 있는지 사용자가 알 수 있는 방법을 추가하고 싶을 수도 있습니다 🤔

좋은 물건! 정적으로 생성된 페이지가 단일 JSON 파일을 사용하여 여러 경로 간에 데이터를 공유할 수 있는 방법이 있는지 궁금합니다(코드 분할과 같지만 데이터용)?

나는 최신 canary 빌드에 부딪쳤고 즉시 새로운 Loading 상태에 빠졌습니다. 과거에는 뷰 레이어가 렌더링을 시작하기 전에 이미 올바른 데이터를 얻었다고 안전하게 가정하는 것이 좋았습니다. 강제 비동기 로딩은 그것과 크게 다릅니다. 나는 새로운 자동 생성 SSR 끝점이 대체할 모든 상용구 끝점을 제거하는 것을 정말 즐겼지만 새로운 Loading 상태를 포함하도록 모든 페이지를 다시 디자인할 계획은 없었습니다.

더 빠른 TTFB에 대한 열망과 미래에는 내 앱에 좋은 기능이 될 수 있다는 점을 이해합니다. 하지만 할 수있을 것입니다 Loading 상태 유사한 옵트 인 또는 옵트 아웃 기능, fallback: false 에 대해 getStaticPaths ? 페이지의 export const enableLoadingState = false 또는 next.config.js 사이트 전체

https://github.com/zeit/next.js/issues/9524#issuecomment -583962425

실험 기능을 사용 중이며 현재 이 동작을 실험하고 있음을 다시 한 번 알려드립니다.

내 (실험적) SSG 웹 사이트를 Now(기본 설정 사용)에 배포했습니다. 잘 작동하지만 사이트를 탐색할 때 네트워크 탭에 404 오류가 표시됩니다. 모든 404 오류는 _next/static/pages/[slug].js 가리킵니다.

실험 중에 예상되는 동작입니까? 아니면 일부 설정을 변경해야 합니까?

@joostmeijles 올바른 href 및 as 을 next/link . 동적 페이지의 경우 href 는 페이지 href='/[slug]' 여야 하고 as 는 URL as='/slug-1' 이어야 합니다.

빌드하는 동안 콘솔에 3개의 로그가 표시됩니다. 버그인가요?

// Page is showing three logs despite static path only having 2 entries and output generating only two files as intended
export default function Page(props){
    console.log("Page - should only show twice", props); 
    return <><h1>Page</h1></>
}

export async function unstable_getStaticProps(props) {
    console.log("unstable_getStaticProps - should only show twice", props);
    return {
      props
    };

}

export async function unstable_getStaticPaths() {
    console.log("show once")
    return {
        paths: [
        { params: { year: "1901" } },
        { params: { year: "1902" } },
        ]
    }
}

아니요, RFC의 fallback 에 따라 예상됩니다.

아니요, RFC의 fallback 에 따라 예상됩니다.

export async function unstable_getStaticPaths() {
    console.log("show once")
    return {
        fallback: false,
        paths: [
        // This renders /blog/hello-world to HTML at build time
        { params: { year: "1901" } },
        { params: { year: "1902" } },
        ]
    }
}

선택 해제를 시도했지만 이 오류가 발생합니다.

오류: /[연도]의 불안정한_getStaticPaths에서 반환된 추가 키(대체) 현재 허용되는 유일한 필드는 paths

실험 기능을 사용 중이며 현재 동작을 실험 중이며 모든 것이 구현되는 것은 아님을 다시 한 번 알려드립니다.

getStaticProps 이 기능은 페이지에서만 사용할 수 있습니까?
예를 들어 응용 프로그램에 대한 일부 전역 구성을 가져오는 것과 같이 앱/문서에도 흥미로울까요?

나는 이것을 '성공적으로' 구현했고 지금까지의 결과에 만족합니다. 하지만 후속 빌드를 '더 빠르게' 만들 수 있는 방법이 있는지 궁금합니다. 예를 들어 SSG 생성 페이지가 변경되지 않았는지 확인하고 다시 생성하지 않습니까? (아마도 나에게서 희망적인 생각)

@timneutkens SSG 페이지용 sitemap.xml 생성기를 추가할 계획이 있습니까? 지금은 정적 페이지에 대해서만 구현하는 것이 더 쉽다고 생각하기 때문에 동적 경로에 대해 이야기하지도 않습니다.

@timneutkens SSG 페이지용 sitemap.xml 생성기를 추가할 계획이 있습니까? 지금은 정적 페이지에 대해서만 구현하는 것이 더 쉽다고 생각하기 때문에 동적 경로에 대해 이야기하지도 않습니다.

예, 이것은 훌륭한 선택이 될 것입니다. 현재 SSR로 직접 생성 중입니다. (그러나 sitemap.xml 파일은 로드하는 데 시간이 오래 걸립니다)

https://github.com/zeit/next.js/issues/9524#issuecomment -585293270

getStaticProps가 도착한 후 영향을 주는 다른 작업이 있기 때문에 처음에는 페이지에만 해당됩니다.

https://github.com/zeit/next.js/issues/9524#issuecomment -586957539

예, 하지만 이 RFC의 일부는 아닙니다. 이 땅 이후에 후속 조치가 있을 것입니다.

@timneutkens 다음이 정적 페이지를 빌드할 때마다 URI를 배열에 푸시할 수 있기 때문에 SSG 페이지에 대한 구현이 쉽다고 생각합니다. 그런 다음 종료되면 배열을 각 XML 태그에 매핑하고 중간에 조인하고 삽입하기만 하면 됩니다. <sitemapindex> 태그. getStaticProps 는 excludeFromSitemap 라는 반환 개체에 다른 키를 가질 수 있으므로 기본값은 모든 페이지가 sitemap.xml 되지만 옵트아웃 옵션이 있는 것입니다.

이 경우 개발자는 사이트맵에 들어갈 정적 페이지를 미세하게 제어할 수 있습니다(예: page [foo] 의 getStaticPaths 함수가 foo 로 경로를 반환한 경우) 'abc' 및 'xyz' 그러나 'abc' 파일 excludeFromSitemap 를 true 으로 설정할 수 있습니다 getStaticProps 매개변수 ==='xyz' getStaticProps .

또한 SSR 및 정적 페이지의 경우 getServerProps , getStaticPaths 및 getStaticProps 과 같이 페이지 파일에서 상수(예: export const excludeFromSitemap = true; )를 내보낼 수 있습니다. getStaticProps 를) 내보냅니다.

SSG 페이지에서 내보낸 excludeFromSitemap 상수(페이지 기본값)가 있고 해당 키가 getStaticProps 함수(경로별)에서 반환된 개체에도 있는 경우 내보낸 값이 기본값으로 작동해야 합니다. 해당 페이지의 모든 경로에 대한 값과 경로별 excludeFromSitemap 가 getStaticProps 개체에 있는 경우 페이지의 기본값을 재정의해야 합니다(페이지가 export cosnt excludeFromSitemap = true 수행할 수 있도록 그런 다음 getStaticProps 값이 false 개체에 excludeFromSitemap 키를 추가하여 특정 경로를 제외한 사이트맵의 모든 경로를 제외합니다.

배열에 추가하는 코드는 다음과 같습니다(저는 진리표를 계산하고 Karnaugh 맵으로 최소 부울 표현식을 얻었습니다).

//...somewhere else
const validExcludeFromSitemapTypes = ['boolean','undefined'];

//...for each path
const isSSG = !!getStaticPropsReturnedObj && typeof getStaticPropsReturnedObj === "object";
if(
    validExcludeFromSitemapTypes.indexOf(typeof pageExports.excludeFromSitemap)<0 ||
    (isSSG && validExcludeFromSitemapTypes.indexOf(typeof getStaticPropsReturnedObj.excludeFromSitemap)<0)
) {
    throw new Error("'excludeFromSitemap' can either be ommited (undefined) or be a boolean");
}
const defaultExcludedValue = !!pageExports.excludeFromSitemap;
const hasSpecificExcluded = isSSG && typeof getStaticPropsReturnedObj.excludeFromSitemap !== "undefined";
const specificExcludedValue =  isSSG ? !!getStaticPropsReturnedObj.excludeFromSitemap : false;

if(!specificExcludedValue && (!defaultExcludedValue || hasSpecificExcluded))
    sitemapURIs.push(correctlyEncodedURI);

배열을 사이트맵으로 바꾸는 것은 이렇게 하는 것만큼 쉽습니다(배열의 URI가 이미 !excludeFromSitemap 인코딩 및 필터링되었다고 가정).

function createSitemap(sitemapURIs: string[]): string {
    return `<sitemapindex>${sitemapURIs.map(u=>`<sitemap><loc>u/loc></sitemap>`).join('')}</sitemapindex>`;
}

이 기능은 사용자에게 100 SEO 점수를 제공하고 sitemap.xml 갖는 것이 큰 도움이 될 것이기 때문에 이 기능이 Next.JS에 잘 들어맞을 것이라고 생각합니다! ( robots.txt 는 사이트맵 배열에 경로를 추가하여 허용되지 않는 페이지의 다른 배열에 해당 경로를 추가하는 조건에 else 를 추가하여 잠재적으로 생성될 수도 있습니다.

현재 릴리스 버전에서 사용하는 경우 unstable_getStaticPaths 함께 unstable_getStaticProps 생활 기능에 대한 기능, 당신은 할 수 없습니다 API를 호출 /api/ .
서버가 실행되고 있지 않기 때문에 이러한 방식으로 해당 요청을 수행하고 정적 props를 생성하는 것은 불가능합니다.
경로 기능을 제공하지 않거나(기본적으로 캐시가 있는 이 SSR을 만드는 것은 여전히 ​​좋습니다!) SSG 대신 SSR에 의존해야 합니다.

이 기능에 좋은 추가 기능이 아닐까요? 여기서 가장 좋은 방법이 무엇인지 확실하지 않습니다. SSR 및 /api 경로를 사용하여 http 요청을 바로 가기로 제안하는 다른 곳에서 제안을 읽었습니다. 이것은 여기에서도 유용할 것입니다.

그러나 이 모든 것은 물론 빌드 환경에서 코드를 실행하는 것을 의미하며, 이는 다른 서비스/db 호출 또는 이와 유사한 것을 호출합니다. 이것은 구현될 때 명확해야 하지만 이 기능에 대한 멋진 추가 사항이 될 것입니다.

@reckter 예, 방금 비슷한 작업을 수행했습니다. 정적으로 생성되는 동안 개별 페이지 요청마다 db에 연결해야 했습니다. 기분이 많이 이상했다...

그것이 최종 사용 사례가 아니기를 바랍니다.

next.config에서 설정할 수 있는 일종의 초기화 스크립트가 있으면 좋을 것입니다.

@reckter HTTP 요청을 SSG/SSR에서 API 경로로 바로 가기 위한 방법은 정말 좋을 것입니다! 이러한 시나리오 중 하나에서 나 자신에게 네트워크 요청을 하는 것이 이상하게 느껴집니다.

어쨌든, SSG 동안 API 경로에 액세스하기 위한 가능한 솔루션은 정적 페이지를 컴파일하기 전에 로컬 서버에서 /api 경로만 실행하도록 하는 것입니다! 따라서 빌드 단계는 다음과 같습니다.

1. /api 경로만 제공하는 서버("api 컴파일 서버" 또는 이와 유사한 것)를 시작합니다.
2. unstable_getStaticPaths
3. unstable_getStaticProps
4. 정적 페이지 컴파일

@reckter 기본적으로 API 라우트를 호출할 필요가 없습니다. 구현하는 함수를 직접 호출할 수 있습니다. 이렇게 하면 http 원인을 넘어서는 많은 오버헤드도 피할 수 있습니다.

기본적으로 현재 다음과 같은 API 경로가 있는 경우:

import myDb from 'mydatabaseprovider'
const db = myDb()

export default async (req, res) => {
  cont myData = await db.query('posts')
  res.json(myData)
}

다음과 같이 변경할 수 있습니다.

import myDb from 'mydatabaseprovider'
const db = myDb()

export async function getData() {
  const myData = await db.query('posts')
  return myData
}

export default (req, res) => {
  const myData = await getData()
  res.json(myData)
}

그런 다음 페이지에서:

import {getData} from './api/myfunction'

export async function getStaticProps() {
  const myData = await getData()
  return {
    props: {
     myData
   }
  }
}

GraphQL API에 대해 동일한 작업을 수행하는 것은 까다로울 것입니다. 그리고 대부분의 REST에서도 마찬가지입니다.

API 호출 != DB에서 가져오기(일반적으로)
필드 이름 바꾸기, 데이터 형식 변경 등과 같은 API 계층에는 거의 항상 몇 가지 비즈니스 로직이 있습니다.

pages/api 호출을 허용하지 않을 이유가 있다고 확신하지만 실제 API의 우회는 쉽거나 저렴하지 않습니다. 그리고 여분의 몇 밀리초는 추가 코드/복잡성 IMO에 대한 비용을 능가하지 않습니다.

또한 모든 API에 대한 요청이 허용된다는 것이 이상하게 느껴집니다. 나만의 🤷‍♂

unstable_getStaticPaths 하면 페이지가 다시 로드되어 예를 들어 redux에서 현재 상태가 손실됩니다. 앞으로 이 행동이 바뀔까요?

편집: 링크 또는 라우터에서 as 옵션을 사용하여 이 동작을 우회할 수 있는 것 같습니다.

<Link
  href='/item/[key]'
  as={`/item/${itemName}`}
>

router.push(
  '/item/[key]',
  `/item/${itemName}`
);

@meesvandongen 항상 <Link> 이 유효하지 않으면 기본적으로 <a> 로 작동하는 백엔드 부분으로 이동합니다. [key] 와 같은 동적 조각은 해당 값과 쌍을 이루어야 합니다.

@reaktivo pages/[lang]/blog/[id].js -> getStaticPaths 에서 정적으로 렌더링할 모든 URL을 제공합니다.

https://github.com/zeit/next.js/issues/9524#issuecomment -562625858
이 경우 index.js를 제외한 모든 페이지에 getStaticPaths 및 getStaticProps 함수를 추가해야 합니다.
일부 mdx 페이지가 있으면 프로젝트를 유지 관리하기가 더 어렵습니다.

정적 getStaticPaths getStaticProps 메소드로의 변경 또는 호환을 고려하십시오. https://github.com/zeit/next.js/issues/9524#issuecomment -558617056
그렇다면 페이지는 고차 함수 또는 고차 구성 요소(HOC)에 의해 래핑될 수 있습니다.
이런 식으로 코드는 더 유지 관리하기 쉽고 typesscript에 더 편리합니다.

나무 흔들기 대 동적. 이 얼마나 골치 아픈 트레이드오프인가.😂

9.2.3-canary.13 사용하여 다음과 같이 getStaticPath에서 fallback: false 를 사용해 보았습니다.

  return {
    fallback: false,
    paths: slugs.map(slug => ({params: {slug: slug}}))
  }

그러나 다음 오류와 함께 실패합니다.

Error: Extra keys returned from unstable_getStaticPaths in /blog/[slug] (fallback) Expected: { paths: [] }

9.2.3-canary.13 사용하여 다음과 같이 getStaticPath에서 fallback: false 를 사용해 보았습니다.

  return {
    fallback: false,
    paths: slugs.map(slug => ({params: {slug: slug}}))
  }

그러나 다음 오류와 함께 실패합니다.

Error: Extra keys returned from unstable_getStaticPaths in /blog/[slug] (fallback) Expected: { paths: [] }

맵이 더 높은 레벨이 필요하다고 생각하므로 맵은 현재 가지고 있는 개체를 반환하지만 고유한 슬러그를 포함합니다. 경로에 매핑하는 대신.

아직 nextjs에서 내 버전을 업데이트하지 않았지만 비슷해야 합니다.

return data.map(item => {
    return {
      params: {
        slug: item.slug,
      },
    }
  })

@jorngeorg 공개 PR입니다: https://github.com/zeit/next.js/pull/10701

환상적인 기여! 정적 렌더링 프로세스를 실제로 향상시킵니다.

동적 경로에서 getStaticProps 대한 호출 없이 "대체"가 생성된다는 문서를 추가하는 것이 좋습니다. 즉, props가 비어 있는 경우를 설명하기 위해 구성 요소를 코딩해야 합니다.

또는 대체를 생성할 때 컨텍스트 없이 getStaticProps 를 호출하도록 동작을 변경할 수 있습니다. 이것은 next export 현재 작동하는 방식과 일치합니다(예: getInitialProps 를 컨텍스트 없이 실행하여 /p/[id].js 를 /p/[id].html 로 내보냅니다).

• getStaticProps - next build 시간에 SSG(정적 생성)를 선택합니다.
• getServerProps - 온디맨드로 렌더링하는 SSR(서버 측 렌더링)을 선택합니다.

10722

getServerProps의 이름을 getServerSideProps로 바꿉니다.

동적 경로에서 getStaticProps 대한 호출 없이 "대체"가 생성된다는 문서를 추가하는 것이 좋습니다. 즉, props가 비어 있는 경우를 설명하기 위해 구성 요소를 코딩해야 합니다.

참고하면 좋은점! 나는 또한 그것을 놓쳤기 때문에 일부 빌드/배포 오류가 있었습니다.

변경 사항을 반영하도록 RFC를 업데이트했습니다.

@timneutkens

• 동일한 경로에 대한 후속 요청은 생성된 페이지를 제공합니다.

이것이 Next.js가 생성된 페이지를 캐시할 것임을 의미한다고 가정합니까? 인메모리 캐시인가요? 이 캐시가 제한에 의해 제한되거나 메모리 누수가 발생할 수 있습니까?

next start 를 사용하면 현재 캐싱 예제와 유사한 lru-cache를 사용합니다. 현재 기본 제한은 50MB이며 나중에 구성할 수 있습니다. https://github.com/zeit/next.js/ 블롭/카나리아/패키지/next/next-server/server/spr-cache.ts#L90

ZEIT에서 호스트할 때 이제 생성 및 캐싱이 CDN/프록시에서 발생하므로 약간 다르게 작동하므로 메모리 누수나 lru 제한을 초과하는 경우에 대해 걱정할 필요가 없습니다.

👍 좋아, 합리적으로 보인다. 그것은 내가 합리적인 기본 동작으로 염두에 두었던 것입니다.

• getStaticProps - next build 시간에 SSG(정적 생성)를 선택합니다.
• getServerProps - 온디맨드로 렌더링하는 SSR(서버 측 렌더링)을 선택합니다.

10722

getServerProps의 이름을 getServerSideProps로 바꿉니다.

그런데 왜 이름을 바꾸나요? IMHO getServerProps는 입력하기에 충분히 정확하고 짧아서 Side를 추가하는 것이 나에게 중복되는 느낌입니다.

getStaticPaths 메서드에 변경 사항이 있는지 궁금합니다. 내 동적 페이지는 더 이상 정적 페이지로 생성되지 않습니다. 이제 람다 함수로 내보내집니다.

이제 기본 동작이 페이지가 먼저 람다로 렌더링되고 특정 페이지를 방문한 후에만 페이지가 정적 페이지로 생성되는 것이 맞습니까? (대체에서 언급한 것처럼)

@erhankaradeniz 페이지가 Lambdas 가 되는 getStaticPaths 변경 사항이 없습니다. 이것은 사용상의 오류일 가능성이 있습니다.

문제를 식별할 수 있도록 코드를 보여주시겠습니까?

@Timer 지금은 경로에서 작동하지 않는 이유를 알아낼 때까지 여전히 params를 사용할 수 있는 [email protected]으로 되돌아갔습니다.

이것이 현재 내 경로를 생성한 방법입니다.

return cityData.map(city => {
    return {
      params: {
        country: city.countrySlug,
        city: city.slug,
      },
    }
  })

그리고 다른 페이지에서는 다음을 수행합니다.

return cityData.map(city => {
    return {
      params: {
        country: city.countrySlug,
        city: city.slug,
      },
    }
  })

경로가 있는 새 카나리아 릴리스로 변환하지 못했습니다. console.logs가 getStaticPath 내에서 실행되지도 않기 때문에 뭔가 잘못하고 있는 것 같습니다.

중첩 경로 사전 렌더링 및 SSG에 문제가 있습니다.

// pages/[lang]/[...slugs].js

export async function getStaticPaths() {
  let knex = await import("knex/client").then(m => m.default)
  let pages = await knex("page").select(["lang", "url"])
  return {
    fallback: true,
    paths: pages.map(page => {
      return {
        params: {
          lang: page.lang,
          slugs: page.url == "/" ? [] : page.url.slice(1).split("/"),
        }
      }
    }),
  }
}

~으로 이끌다

Error occurred prerendering page "/en/". Read more: https://err.sh/next.js/prerender-error:
Error: The provided export path '/en/' doesn't match the '/[lang]/[...slugs]' page.

홈 페이지의 경우. 어떤 이유로 NextJS가 일치하지 않습니다.

{lang: "en", slugs: []}

에게

/[lang]/[...slugs]

{lang: "en", slugs: ["/"]} 하면 빌드되지만 URL이 잘못됩니다.

├ ● /[lang]/[...slugs]      875 B        204 kB
├   ├ /en/credits
├   ├ /en/%2F

기록을 위해 getServerSideProps 는 유사한 설정으로 잘 작동합니다.

실험적이라는 건 알지만 이 스레드는 피드백을 제공하기 위한 것입니다. 맞나요?

pages/[lang]/[...slugs].js 일치 /en/abcdef 하지 /en , 현재 만들 필요가 그것을 위해 pages/[lang]/index.js .

이에 대한 기능 요청이 있습니다: https://github.com/zeit/next.js/issues/10488

우선, 이것은 굉장합니다. 나는 Next.js에 이와 같은 것을 갖고 싶었기 때문에 마침내 Gatsby.js에서 벗어나 하이브리드 앱(정적 + 동적)을 가질 수 있게 되었습니다.

🚀 나는 카나리아를 시도했고 반 구운 복잡한 앱 버전은 잘 작동했습니다. 나는 여기에 있는 모든 주석을 읽지 않았지만 나무 흔들기가 아직 구현되었는지 확신하지 못한다고 고백합니다.

🤔 getStaticPaths 는 SSG 동작에 대한 정적 경로를 정의하는 setStaticPaths 와 훨씬 비슷합니다. 그런 점이 나를 조금 혼란스럽게 했다.

🧐 빌드 카테고리를 만들어 빌드 시간을 단축할 수 있는지 궁금합니다. 이것이 설정을 복잡하게 만들 것이라는 것을 알고 있지만 그만한 가치가 있습니다. 설명하겠습니다:

blog 또는 pages 또는 누군가가 원하는 2020-content 설정하는 setBuildCategory 와 같은 것이 있으면 어떻게 될까요? 그런 다음 SSG 빌더는 변경된 페이지의 범주를 찾고 캐시 + 새 렌더 조합에서만 해당 범주를 다시 작성하려고 시도합니다. 이와 같은 것은 SSG를 빠르게 만들고 많이 변경되지는 않지만 여전히 변경될 수 있으므로 보관할 수 없는 항목에 대한 막대한 빌드 시간을 피하는 데 도움이 될 수 있습니다.

그것이 의미가 있다면; 전화를 걸고 이에 대해 채팅하게 되어 기쁩니다.

사용자 정의 서버 구현으로 getServerSideProps 를 처리하는 방법은 무엇입니까?

if (pathname === '/a') {
  app.render(req, res, '/b', query)
}

위의 예에서 /a 방문하면 pages/b.js 페이지가 렌더링됩니다. 그러나 /a 대한 클라이언트 측 리디렉션은 이 경우에 존재하지 않는 a.json 파일을 다운로드하려고 시도합니다.

다른 JSON 파일을 렌더링하기 위해 /_next/data/{BUILD_ID}/{PAGE}.json 에 대한 요청에 대해 유사한 조건이 있어야 합니까?

getStaticPaths에서 fallback: true 를 사용하려면 req 객체를 어떻게 얻습니까? 현재로서는 할 수 없는 것으로 보입니다. 내가 필요한 이유는 브라우저에서 일부 쿠키를 가져와 경로를 인증하는 것입니다.

@tylermcrobert 요청이 전혀 없을 때 쿠키를 잡는 것을 어떻게 상상합니까?!
실제 방문자 요청에 따라 백엔드가 있는 경로는 "정적" 및 "동적"의 정의에 따라 정적으로 만들 수 없습니다. 정적 및 인증을 결합할 수 없다는 것은 말할 것도 없고... 인증 부분은 페이지 대신 API 및 클라이언트 코드에 속할 뿐입니다.

사용자 정의 서버 구현으로 getServerSideProps 를 처리하는 방법은 무엇입니까?

if (pathname === '/a') {
  app.render(req, res, '/b', query)
}

위의 예에서 /a 방문하면 pages/b.js 페이지가 렌더링됩니다. 그러나 /a 대한 클라이언트 측 리디렉션은 이 경우에 존재하지 않는 a.json 파일을 다운로드하려고 시도합니다.

다른 JSON 파일을 렌더링하기 위해 /_next/data/{BUILD_ID}/{PAGE}.json 에 대한 요청에 대해 유사한 조건이 있어야 합니까?

Next.js는 동적 경로 매개변수를 지원하므로 사용자 지정 서버에서 다시 매핑할 필요가 더 이상 거의 없습니다. https://nextjs.org/docs/routing/dynamic-routes

이미 설명한 접근 방식은 <Link> 작동하지 않으므로(전체 페이지 전환이 발생함) getServerSideProps가 이미 작동합니다.

@tylermcrobert 요청이 전혀 없을 때 쿠키를 잡는 것을 어떻게 상상합니까?!
실제 방문자 요청에 따라 백엔드가 있는 경로는 "정적" 및 "동적"의 정의에 따라 정적으로 만들 수 없습니다. 정적 및 인증을 결합할 수 없다는 것은 말할 것도 없고... 인증 부분은 페이지 대신 API 및 클라이언트 코드에 속할 뿐입니다.

이 경우 대체 옵션을 오해하고 있는 것일 수 있습니다. 당신이 말하는 것은 빌드 타임 컨텍스트에서 완전히 의미가 있습니다.

미리 정의된 경로가 없을 때를 위한 fallback: true 아닌가요? 이 경우 브라우저에서 폴백(fallback)에 도달할 것입니다. 그렇지 않습니까?

@tylermcrobert yes fallback: true 케이스에 요청이 있지만 API는 "최소 공통 분모"로 통합되어야 합니다. 모든 것이 하나의 전제 세트로 구축된 다음 완전히 다른 전제 세트로 점진적으로 업데이트되는 작업 시스템을 상상할 수 없습니다. 지원하는 것은 재앙이 될 것입니다.

이러한 증분 빌드가 빌드 간에 여전히 캐시된다는 점을 놓치고 있다고 생각합니다. 따라서 첫 번째 방문자의 역할은 모든 후속 사용자의 빌드 결과에 영향을 미칩니다! 나쁜 생각처럼 들립니다.

@ivan-kleshnin 이해하고 확실히 동의합니다. 내가 묻는 이유는 내 특정 사용 사례 때문입니다.

미리보기 기능을 허용하는 헤드리스 CMS를 사용하고 있으므로 미리보기가 필요한 페이지는 빌드 시 포함되지 않습니다(미리보기 중인 항목이 이 시점에서 존재하지 않기 때문입니다). 나는 이것이 대체 옵션이 들어오는 경우라고 생각했습니다.

해당 미리보기에 액세스하려면 쿠키를 통해 제공되는 api 미리보기 참조에 액세스해야 합니다.

useStaticProps 완전히 폐기해야 하는 경우입니까? 내 문서를 미리 볼 수 없기 때문에 정적 빌드의 이점을 잃고 싶지 않습니다.

Gatsby와 같은 것에 비해 이 RFC의 매력은 헤드리스 CMS로 작업하는 데 고통을 덜 주는 정적 사이트 생성으로 "하이브리드 제어"를 제공한다는 것입니다.

미리보기 기능을 허용하는 헤드리스 CMS를 사용하고 있으므로 미리보기가 필요한 페이지는 빌드 시 포함되지 않습니다(미리보기 중인 항목이 이 시점에서 존재하지 않기 때문입니다). 나는 이것이 대체 옵션이 들어오는 경우라고 생각했습니다.

더 빨리 지켜봐 주세요 🕵

따라서 이것을 올바르게 이해하면 예를 들어 사용자가 등록할 때(새 페이지/사용자이므로 정적 페이지가 생성되지 않음) fallback true를 사용할 수 있지만 프로필이 방문을 받으면 자동으로 생성됩니까?

에르한 카라데니즈
http://www.erhankaradeniz.com

2020년 3월 4일 20시 25분에 Tim Neutkens [email protected]이 다음과 같이 썼습니다.

미리보기 기능을 허용하는 헤드리스 CMS를 사용하고 있으므로 미리보기가 필요한 페이지는 빌드 시 포함되지 않습니다(미리보기 중인 항목이 이 시점에서 존재하지 않기 때문입니다). 나는 이것이 대체 옵션이 들어오는 경우라고 생각했습니다.

더 빨리 지켜봐 주세요 🕵

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 구독을 취소하세요.

사용자 데이터는 해당 클라이언트 측을 가져오려는 나쁜 예입니다. 대체는 빌드 시 생성되지 않은 페이지를 정적으로 생성하는 주문형 페이지를 위한 것입니다. 예를 들어 빌드 시 상위 100개 블로그 게시물을 생성하고 트래픽이 적은 다른 블로그 게시물은 생성하지 않을 수 있습니다.

문서도구는 곧 제공될 것입니다.

네, 제가 의미한 것은 자리 표시자 페이지였습니다. 실제로 클라이언트 측에서 사용자 데이터를 가져올 것입니다.

@timneutkens 정적으로 생성된 특정 페이지를 삭제하거나 다시 작성하는 방법이 있습니까?

안녕하세요!!! 최적의 응용 프로그램처럼 들립니다. 나는 React와 Next를 모두 사랑합니다!!! 우리가 사용할 수 있도록 모든 것을 우아하고 간단하게 만들었습니다!! 그러나 예제에는 개념 블로그가 포함됩니다. Headless CMS를 쿼리할 때 구현의 예를 보고 페이지/게시물당 가져오기를 정적 항목으로 내보내기로 수행하고 싶습니다.

// 금요일이 가까워서 건배!!!

@timneutkens 신나네요 👌

우리가 자주 접하는 시나리오 중 하나는 동적 경로 또는 루프에서 프로젝트 생성을 제외하고 next.js 또는 gatsby에 대한 완벽한 솔루션이 아직 없습니다.

역사적 이유로 우리는 가격, 통화, 지원 전화번호 및 언어 선택기를 제외하고 동일/정확한 페이지를 제공하는 여러 도메인을 처리해야 합니다(이를 변경할 생각이 없습니다). 본질적으로 이러한 마케팅 페이지의 대부분은 매우 정적이며 매일 또는 매주 구축하는 것으로 충분합니다(모든 요청에 ​​대해 렌더링하도록 하는 것과 비교).

내 질문/생각: (미래에?) getStaticPaths 가 경로 매개변수는 아니지만 요청 수준에서 페이지를 전환하는 데 사용할 수 있는 페이지를 생성할 수 있는 방법이 있습니까(예: 서버리스 함수는 locale 기반으로 사전 빌드된 정적 결과를 반환합니다.

구체적으로 이것은 https://mysite.com/my-product 및 https://mysite.co.uk/my-product 가 두 개의 다른 정적 페이지를 제공하지만 다음 앱을 50배 생성하거나 모든 요청에 ​​대해 CMS를 누르지 않아도 된다는 것을 의미합니다.

미리 감사드립니다. 특히 그것이 미래를 위해 해결/해결될 수 있는 것이라면 여러분의 생각을 듣고 싶습니다 ❤️

SEO를 위해 트래픽이 많은 방문 페이지와 서버 부하를 줄이기 위해 SSG를 사용하고 싶지만 수화 후 현재 데이터를 사용하고 이 페이지로의 클라이언트 측 라우팅을 원하는 사용 사례에 대해 생각하고 있습니다. 그게 가능할까요?

따라서 기본적으로 이 페이지로의 클라이언트 측 라우팅에서 동작은 getInitialProps 와 같아야 합니다(현재 데이터는 페이지가 표시되기 전에 가져옴). 그리고 이 페이지로의 서버 측 라우팅에서 정적 html이 제공되고 수화되어야 하며 (선택 사항) 페이지의 일부 데이터를 업데이트하기 위해 일부 API 응답을 가져와야 합니다.

방금 unstable_getStaticProps 를 사용해 보았는데 재미있는 충돌이 발생했습니다. getStaticProps 와 API 경로를 사용하는 것은 어렵습니다.

코드의 의미에 주의를 기울이지 말고 데이터 가져오기 흐름에만 주의하십시오.

// pages/api/healthcheck.ts
import { NextApiResponse, NextApiRequest } from 'next';

export type ApiHealthCheckResponse = {
  message: 'ok';
};

const healthCheckHandler = (
  req: NextApiRequest,
  res: NextApiResponse<ApiHealthCheckResponse | ''>,
) => {
  if (req.method === 'GET') {
    return res.status(200).json({ message: 'ok' });
  }

  return res.status(405).send('');
};

export default healthCheckHandler;

// pages/index.js
// ...

export async function unstable_getStaticProps() {
  return {
    props: {
      healthcheck: (await fetch('localhost:3000/api/healthcheck').json())
    },
  };
}

서버가 실행되고 있지 않기 때문에 페이지 빌드가 빌드 시 충돌합니다. getStaticProps 가 너무 동적인 것과 함께 사용되어서는 안 되므로 이것이 유효한 사용 사례인지 확실하지 않지만 공유할 수 있는 흥미로운 사례라고 생각했습니다. 다른 API에서 데이터를 가져와서 다시 포맷하십시오.

@martpie 이 댓글을 확인하고 싶을 수도 있습니다: https://github.com/zeit/next.js/issues/9524#issuecomment -589772756

Next.js 9.3에서 차세대 SSG(정적 사이트 생성) 지원이 안정적으로 릴리스되었습니다!

이 릴리스는 또한 "미리보기 모드"에 대한 지원, 또는 정적으로 사전 렌더링 된 페이지 우회 할 수있는 기능을 포함하고 주문형 권한이 부여 된 사용자의 페이지를 렌더링합니다.

자세한 내용은 블로그 게시물 에서 확인할 수 있습니다. 더 많은 작업을 수행하려면 문서 로 바로 이동하십시오!

Next.js GitHub 커뮤니티에 질문을 게시하세요!

이거 대박! 노고에 감사드립니다!

이 새로운 기능은 현재 saga 및 redux에서 작동하지 않는 것 같습니다.