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ページのみの再構築をトリガーしようとしていますが、アプリケーションコードは変更されていません。

すぐにアラームが鳴ります。この場合、ビルドをトリガーすると、次の2つの解決策が考えられます。

1）すべてがキャッシュされるため、何も再構築されません。コードは変更されておらず、何とかされていません。
2） --forceすると、「すべて」が再構築されますが、SSGページの再構築のみが必要でした。

_これらは単なる仮説であり、ビルドシステム自体に依存します-Nextをどの程度認識しているか_

これはおそらく他のホスティングソリューションに影響を与えるでしょう。

Next自体には.next/cacheます...これはそれをどのように回避しますか？

@joltmodeは、基本的に現在すべての静的サイトジェネレーターに.next/cacheは、Nowでの展開間で保持され、再利用されます。 現在、この場合、キャッシュ（潜在的にhttps://zeit.co/blog/serverless-pre-rendering）でgetInitialPropsを使用している可能性があることに注意してください。これは、サーバーレス関数で動的にレンダリングしてから、CDNにキャッシュします。動作はまだ完全に正常であり、 getServerPropsを使用しても引き続き機能します。

本当に素晴らしく、顧客プロジェクトでNextをどのように使用しているかにうまく適合し、コピーしたボイラープレートコードをいくつか削除します。

考慮すべきことの1つは、getStaticPropsとgetServerPropsの名前です。これらが将来、{props}とその他の潜在的なオプションを返す場合、* Propsは混乱しませんか？ たぶん、getStaticConfiguration、getStaticSetup、getStaticOptionsはもっと一般的でしょうか？

@kibsの戻り値は、常に小道具の処理方法に関連しています。 ですから、ネーミングは素晴らしいimoです。

これは単に素晴らしいです！ これは、プライベートWebアプリとプロフェッショナルWebアプリの両方を開発しているときに、私が最近持っていた、または考えることができたすべてのユースケースとニーズを解決しています。 あなたは私が私自身のハイブリッドサイトジェネレーターを始めるのを妨げただけです、ありがとう！

また、新しいメソッドが以前のgetInitialProps()およびexportPathMap()よりも優れていることに関連することもできます。これ

これを試すのが待ちきれません！

補足：最後の例では、 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アプローチにより、応答をより効率的にキャッシュできます。

もちろんですが、ReactサーバーへのRTTをまったく回避することについて話しています。 サーバーからのSSR出力がCDN /キャッシュサーバープロキシにキャッシュされている場合を考えてみます。 これを、別のAPIレイヤー（Web /アプリ/すべてのクライアントに共通）を直接呼び出すクライアントナビゲーションのデータフェッチと組み合わせると、トラフィックの多いシナリオでNext.jsサーバーレイヤーをそれほどスケールアップする必要がなくなります。

ウォーターフォールフェッチのポイントは理解していますが、消費者がNextサーバーをデータソースではなくSSRレイヤーとして扱うことができるようにすると、スケーリングのセットアップが大幅に改善されます。

とても面白そう！ 彼はgetInitialProps代わりになるのでしょうか、それとも一緒になりますか？ たとえば、私たちのユースケースでは、データフェッチAPIは公共サービスです。 したがって、クライアント側のナビゲーションでは、クライアントがAPIレイヤーを直接呼び出すことを期待しますが、SSRではサーバーがそれを呼び出します。 今後、このユースケースは以前の方法で解決され続けるでしょうか？

一般に、その動作にはいくつかの欠点があります。たとえば、世界中の特定の領域からのウォーターフォールのフェッチが遅くなる可能性があります。 getServerPropsアプローチにより、応答をより効率的にキャッシュできます。

もちろんですが、ReactサーバーへのRTTをまったく回避することについて話しています。 サーバーからのSSR出力がCDN /キャッシュサーバープロキシにキャッシュされている場合を考えてみます。 これを、別のAPIレイヤー（Web /アプリ/すべてのクライアントに共通）を直接呼び出すクライアントナビゲーションのデータフェッチと組み合わせると、トラフィックの多いシナリオでNext.jsサーバーレイヤーをそれほどスケールアップする必要がなくなります。

ウォーターフォールフェッチのポイントは理解していますが、消費者がNextサーバーをデータソースではなく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でインポートとrequireを使用するためのベストプラクティスが何であると想像するかです。 私が間違っていない場合、上記のスニペットはReactにfs-extraでインポートしようとしますか??。 したがって、インポートをこのようにインライン要求に変更する方がよいでしょうか？

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または小道具を指定する必要があります。

@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は、書かれているように、多くのアプリケーションにすぐに役立つため、批判するのは難しいです。 ただし、同意するかどうかわからない1行に対処したいと思います。

「 getStaticPathsは、 exportPathMapを持つ必要性を置き換え、ページごとに機能します。」

一部のアプリケーションでは、ビルド時にルートを知ることが非現実的または不可能です。 いくつかの例は次のとおりです。

• ユーザープロファイルページ
• 製品ページ（在庫が急速に変化する企業向け）
• 受注詳細ページ

このようなページのルートはおそらく/entity-name/entity-idの形式になり、 router.push('/customers/[customerId]', '/customers/baer')ようなことができるので、Nextの動的ルートは非常にうまく機能します。 まだ問題があります。 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相互に排他的ですか？ つまり、パーツを事前レンダリングし、パーツを動的にすることは可能でしょうか？

ええ、1つは静的生成で、もう1つはサーバー側レンダリングです。

これにより、Nextに移行する前にGatsbyから見逃していた大きな問題の1つが修正されます。

モノリシック（数百kbs）のJSONファイルがあり、そこからデータを取得して、ページを変更せずにレンダリングします。 Gatsbyでは、JSONファイルをGraphQLスキーマにロードし、それに対してクエリを実行し、特定のページをレンダリングするために必要なデータのみを取得しました。 Nextでは、これを行うための最も簡単でクリーンな方法はimport monolith from './monolith.json'であり、ユーザーはJSONファイル全体をダウンロードする必要があります。

このRFC100％はこのユースケースに対応し、Gatsbyが優れている領域でGatsbyと同等に近づくための次のステップをもたらします（明らかに、GatsbyはランタイムSSRを実行できないため、静的ビルドタイムレンダリングについてのみ説明します）

@ timneutkens 、RFCをありがとう！

最近@rauchgと話し合ったNext.jsのユースケースがあります。

Next.jsは、非常にスムーズなDXといくつかの妥当なデフォルトを提供します。 そのため、クライアント側でのみレンダリングされるアプリケーションであるスマートTVアプリにNext.jsを使用することに興味があります。

スマートTVアプリは、TVのブラウザエンジンによって実行されるほぼ古典的なWebアプリです。

1. アプリは、スタイル、スクリプト、画像、_index.html_、証明書、TV構成ファイルのバンドルにパッケージ化されています。
2. バンドルは、レビューのためにプラットフォームのアプリストアに送信されます。
3. バンドルはストアからアプリとしてインストールされ、ユーザーによって実行されます。

重要なのは、バンドルがTVデバイス自体によって静的にホストされており、サーバーからロードされていないことです。 したがって、SSRオプションは使用できません（Node.jsはこれらの目的で開発者に公開されません）。 しかし、アプリ自体は動的です（たとえば、Netflix）。

したがって、静的WebサーバーによってホストされているSPAを実行する必要があります。

私が理解しているように、 getServerProps （またはgetInitialProps ）を完全にオプトアウトすると、SSRを回避するのに役立ちます。 しかし、クライアントでの動的レンダリングはどうなりますか？ そして、この場合のルーティングはどうですか？ このRFCによると、@ timneutkens 、

PS個別に議論する方がよいと思われる場合は、このユースケースの問題を作成できます。

@grushetsky別の問題を作成できますか。 これは、RFCで議論されているものとはまったく異なる質問です👍

@timneutkensこのRFCの約束は、私がNextに非常に興奮したことの1つです。 明確にするために、 getInitialPropsもまだ存在しますよね？

正しい@outdooricon - getInitialPropsは、当面の間残ります。

RFCによると：

このRFCは、APIの追加についてのみ説明しています。 すべての新機能は完全な下位互換性があり、段階的に採用できます。 このRFCは非推奨を導入していません。

素晴らしいRFC、これに非常に興奮しています！

私は特定のユースケースに関連してgetServerPropsについて考えていて、結果をキャッシュに入れています。 これはAPIエンドポイントに変換され、結果が小道具としてコンポーネントに配信されるため、結果をRedux、GraphQLキャッシュなどのクライアント側の外部キャッシュに配置する規定の方法はありますか？

getInitialPropsは静的で非同期であるため、正しく理解していれば、Nextには、コンポーネントを初めてレンダリングする前に、完了するのを待つ機会があります。 これにより、外部キャッシュに物事を入れることができます。 getServerPropsはサーバー上で実行されるため、これは当てはまりません。コンポーネントのライフサイクルでキャッシュにデータを配置するということは、データがまだキャッシュで利用できないレンダリングが必要であることを意味しているようです。 、小道具で利用できる場合でも？

もちろんこれは意図的なものであり、アプローチが欠けているかもしれませんが、それが考慮されているものであるかどうかを尋ねると思いました。

編集：これはgetStaticPropsも当てはまると思います。 😄

どこかで見逃したかもしれませんが、コンテンツがキャッシュされているのに、dbで更新されたり、新しいブログ投稿が作成されたりする状況をどのように処理しますか？ 新しいビルドを自動的に行う必要がありますか？ たぶんそうだ。

初めに！ すばらしい提案です。ほとんどの人のユースケースでexportPathMapsを大幅に上回っています。 本当にありがたいです。 そうは言っても、ルートの国際化でどのように機能させることができるかを理解するのに苦労しています。

i18nプレフィックス付きルートを処理する方法に関する提案はありますか？ 私の特定のユースケースでは、country-langプレフィックスとURLが異なるページで数千を構築する必要があります。

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

あなたの例のように（ /blog/[id].js ）、URLのプレフィックスがよく知られている場合、 getStaticPathsは本当に役立つようです。 しかし、動的プレフィックス（country-lang）と動的パスの両方を使用してルートレベルでパスを生成する必要がある場合、 getStaticPaths実装はどのように見えると思いますか？

@reaktivo pages/[lang]/blog/[id].js -> getStaticPaths 、静的にレンダリングするすべてのURLを提供します。

@timneutkensこれがいつ利用可能/テスト可能になるかについて何か考えはありますか？

一般に、ETAは提供しません。これは、ソリューションが正しいことを確認するために、本番アプリに対して機能を広範囲にテストするためです。

この改善により、「維持されていない」フェノミクスプロジェクト（私以外は誰も使用しないreact ssg）を完全に廃止することになります。 Next.jsがこの不足している部分を追加しているのを見るのは素晴らしいです！

疑問を明らかにしたいと思います。 ワードプレスのような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が戻ってこない限り、ページにはコンテンツがありません（bye-bye SEO）

nextJSを使用したJamstackの実行例はありますか？netlifyで実行できます。

ありがとう、
アンドレアス

ちょっと@ ScreamZ-この変更は、完全に静的なサイトをnextjsで構築できるようにするものだと思います。 長い間、 next exportを使用してnextjsサイトを静的にコンパイルすることができましたが、それでもgetInitialPropsを使用してクライアント側のルート遷移に関するデータをフェッチします。 getStaticPropsを使用する機能を使用すると、追加のデータをフェッチせずにクライアント側の遷移を実行できます。 getStaticPropsでフェッチされたすべてのデータは、ビルド時に1回フェッチされ、更新されません。再構築しない限り、ライブサイト。 これはデータ駆動型静的サイトの古典的なアーキテクチャであり、Webhookを介してデータソースをホストにリンクし、データソースが変更されたら、サイトを再構築するようにホストに指示します。

完全に静的なnextjsWebサイトの既存の例はたくさんあり、netlifyでnextjsサイトを実行するのは簡単です。 私の会社のウェブサイトは現在nextjsで実行されており、netlifyによってホストされています。これが良い例になることを願っています。

zeitのホスティングサービスも強く検討する価値があることは注目に値します。 価格は非常に似ており、nextjsサイトとの統合は他に類を見ません-文字通り何も構成する必要はありません。githubをリンクするだけで、zeitのホスティングはnextjsを実行していることを認識し、自動的に構成してデプロイしますすべての。

これは決して広告ではありません、私はzeitのために働いていません、ただ本物の承認です。 あなたは絶対にそれをnetlifyで動作させることができます、そして私は証拠としていくつかのサイトのために個人的に持っています。 ただし、nextjsがどのように機能するかを完全に理解する必要があり、netlifyでスムーズに実行できるようにすべてが正しく構成されていることを確認する必要があります。 nextjsサイトで最もシンプルで確実なホスティングをお探しの場合は、zeitのホスティングを試してみてください。

@jescalanこの素晴らしい共有をありがとう🙏🏻

Publish directoryを使用してoutフォルダーを指定できるため、netlifyでNextJSを使用しても問題はありません。 しかし、zeit Nowでは、言う方法はありません。SSRを使用せずに、 next export使用して静的にいっぱいにしてください。

@ScreamZこれは一種の真実ですが、「完全な静的」サイトをどの程度正確に定義するかによって異なります。 あなたが使用している場合はgetStaticPropsツァイトのホスティングサービスで、すべてのページのために、あなたが得るものを効果的にそれが実行されない場合でも、静的なサイトに等しいnext export持つすべてのページから、 getStaticPropsは、サイトがデプロイされたときにのみ構築され、その後CDNから直接提供されます。

主な違いは、私が知る限り、zeitのホスティングですべてのページを強制的に静的にする方法がないことです（編集：zeitは最近、 exportPathMapを含む構成を持つすべてのサイトが実行されるように変更しました完全に静的なサイトなので、これはもはや真実ではありません）。 getStaticPropsページは、 next exportによって生成されたページとまったく同じように動作します。ページの単一の静的コピーは、ヒットするたびにCDNから直接提供されます。 ただし、 getServerPropsまたはgetInitialPropsを使用して一部のページを実行することもでき、それらはサーバーでレンダリングされたページとして動作します。 個人的には、これはメリットだと思います。SSRルートが必要な場合は、別のデータフェッチ方法を使用するだけで、その単一ルートがSSRになり、他のすべてのルートは静的なままになります。

@jescalanありがとう、

したがって、これが実装されるのを待つ必要があります。それまでの間、静的にnetlifyを使用します。

SSG構成に関する話はありますか？ 具体的には、共有ビルドアーティファクトを使用したいのですが、QA /製品の構成が異なるnext exportを実行します。 これらの構成値は、 getStaticPropsでのみ読み取られます。 これはserverRuntimeConfigまたはpublicRuntimeConfigまたはprocess.env直接使用しますか？

@ScreamZ @jescalan @Timerと一緒にNowでzero-config next exportサポートを開始しました（彼はすべてのクレジットに値します）。 できるよ：

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

そして、それは自動的に機能します。

どうなるか教えてください🙏

ええ、私はサポートを求めた人でした、そして彼らはこれがまだ実装されていると私に言いました😅私が見る限り、あなたはconfigでエクスポートマップを定義する必要がありますか？

@ScreamZいいえ、上記のようにnext build && next exportを追加するだけで、機能します。

@timneutkens getInitialPropsをgetServerPropsに置き換えた場合でも、 Server Pre Renderingを有効にするには、構成ファイルにtarget: 'serverless'を追加する必要がありますか？ ありがとう。

どうすればこれらを試すことができますか？

どうすればこれらを試すことができますか？

これらのメソッドはすべて、認識されるために現在unstable_プレフィックスが必要だと思います。

例： unstable_getStaticProps

@timneutkens

@ScreamZ @jescalan @Timerと一緒にNowでzero-config next exportサポートを開始しました（彼はすべてのクレジットに値します）。 できるよ：

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

そして、それは自動的に機能します。

どうなるか教えてください🙏

私のビルドスクリプトはもう少し多くのことを行っていますが、それは魅力のように機能しているようです：

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

その上、それは素晴らしいです！ それはまさに私が探していたものでした😅（さようなら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は現在、私たちのチームといくつかの選択されたパートナーによって内部で徹底的にテストされています。 上記のように、 非常に実験的な動作を選択できます。 😄

ただし、APIを破壊的な方法で更新する可能性があるため、本番ワークロードを新しいメソッドに移行しないでください。

個人的には、8〜20Kページの静的サイトの生成に使用しています（一部のページで動的な要求が発生する可能性があります）。 これは非常にうまく機能します（Nowの10Kファイルの制限を除く）。残念なのは、getStaticPathsメソッドがないと、リロードのたびにgetStaticPropsが呼び出されることだけです。 良い動作の1つは、最初の呼び出しでjsonファイルが作成され、次の呼び出しでそれが使用されることです。

インクリメンタルビルドは計画されていますか？ では、新しい/変更されたコンテンツのみが再構築されますか？

上記のように、 非常に実験的な動作を選択できます。

unstable_getServerPropsメソッドをテストしたいのですが、現時点では無視されているようで、 zeit/next.jsリポジトリのどこにも見つかりません。 それはまだ実装されていませんか、それとも私はそれを間違っているだけですか？

インクリメンタルビルドは計画されていますか？ では、新しい/変更されたコンテンツのみが再構築されますか？

実装はインクリメンタル再構築を念頭に置いて設計されましたが、まだサポートされていません（このRFCではカバーされていません）。

アーキテクチャは準備ができており、これらの機能が安定した後でこれを調査しますので、ご安心ください。
これが、 getStaticPropsがページごとに定義され、アプリケーション全体に対して1回ではない理由です。

不安定な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: {...}}

また、開発サーバーを使用するときはまだ少し荒いですが、すばらしいことも付け加えておきます。

ただし、開発サーバーを使用する場合は、まだ少し荒いです。
@mikestopcontinues

これについて詳しく教えていただけますか？ 開発サーバーのエクスペリエンスについて否定的なフィードバックを寄せてくれた人は他にいません。解決してもらいたいと思っています。

@Timer私は新しいAPIが本当に好きです。 開発中の私の主な問題は、jsonがロードのたびに再要求されることです。 これによりテストの速度が低下しますが、実際にサイトを閲覧したときのユーザーエクスペリエンスが誤って表示されます。

「すべての読み込み時」とは、ページの読み込みを意味しますか？ または再構築しますか？ または...？

@mmmeff同じパスに移動するたびに、jsonが再要求されます。 したがって、2つのページ間を行ったり来たりすると、データを待つのに多くの時間が費やされます。

@mikestopcontinuesこれは意図された動作です。開発では、最新のデータが望ましい場合が多いためです。 新しい問題でいくつかのより良いヒューリスティックについて議論することにオープンになります！

@timneutkensこのRFCは非常に有望に見えます。 セキュリティと、それが正確にどのように機能するかについて、いくつか質問/懸念があります。

SSRとSSGの両方に依存する一般的なビジネスケースを考えてみましょう。

環境

ウェブサイト（別名「アプリ」）にいくつかの情報を表示したいと思います。
これらの情報は、GraphQLAPIを介してアクセスできるBDDに格納されます。
これらの情報の一部は公開されており、一部は非公開です（つまり、ユーザーの電子メール/パスワード）。

アプリは2つの段階を使用します。

• 顧客がステージングアプリでリアルタイムの変更を確認できる「ステージング」ステージ（バックオフィスなどを通じてこれらの情報を更新します）
• 顧客がアクセスできず、自分で何も更新できない「本番」段階。 本番アプリを更新するには、新しいデプロイを行う必要があります。 （彼らは、彼らの言ったバックオフィスから、新しい本番展開を行うように求めています）

このシナリオでは、SSRとSSGの両方を使用します。

• ステージングアプリはSSRを使用します。これは、GraphQL APIからデータをリアルタイムでフェッチするためです（ページの作成時）。
• 本番アプリはSSGを使用します。これは、新しいデプロイが行われると、GraphQL APIからデータをフェッチし、そこから静的ページを生成するためです（したがって、静的であり、変更されなくなり、GraphQLAPIへのクエリは行われません。実行時（少なくともページのロード時ではない））

このシナリオは十分に一般的であり、（IMHO）SSG使用の主要なユースケースの1つである必要があります。
本番アプリは、ステージングアプリのスナップショットにすぎません。

いくつかの質問：

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パラメーターを受け取ることができるのでしょうか。 それはどう違うのですか？

1:30ティムNeutkensで火、2020年1月14日には[email protected]
書きました：

@pjawshttps ：//github.com/pjaws具体的に言及されているRFC
getStaticPropsは静的生成用です。 静的HTMLは受信できません
クエリ文字列。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/zeit/next.js/issues/9524?email_source=notifications&email_token=AMVRRIQCKDJNF4MPWSLYNV3Q5WA2NA5CNFSM4JRPBEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AMVRRIRJXLYC4MC4U7DH7NDQ5WA2NANCNFSM4JRPBELQ
。

getStaticPathsでは、ビルド時にレンダリングされるページを返す必要があるためです。

これらの変更は、いつものように非常に有望で素晴らしい仕事に見えます！ 👍

ページ間で共有されるデータのニーズを満たすために、 _app.jsにgetInitialPropsを含めるユースケースについて疑問に思います（コンテキストプロバイダーの設定など）。 getStaticPropsを同じように使用することは不可能であることを正しく理解していますか？ 個々のページでのみ定義することは可能ですか？

_app.jsにgetInitialPropsを配置して、ページ間で共有されるデータのニーズを満たす（コンテキストプロバイダーの設定など）ユースケースについて疑問に思います。 getStaticPropsを同じように使用することは不可能であることを正しく理解していますか？ 個々のページでのみ定義することは可能ですか？

正解です。最初は個々のページ専用です。 後で再考するかもしれません。 _appのgetInitialPropsは、静的HTMLにエクスポートするときに引き続き呼び出されるため、getStaticPropsに段階的に移動できます。

こんにちはみんな、1つの関連する質問-資産はどのように扱われますか？ ヘッドレスCMS（wordpressやgraphcmsなど）を使用している場合、静的htmlでアセットのURLが使用されていることがわかりました。

ここには2つの設定があります-アセットリンクをそのように使用することです。
しかし、より可能性が高いのは、アセットをダウンロードし、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からキャッシュするようにCDNを設定しているため（私の場合はs3から提供されます）。

あなたのソリューションがZeitNOWを使用して私に基づいているかどうか完全にはわかりません

イメージがダウンロードされて展開の一部になると、この問題全体が大幅に単純化されます。 ベースURLからキャッシュするようにCDNを設定しているため（私の場合はs3から提供されます）。

これにより、実際にはビルドプロセスがはるかに複雑になり、10倍遅くなりますが、決して単純ではありません。

あなたのソリューションがZeitNOWを使用して私に基づいているかどうか完全にはわかりません

世界中のすべてのプロキシで動作します。 クラウドフロントを含みます。

@timneutkensは、実際にはビルドプロセス時間に依存し

私は確かにあなたが皆のためにこれをオンにすることを主張していません。 多くの人がCMSにディープリンクすることを喜んでいます。 しかし、私たちはトラフィックの多いサイトを運営しており、これは間違いなく私たちのようなサイトが必要としているものです。

また、私を許してください、しかし私はあなたの解決策を理解しませんでした。 これをどのように構成する必要がありますか？ CMSが使用するURLを制御できません。 たとえば、Datocmsはwww.datocms-assets.com/からサービスを開始します。 ＃9081のソリューションをどのように使用しますか？

実際には、ビルドプロセスの時間には依存しません。 時間がかかっても構いません

これはアプリケーションに当てはまるかもしれませんが、ほとんどのアプリケーションには当てはまりません。

ただし、多くの理由（既知のベースURLから提供されるすべてのアセットを含む）のため、これをビルドでベイク処理することを強くお勧めします。

実際には、言われている必要はありません。たとえば、 www.datocms-asset.com/*などのように/images/*をcmsurlにプロキシするリライトを使用できます。 次に、 /imagesを使用してすべての画像をリンクします。

これは話題から外れ始めていることに注意してください。

@sandysは、実際には、＃9081を使用して/ imagesからCMSに書き換えを追加すると、ソリューションがはるかに簡単になります。 ZEITなど

@timneutkens私のために物事を明確にするためだけに。 理想的な状況では、画像をハッシュしてブラウザの一意のURLで永久にキャッシュし、コンテンツ作成者はCMSで同じ名前でいつでもファイルを更新できます。 つまり、セットアップでは、CMSが次の責任を負う必要があることを提案します。

1. 画像の最適化
2. 画像をハッシュし、このハッシュで提供する
3. 画像のURLからハッシュ化された画像のURLへのマップを提供します。これはgetStaticPropsでダウンロードして、画像の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

gatsby側でも-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/#downloading -files

@sandysこれは

しかし、私たちの心のすべてにおいて、これはSSGと密接に関連していることを述べたかっただけです。 理想的なケースは、SSGエクスポートコマンドがこれを行うことです。 通常、これは他の場合には必要ありません。
最良のケースは、これが次のエクスポート時にオプション機能になることです。

しかし、あなたが望むように-あなたの決定を尊重してください。

しかし、それはnext exportが現在も行っていないことです。 したがって、それが完全に新しいものであり、このRFCとは無関係である理由。

また、 getServerPropsやオンデマンドレンダリングでは使用できません。

@Janpot CMSプロバイダーは、画像などに一意のURLを指定することで、これをすでに処理しています。

👍はい、それは理にかなっています。 ただし、プロジェクトで画像を使用し、それらを最適化してキャッシュする場合は、次の2つの選択肢があります。

1. カスタムWebpackセットアップを構築する
2. 外部CMSを使用する

編集：

そして、私が正しく理解していれば、 file-loaderはすでにCSSに含まれています。 JSでも有効にするのではないですか？

@Janpot Sandeepが言及した特定のポイントは、URLはプロジェクト自体ではなく、外部ソースから

ZEIT Nowにデプロイされたサイトの場合、新しい静的APIを使用して動的URLを持つページがある場合、 unstable_getStaticPathsを使用して静的に生成されていないページの場合、関数unstable_getStaticPropsは、404を返すのではなく、実行時にサーバー上で実行されます。

たとえば、 /blog/[slug].jsページがあり、そのgetStaticPathsは配列を返します。

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

私のgetStaticPropsは、スラッグに基づいてファイルを読み取るロジックがあります。 /blog/helloにアクセスすると、ページは期待どおりに事前レンダリングされますが、 /blog/doesnt-existような無効なページにアクセスすると、実行時にgetStaticPropsが実行され、エラー500が表示されます。または、エラー処理を追加すると、 getStaticPathsからの出力にリストされていないにもかかわらず、404ではなくページがレンダリングされます。

このロジックは意図的なものですか？

これは大きな改善です。 これを行うために、ビルド前のスクリプトを作成しようとしていました。
Next 9.2でサイトの1つをunstable_getStaticPathsとunstable_getStaticPropsに移動することをテストしたところ、うまくいきました。

exportPathMapと比較して1つの回帰があります。 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のブログが印象的でした
それはすでに野生に出ていました。

17:05ティムNeutkensで金、2020年1月17日には[email protected]
書きました：

この機能に関するすべての興奮に心から感謝します。 述べたように
他の場所では、通常、機能のタイムラインを共有しません。
彼らが適切な開発者の経験、制約、そして将来を持っていることを確認してください
証拠性。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/zeit/next.js/issues/9524?email_source=notifications&email_token=ADKINGF724256WCEFHBFIH3Q6ITRXA5CNFSM4JRPBEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ADKINGBVCG6MFMOG5U2FGMDQ6ITRXANCNFSM4JRPBELQ
。

>>

ラシターグレッグ
[email protected] [email protected]
セル（832）495-9903

getStaticPropsようなものはありますが、ページごとではなくアプリ全体で1回だけ実行されますか？

私のユースケースは、複数のページで使用されるReactコンテキスト（ PricingPlansContext ）があり、ビルド時にデータ（価格プラン）を外部サーバーから1回だけ取得することです（ 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フォローアップに感謝します。 私は2つの方法を試しましたが成功しませんでした。 文字列としてスラグ値を指定する場合は、基本的に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

私は特にeコマースサイトの観点から考えています。そこでは、URLのpathnameで製品検索のすべての側面をカバーするのは難しいでしょう。

最近ここにメッセージを投稿しましたが、返信がありません-基本的に、サイトがZEIT Nowにデプロイされると、 getStaticPropsはgetServerPropsように動作します（つまり、 getStaticPathsを無視してリクエストを処理します）動的に）-これはバグだと思いますか？

@dpfavand私も正確なことを経験しています！ CMSのページに基づく動的ページルーティングを使用して

@timneutkensフォローアップに感謝します。 私は2つの方法を試しましたが成功しませんでした。 文字列としてスラグ値を指定する場合は、基本的に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キーはありません。

ところで、小さな世界！ fastr_confでお話しいただきありがとうございます。

こんにちは@timneutkens 、

next.jsを静的サイトジェネレーターのように動作させるというアイデアに非常に興奮しています。

大量のデータが一度要求された後、別のページを生成するために使用される場合に、 getStaticPropsメソッドとgetStaticPathsメソッドをどのように使用できるかを尋ねたいと思います。

たとえば、使用可能なすべてのオブジェクトをフェッチするメソッドを持つAPIベースのCMSのJavaScriptSDKクライアントを使用しています。 これらのオブジェクトの一部はサイトページを表します。

const entries = await cmsSdkCient.getEntries();

これまで、 exportPathMapメソッドを使用して、CMSからすべてのエントリを一度にフェッチし、これらのページのパスとそのデータの間のマップを生成してきました。 exportPathMap関数は2つのことを行います。

1. ページのマップにデータと、エクスポート時にgetInitialPropsによって消費されるssr: trueを提供します
2. 同じデータを、今回はssr: false init-props.json使用して、すべてのページのパスに一致するフォルダーに配置された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メソッドと

// 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が開発モードで実行されていると仮定すると、リモートデータを再フェッチしてサイトを再構築するために、これらのメソッドを再実行するようにnext.jsに通知するにはどうすればよいですか。

@smnhこれは「単なるJavaScript」であるため、エントリを1回フェッチして、結果をデータフェッチメソッドにキャッシュできます。 他のページのgetStatic *メソッドで再度呼び出された場合、ネットワークが再度ヒットすることはありません。

2番目の質問については、自動的に行われます。 next devを実行すれば、準備は完了です。

上記のgetStaticPaths例にのみパスパラメータが表示されます。 クエリパラメータを含むSSGパスを使用することは可能ですか？ 例えば：

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

私は特にeコマースサイトの観点から考えています。そこでは、URLのpathnameで製品検索のすべての側面をカバーするのは難しいでしょう。

これはssgのコンテキストでは意味がないと思います。 SSGは、すべてのエントリに対してファイルを出力します。クエリパラメータはファイル名の一部ではないため、リクエストを実際のファイルに書き換えるにはサーバーレイヤーが必要です。 （上記の例では静的ファイル名は何ですか？）デフォルトのビュー（ファセットなしでページにアクセスした場合に得られるもの）を事前にレンダリングし、リクエストにクエリパラメーターがある場合はクライアント側で更新することを検討することをお勧めします。 しかし、それはこのSSGRFCを超えた問題になります。

@dpfavand私も正確なことを経験しています！ CMSのページに基づく動的ページルーティングを使用して

@timneutkensフォローアップに感謝します。 私は2つの方法を試しましたが成功しませんでした。 文字列としてスラグ値を指定する場合は、基本的に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キーはありません。

ところで、小さな世界！ fastr_confでお話しいただきありがとうございます。

おい！ Nextjsチームはこれに対処し始めました。現在のカナリアの実装に関するいくつかの追加の問題に対処するためのチケットが開かれています： https ：

@smnh私がやっていることは、ビルドとエクスポートを実行する前に、共有コンテンツをプリフェッチしてJSONに保存するスクリプトを作成することです。 次に、そのJSONをモジュールとしてページに直接インポートします。

再構築の場合、関連するコンテンツが変更されたときにNetlifyビルドフックをトリガーするようにCMSにWebhookを設定しました。 GetStaticPropsは、ページ固有のコンテンツをフェッチするだけです。

ありがとう@zeusdeux
NS：

2番目の質問については、自動的に行われます。 次の開発を実行すれば、準備は完了です。

それらをモジュールにキャッシュしてからCMSのデータを変更すると、キャッシュが無効になり、 devによって再実行されますが、next.jsを停止して再度実行することはありません:)

それらをモジュールにキャッシュしてからCMSのデータを変更すると、キャッシュが無効になり、 devによって再実行されますが、next.jsを停止して再度実行することはありません:)

getStaticPathsは本番ビルドでのみ呼び出されるため、その関数から呼び出された場合にのみ、フェッチメソッドにモジュール状態でキャッシュするように指示できます。

ねえ、誰かが私と同じ問題に遭遇したかどうかは見たことがありません。

unstable_getStaticProps複数のルートに同じページがあるとしましょう：

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

ソースコードは両方のページで同じであるため、複製する必要はありません。 したがって、最初のファイルにロジック付きのソースコードが含まれている場合、2番目のファイルは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- ssg。

私は何度か困惑し、これが他の人に役立つかもしれないと考えました。

zeit.co/nowにデプロイするときに、ビルド中にgetStaticPropsを使用して次のAPIルートにアクセスするにはどうすればよいですか？ 同形フェッチには絶対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ステータスコードがありません。

もちろん、完全な静的エクスポートを実行する場合、すべてが単なるファイルであるため、ステータスコードを実行する方法はありません。 getStaticPropsを使用してハイブリッドサイトをZEIT Nowにデプロイすることについて話しています。これに関係なく、すべてのページを動的パスに一致させるのではなく、 getStaticPathsを尊重し、404ページを提供する必要があるようです。

これは、Nowでの動作だけではなく、 next start同じです。

ただし、前に述べたように繰り返します。これは実験的なものであり、動作は変化する可能性があります。

しかし、 getServerPropsまたはgetInitialProps 404ページを提供することは可能です-応答コードを検討するときにgetStaticPropsがgetStaticPaths無視する場合、それは気にするサイトにとって完全に実行不可能です良いSEO。

おそらくステータスコードを処理する方法をもっと紹介しますが、ほとんどの静的サイト（CRAなど）は/*をindex.htmlにルーティングします。404はまだ200です。

こんにちはみんな、私はまっすぐな質問があります、私はいくつかのページをSSGするために新しい[unstable_]getStaticPropsを使用して簡単なウェブサイトを構築しています。 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とアンプが連携していないことを明示的にエクスポートする必要があります）が、高レベルのリクエストを行うための「良い方法」を見つけましたおよびページごとの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を明示的にエクスポート」することでした。

アンプと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から来ているものをを取得します。 小道具または別のソリューションを使用して、 <Layout />子として<Header />を注入する必要があります。 そして、それを使用したいすべてのページに<Header />インジェクションを繰り返す必要があります。

HOCアプローチでは、 <Header /> 1回追加するだけです。

そのため、可能であればコードの重複を避けるために、 @ pkral78によって提起されたものが良い点だと思いました。

そのため、可能であればコードの重複を避けるために、 @ pkral78によって提起されたものが良い点だと思いました。

それは私の頭の中にありました。 _appページにはgetStaticPropsが必要です。これは、最初のページのレンダリング中に1回呼び出され、保存されたpropsを次のレンダリングされたページに渡します。 しかし、それが適切な概念であるかどうかはまだ考えています。

この種のものが意図されたユースケースであるかどうかはわかりませんが、機能していないようです。

// /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

これは、インポートファイルのパスが動的であることについて不平を言っています

Jan Potomsの[email protected]は、2020年1月30日木曜日の00:29に次のように書いています。

この種のものかどうかわからない
https://codesandbox.io/s/nifty-cache-jspqrは意図されたユースケースですが、
うまくいかないようです：

// /pages/[...slug].jsximport ReactDOMServer from "react-dom / server";
非同期関数のエクスポートunstable_getStaticProps（{params：{slug}}）{
//これはどれくらい安全ですか？
const filePath = "../content/" + slug.join（ "/"）+ ".mdx";
const {デフォルト：コンポーネント} = await import（filePath）;
const content = ReactDOMServer.renderToStaticMarkup（Component）;
戻る {
小道具：{タイトル：slug.join（ ""）、コンテンツ}
};
}
デフォルト関数のエクスポートPage（{title、content}）{
戻る （

{題名}

）;
}

意図されたユースケースではない場合でも、次のように見えるエラーをログに記録します。
少し疑わしい：

[警告] ./ pages / [... slug] .jsx
重要な依存関係：依存関係の要求は式です

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/zeit/next.js/issues/9524?email_source=notifications&email_token=AAADKRKOL34WKTG7J5QFRJ3RAIGPBA5CNFSM4JRPBEL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAADKRIWNA2DSMWFRGD453DRAIGPBANCNFSM4JRPBELQ
。

そのため、可能であればコードの重複を避けるために、 @ pkral78によって提起されたものが良い点だと思いました。

それは私の頭の中にありました。 _appページにはgetStaticPropsが必要です。これは、最初のページのレンダリング中に1回呼び出され、保存されたpropsを次のレンダリングされたページに渡します。 しかし、それが適切な概念であるかどうかはまだ考えています。

@ pkral78 、Nextで実装されていると想像するほとんどのSSGサイトで、「共通の部分」（ヘッダー、フッター、サイドバーなど）が必要なためである可能性があります。 また、必要に応じて_appでその共通部分のクエリを作成し、各ページで手動で実行しなくても子ページで使用できるようにしないのはなぜですか。

私の唯一の懸念は、それを_app.jsに入れると、ページによっては複数の「共通部分」を持つことができないということです。 私が試作されたアイデアを、私は私が呼ばれる理由だこと」、それは私たちはあなたがレンダリングするページの種類に応じて、複数のレイアウトを持つことができるようになるので、レイアウトにそれを持ってできるようにしたかったのwithSSGLayoutに私のHOCは、SSGページだけでなく、SSRと完全にクライアントベースのページ、または複数のSSGLayoutを計画していたためです。これは、レイアウトが親のgetStaticPropsメソッドも担当できる場合に実行できます。

とにかく、NextにSSGがあると、あらゆる種類のWebサイトのツールになります🙌

@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>
  );
}

@Janpotうん！ プレーンなマークダウンを使用することもできます。これは、nextjs.org / docsに対して行うことです。

https://github.com/zeit/next.js/issues/9524#issuecomment -580207073に関しては、現在SSRでNextを使用しているのとまったく同じです。 レイアウトレベルで実行されるGraphQLリクエストがあり、そのコンテンツはアプリの共通コンポーネント（Navbar、Footer、および動的な子）と共有されます。 次に、動的な子は通常、ページ固有のコンテンツに対して別のGraphQLリクエストを作成します。

したがって、これを再利用する方法があることは重要であるように思われます。これらの共通データをフェッチするために、各ページでコードを複製する必要はありません。

おい！
私はここでかなり新しいです。 アプリをNextJSに移行する作業を開始しました。

この機能から大きな恩恵を受ける基本的なユースケースがあります-複数の言語バージョン。 私が取り組んでいるWebアプリには、1日あたり100.000以上のページビューを持つ16の言語バージョンがあり、たとえばランディングページを静的に生成できることは素晴らしいことですが、問題はルーティングです。

サーバーサイドレンダリングを使用すると、リクエストヘッダーまたはCookieを読み取り、適切な言語バージョンをレンダリングできますが、それがないと、/ en、/ de、/ frなどのすべてのバージョンのパスを作成し、「/」でNextJSにリダイレクトさせる唯一のソリューションですか？

ReactDOMServer.renderToStaticMarkupについて学習した後、 unstable_getStaticProps関数に追加しました。インタラクティブまでの時間と潜在的な最初の入力遅延の最大値が大幅に改善されたため、（モバイル）PageSpeedスコアが96から100に向上したことがわかりました。 。

JavaScriptなしでページにアクセスでき、正常に読み込まれるため、SSGを使用しているにもかかわらず、Reactはページの読み込みで作業を行っているようです。

これはReactに関する私の理解の欠如かもしれませんが、JavaScriptを使用した場合と使用しない場合のパフォーマンスは同じであり、コンポーネントの事前レンダリングが役立つとは思いません（SSGが行っていることだと思いました）。

予期されたもの、バグ、または私が間違っていることはありますか？

事前コミット： https ： https％3A％2F％2F5e310826bcf5030008a91209--josephduffynextjs.netlify.com％2Fposts％ 2Fgathered-1-0-1 mobile
コミット： https ：
コミット後： https ： https％3A％2F％2F5e3371beda1b8f0009368ef9--josephduffynextjs.netlify.com％2Fposts％2Fgathered -1-0-1 mobile

@JosephDuffy

そのため、SSGを使用しているにもかかわらず、Reactはページの読み込みで作業を行っているようです。

それはDOMを潤します。 基本的：

1. ブラウザがSSRhtmlをブラウザのDOMにロードします
2. Reactは仮想DOM全体を再構築します
3. ReactはこれらのDOMをトラバースし、同期します（ハイドレーション）

副作用やイベントハンドラーがないなど、コンテンツが本当に静的である場合は、手順2と3は不要です。 あなたの方法では、基本的にコンポーネントツリーを1つの属性を持つ1つのコンポーネントに減らします。これは、Reactがレンダリングしてハイドレイトするのに非常に高速です。 （+ dangerouslySetInnerHTMは水分補給中は無視されます）

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

イベントハンドラーと副作用はこのメソッドでは機能しないことに注意してください。

編集：

1つのアイデアは、 getStaticPropsが静的htmlを返す場合に、ページのデフォルトのエクスポートを省略できるようにすることです。 NS

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で最初のロード時間を避けたい。ZeitNow以外の他のソリューションを探す必要があるかもしれない

Next.jsは、getServerPropsの呼び出し結果を返すAPIエンドポイントも自動的に公開します。 [...] Next.jsは、この公開されたAPIエンドポイントをフェッチして、ページをクライアント側にレンダリングするために必要な小道具に変換されるJSONデータを取得します。

Next.jsは、実際のルート変更を実行してページコンポーネントをレンダリングする前に、このエンドポイントからデータをフェッチします（少なくともデフォルトでは、他の方法でそれを行うことはできません）。 そのため、特定のページが静的に生成されるため、ユーザーは非常にきびきびとしたサイトを体験する可能性がありますが、SSRページへのリンクをクリックすると、ルートが変更される少し前に突然サイトが「ハング」します。

コンポーネントを_first_でロードして、ロードインジケーター、アニメーション化されたプレースホルダーなどを入力できるようにするための推奨される方法はありますか？ （現在のページに追加する代わりに。）そうでない場合は、新しく提案された機能に関連する可能性がありますか？ getInitialPropsとrenderメソッド内のフックの組み合わせを使用してそれを達成しましたが、面倒に感じます。

この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で最初のロード時間を避けたい。ZeitNow以外の他のソリューションを探す必要があるかもしれない

@erhankaradenizと@ziltoshは、一般的に非常にすぐに展開する必要があります。 できるだけ早くサポートが必要な場合は、直接私にpingするか、 support @ zeit.coに連絡して

私は同じ問題を抱えています。
彼らがその制限を引き上げようとしていることは理解していますが、いつ展開されるかはわかりません。
したがって、すべてのページでgetStaticPropsを使用し、一部のページでのみgetStaticPathsを使用して機能します（私の製品ページは全ページの70％を生成するため、getStaticPathsを入れませんでした）。 私は制限を下回っていますが、それは完璧ではありません。最初のロードは非常に長く、404エラーを処理するのが困難です。

彼らがすぐに制限を引き上げることを願っていますが、それが20Kにならないことを願っています..それは長期的には私にとって十分ではないでしょう。
getStaticPathsで最初のロード時間を避けたい。ZeitNow以外の他のソリューションを探す必要があるかもしれない

@erhankaradenizと@Ziltoshは、一般的に非常にすぐに展開する予定です。 できるだけ早くサポートが必要な場合は、直接私にpingするか、 support @ zeit.coに連絡して

ありがとう@kvangundy
この問題についてTwitterで連絡しました;-)

@erhankaradeniz代わりに[email protected]にメールを送信できますか？ そうすれば、それは私たちのシステムに正しく行き着きます。

@flintinatux 、

私はそれがこの問題で扱われるつもりはないと思います、それはそれがトピックから外れていることを意味するので、私はそれを議論するためにどこか他の場所を見つけるでしょう:)

getInitialPropsをgetStaticPropsとgetServerPropsに分割するアプローチは、はるかにクリーンだと思います。 これがユースケースにどのように影響するかについて質問があります。
2つの別々のビルドを作成したいと思います。1つは製品サイト用の静的バージョンで、もう1つは編集環境用のSSRを使用したバージョンです。

ビルドに応じて、静的メソッドとしてgetStaticPropsとgetServerPropsを条件付きでアタッチできると考えていました（https://github.com/zeit/next.js/issues/9524#issuecomment-と同様）。 558617056）ですが、条件付きでそのままエクスポートできるかどうかはわかりません。 ビルドに応じて動的/静的をサポートできるかどうかについて何かアイデアはありますか？

その事に付いては：

• 読み込み状態： https ：
  
  
  
  • 現在取り組んでいます（＃10424）。
  
  
• プレビュー： https ：
  
  
  
  • 作業中ですので、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をpages / _error.jsにリダイレクトするようにするにはどうすればよいですか？

これはまだ実行中であり、現時点では予期しない動作ではありません。

繰り返しになりますが、実験的な機能を使用していることを思い出してください。動作はいつでも変更される可能性があります。 安定していないときにこれを使用すると、状況が変化し、すべてのバージョン間で中断する可能性があります。

@timneutkensありがとう！ 私は不安定さを理解しています。 これを管理する方法を知っていますか？ コードを調べて、_unstable_getStaticProps_内でエラーをスローすると、エラーページが表示されることに気付きました。 これは良い方法かもしれません。 エラーをそのまま_pages / _error.js_に渡す方法が必要です。 404を送信したいと思います。500になります。

以前に他のスレッドでこれを何度も投稿しましたが、「_ errorに移動する」というのは予期しない動作です。現時点では、ページは404状態をレンダリングするはずです。 if(!data.something) { return <My404Component /> }と言っただけで、 My404Componentはnoindexメタタグを設定する必要があります。

本当に？ ドキュメントでは、404に_pages /_error.js_を使用するように明確に指示されています。

参照： https ：

@ jiv-eは、次の原因による404の場合です。

• ページが見つかりません
• ファイルが見つかりません

動的ルートがある場合は、私が言ったように「404」のケースを処理する必要があります。たとえば、 https： //nextjs.org/docs/advanced-features/custom-error-page#reusing -the-built-in-error-ページ

とった！ ありがとう！

getStaticPropsを使用して、ビルド時に翻訳/言語キーをフェッチしたいと思います。これは、月に1〜2回、さらには年に1回も変更される可能性が高いためです。 また、DOM内のJSON /小道具としてそれらを必要としません。 問題は、キーを実際に使用するコンポーネントにツリーを下って渡したくないということです-私のユースケースにはどのようなアプローチが適していますか？

useTranslation（）フック（またはHOC）とコンテキスト？

AppTreeがNextGetStaticPropsコンテキスト（ getStaticProps({ AppTree }) ）の一部になると便利です。 そうしないと、ssgでapollos getDataFromTreeようなものを実行することはできません。

現時点では、getStaticPropsでAppTreeトラバーサルを許可する予定はありません。これは、パフォーマンスに非常に悪いためです（企業からの一貫したフィードバック）。 getStaticPropsをページに追加しても、_appのgetInitialPropsを通過して段階的に採用できるため、Apolloで実際に機能します。

amp: 'hybrid'とSSG機能を同時に持つことができれば素晴らしいと
これは、次のようなページに2つのファイルを作成することで実現できます。

• （SSG）index.html
• （AMP）index.amp.html

これにより、プロキシは?amp=1クエリパラメータに基づいてampドキュメントに解決できます。

amp: 'hybrid'とSSG機能を同時に持つことができれば素晴らしいと
これは、次のようなページに2つのファイルを作成することで実現できます。

• （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を使用してきましたが、これまでのところすばらしいです。

私たちが抱えていた障害の1つは、RSSフィードの生成です。 参照するコンテンツは静的に生成されるため、理想的には静的に生成します。 現在、これを行う方法がわからないため、代わりに、コンテンツをクエリして応答にXMLを書き込むことにより、サーバー側で処理しています。

HTML以外のコンテンツタイプの静的生成をサポートすることについての議論はありましたか？

参考までに、zeitでgetStaticProps使用を開始し、 --prodフラグを使用してリリースしましたが、新しいリリースではjsonファイルのキャッシュがクリアされていませんでした。 本番リリースをエイリアス機能の使用に戻すと機能し、キャッシュがクリアされました。

GatsbyからNext.jsへのtinacms.orgの移行では、新しいgetStaticProps / getStaticPaths APIを使用してきましたが、これまでのところすばらしいです。

私たちが抱えていた障害の1つは、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キーを返す必要があります。これは、 propsを返す必要があるgetStaticProps反映しています。これは変更はまだ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 Webサイトを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" } },
        ]
    }
}

オプトアウトしようとしましたが、このエラーが発生します。

エラー：/ [year]のunstable_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 Nextが静的ページを作成するたびにURIを配列にプッシュし、終了したら、配列を各XMLタグにマップし、結合して中央に挿入できるため、SSGページの実装は簡単だと思います。 <sitemapindex>タグの。 getStaticPropsは、 excludeFromSitemapという名前の戻りオブジェクトに別のキーを持つことができるため、デフォルトでは、すべてのページがsitemap.xml含まれますが、オプトアウトするオプションがあります。

その場合、開発者はどの静的ページをサイトマップに入れるかを細かく制御できます（たとえば、ページ[foo]のgetStaticPaths関数がfooパスを返した場合'abc'と'xyz'が、サイトマップには'abc'ファイルのみを含める必要があり、開発者はexcludeFromSitemapをtrueに設定できます。 getStaticPropsのパラメータ==='xyz' true場合はgetStaticProps 。

また、SSRおよび静的ページの場合、 getServerProps 、 getStaticPaths 、およびgetStaticPropsように、ページファイルから定数（つまり、 export const excludeFromSitemap = true; ）をエクスポートできる可能性があります。 getStaticPropsがエクスポートされます。

SSGページで、エクスポートされたexcludeFromSitemap定数（ページのデフォルト）があり、そのキーがgetStaticProps関数から返されるオブジェクト（パス固有）にもある場合、エクスポートされた値はデフォルトとして機能する必要がありますそのページ内のすべてのパスの値とパス固有のexcludeFromSitemapは、 getStaticPropsオブジェクトに存在する場合、ページのデフォルトをオーバーライドする必要があります（したがって、ページはexport cosnt excludeFromSitemap = true実行できます）次に、 excludeFromSitemapキーをgetStaticPropsから返されたオブジェクトに値false追加して、特定のパスを除くすべてのパスをサイトマップから除外します。

配列に追加するためのコードは次のようになります（真理値表を計算し、カルノー図を使用して最小ブール式を取得しました）。

//...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>`;
}

Next.JSの使命の一部は、ユーザーに100 SEOスコアを与えることであり、 sitemap.xmlを持っていると非常に役立つため、この機能はNext.JSにうまく収まると思います。 （ robots.txtは、サイトマップ配列にパスを追加して、そのパスを許可されていないページの別の配列に追加する条件にelseを追加して生成される可能性もあります）

現在のリリースバージョンでは、使用している場合unstable_getStaticPathsと一緒にunstable_getStaticProps中に住んでいる機能に機能を、あなたが作ることができないAPI呼び出し/api/ 。
サーバーが実行されていないため、対応する要求を行って静的​​小道具をこの方法で生成することはできません。
パス関数を提供する必要はありません（これにより、基本的にこのSSRにキャッシュが作成されますが、それでも便利です！）、またはSSGではなくSSRに依存する必要があります。

多分これはこの機能の良い追加になるでしょうか？ ここでの最善の方法がわからないので、どこか別の場所で提案を読みました。これは、SSRと/apiルートを使用してhttpリクエストをショートカットすることを提案したもので、ここでも便利です。

しかし、これはもちろん、ビルド環境でコードを実行することを意味し、他のサービスやdb呼び出しなどを呼び出します。 これを実装するときにこれを明確にする必要がありますが、この機能のクールな追加になります。

@reckterうん、私は自分と同じようなことをした。 静的に生成されている間、個別のページ要求ごとにデータベースに接続する必要がありました。 とても奇妙に感じました...

それが最終的なユースケースではないことを願っています

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
   }
  }
}

GraphQLAPIに対して同じことを行うのは難しいでしょう。 また、ほとんどの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
この場合には追加する必要がありますgetStaticPathsし、 getStaticProps index.jsを除くすべてのページのための機能。
mdxページがいくつかある場合、プロジェクトの保守はより困難になります

静的getStaticPaths getStaticPropsメソッドへの変更または互換性を検討してください。 https://github.com/zeit/next.js/issues/9524#issuecomment -558617056
その場合、ページは高階関数または高階コンポーネント（HOC）でラップできます。
このようにして、コードはtypesscriptにとってより保守しやすく、より便利になります。

ツリーシェイクとダイナミック。 なんという頭痛の種のトレードオフ。😂

9.2.3-canary.13を使用して、getStaticPathsで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を使用して、getStaticPathsで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: [] }

マップを1レベル高くする必要があると思うので、mapは現在持っているオブジェクトを返しますが、固有のスラッグがあります。 パスにマッピングする代わりに。

nextjsのバージョンはまだ更新していませんが、同様のはずです。

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

@jorngeorgそれはオープンPRです： https ：

素晴らしい貢献！ 静的レンダリングプロセスが本当に改善されます。

動的ルートでは、 getStaticProps呼び出さなくても「フォールバック」が生成されることをドキュメントに追加することをお勧めします。つまり、小道具が空の場合を考慮してコンポーネントをコーディングする必要があります。

または、フォールバックを作成するときにコンテキストなしでgetStaticPropsを呼び出すように動作を変更することもできます。 これは、 next export現在どのように機能しているかと一致します（たとえば、 /p/[id].jsは、コンテキストなしでgetInitialPropsを実行することにより、 /p/[id].htmlエクスポートされます）。

• getStaticProps - next build時点で静的生成（SSG）にオプトインします。
• getServerProps -オンデマンドでレンダリングするサーバー側レンダリング（SSR）にオプトインします。

10722

getServerPropsの名前をgetServerSidePropsに変更します。

動的ルートでは、 getStaticProps呼び出さなくても「フォールバック」が生成されることをドキュメントに追加することをお勧めします。つまり、小道具が空の場合を考慮してコンポーネントをコーディングする必要があります。

言及するのに良い点です！ 私はそれを逃したので、いくつかのビルド/デプロイメントエラーもありました。

変更を反映するようにRFCを更新しました

@timneutkens

• 同じパスへの後続のリクエストは、生成されたページを提供します

これは、Next.jsが生成されたページをキャッシュすることを意味すると思いますか？ これはメモリ内キャッシュですか？ このキャッシュは制限によって制限されていますか、それともメモリリークが発生する可能性がありますか？

next startを使用すると、現在のキャッシュの例と同様のlru-cacheが使用されます。現在、デフォルトの制限は50MBです。後で設定できるようになる可能性があります： https ：

ZEITでホストする場合生成とキャッシュはCDN /プロキシで行われるため、動作が少し異なり、メモリリークやlru制限を超えているかどうかを心配する必要はありません。

👍わかりました、合理的なようです。 それは多かれ少なかれ、私が賢明なデフォルトの振る舞いとして考えていたものです。

• getStaticProps - next build時点で静的生成（SSG）にオプトインします。
• getServerProps -オンデマンドでレンダリングするサーバー側レンダリング（SSR）にオプトインします。

10722

getServerPropsの名前をgetServerSidePropsに変更します。

なぜ名前を変更するのですか？ IMHO getServerPropsは十分に正確で、入力するのに短いので、Sideを追加するのは冗長だと感じます。

getStaticPathsメソッドに変更が加えられているかどうか疑問に思いましたか？ 私の動的ページは静的ページとして生成されなくなりました。ラムダ関数としてエクスポートされるようになりましたか？

ページが最初にラムダとしてレンダリングされ、特定のページにアクセスした後にのみページが静的ページに生成されるというデフォルトの動作が正しい場合、私は正しいですか？ （フォールバックで述べたように）

@erhankaradeniz getStaticPaths変更が加えられていないため、ページがラムダになります。 これは、使用上のエラーである可能性があります。

問題を特定できるように、コードを表示していただけますか？

@Timerは今のところ[email protected]に戻っており、パスで機能しない理由がわかるまで、引き続きparamsを使用できます。

これは私が現在私のパスを生成した方法です：

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 。

このために開かれている機能リクエストがあります： //github.com/zeit/next.js/issues/10488

まず第一に、これは素晴らしいです。 私はNext.jsにこのようなものがあることを望んでいたので、最終的にGatsby.jsから離れて、ハイブリッドアプリ（静的+動的）を使用できるようになりました。

🚀カナリアを試してみましたが、半分焼きたての複雑なアプリバージョンは問題なく動作しました。 私はここですべてのコメントを読んだわけではないことを告白しますが、ツリーシェイクがまだ実装されているかどうかはわかりません。

🤔 getStaticPathsは、SSG動作の静的パスを定義しているsetStaticPathsように感じます。 そういうのは少し戸惑いました。

🧐ビルドカテゴリを設定することでビルド時間を改善できるかどうか疑問に思いますか？ これによりセットアップが複雑になることはわかっていますが、それだけの価値はあります。 説明させてください：

私たちのようなものがsetBuildCategoryとセットにblogまたはpagesまたは誰かが望んでいるものは何でも2020-content 。 次に、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リクエストがまったくないときに、Cookieを
実際の訪問者の要求に依存するバックエンドを持つルートは、「静的」および「動的」の定義によって静的にすることはできません。 静的と認証を組み合わせることができないことは言うまでもありません...それは、認証部分がページではなく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リクエストがまったくないときに、Cookieを
実際の訪問者の要求に依存するバックエンドを持つルートは、「静的」および「動的」の定義によって静的にすることはできません。 静的と認証を組み合わせることができないことは言うまでもありません...それは、認証部分がページではなくAPIとクライアントコードに属するだけです。

その場合のフォールバックオプションを誤解しているかもしれません。 あなたが言っていることは、ビルド時のコンテキストでは完全に理にかなっています。

事前定義されたルートがない場合のfallback: trueではありませんか？ その場合、ブラウザからフォールバックに到達しますね。

@tylermcrobertはいfallback: trueケースにはリクエストがありますが、APIは「最小公分母」によって統合する必要があります。 すべてが1つの施設のセットで構築され、その後、まったく異なる施設のセットで段階的に更新される稼働中のシステムを想像することはできません。 支援するのは大惨事になります。

これらのインクリメンタルビルドがビルド間でキャッシュされるという点を見逃していると思います。 したがって、最初の訪問者の役割は、結果として生じるすべてのユーザーのビルド結果に影響を与えます。 悪い考えのように聞こえます。

@ ivan-kleshnin私は理解しており、確かに同意します。 私が尋ねる理由は、私の特定のユースケースのためです。

プレビュー機能を可能にするヘッドレスCMSを使用しているので、プレビューする必要のあるページはビルド時に含まれません（プレビューされるエントリはこの時点では存在しないため）。 これはフォールバックオプションが登場するケースだと思いました。

そのプレビューにアクセスするには、Cookieを介して提供されるAPIプレビュー参照にアクセスする必要があります。

これは、 useStaticProps完全に廃棄する必要がある場合ですか？ ドキュメントをプレビューできないため、静的ビルドのメリットを失いたくありません。

gatsbyのようなものに対するこのRFCの魅力は、静的サイト生成による「ハイブリッド制御」を提供し、ヘッドレスCMSでの作業を軽減することです。

プレビュー機能を可能にするヘッドレスCMSを使用しているので、プレビューする必要のあるページはビルド時に含まれません（プレビューされるエントリはこの時点では存在しないため）。 これはフォールバックオプションが登場するケースだと思いました。

しばらくお待ちください🕵

したがって、これが正しいことを理解していれば、たとえばユーザーが登録した場合（新しいページ/ユーザーであるため静的ページは生成されません）、フォールバックtrueを使用できますが、プロファイルにアクセスすると自動的に生成されますか？

Erhan Karadeniz
http://www.erhankaradeniz.com

2020年3月4日の20:25に、TimNeutkensの[email protected]は次のように書いています。

。
プレビュー機能を可能にするヘッドレスCMSを使用しているので、プレビューする必要のあるページはビルド時に含まれません（プレビューされるエントリはこの時点では存在しないため）。 これはフォールバックオプションが登場するケースだと思いました。

しばらくお待ちください🕵

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、登録を解除してください。

そのクライアント側をフェッチしたいので、ユーザーデータは悪い例です。 フォールバックは、ビルド時に生成されていないページを静的に生成するオンデマンド用にあります。 たとえば、ビルド時に上位100のブログ投稿を生成し、トラフィックの少ない他のブログ投稿を生成したくない場合があります。

ドキュメントはまもなく上陸します。

ええ、私が意味したのはプレースホルダーページでした。確かにクライアント側でユーザーデータをフェッチします。

@timneutkens静的に生成された特定のページを削除または再構築する方法はありますか？

やあ！！！ 最適なアプリケーションのように聞こえます。 私はReactとNextの両方が大好きです!!! すべてがとてもエレガントでシンプルに使えるようになりました!! しかし、この例には概念ブログが含まれています。 ヘッドレスCMSにクエリを実行し、静的アイテムとしてのエクスポートとしてページ/投稿ごとにフェッチを実行する場合の実装例を確認したいと思います。

//金曜日が近いので、乾杯!!!

@timneutkensこれはエキサイティングです👌

私たちが頻繁にヒットするシナリオの1つであり、動的ルートまたはループ内のプロジェクトの生成を除いて、next.jsまたはgatsbyを使用した完全なソリューションはまだありません。

歴史的な理由から、価格、通貨、サポート電話番号、言語セレクターを除いて、同じ/正確なページを提供する複数のドメインを処理する必要があります（これを変更する意欲はありません）。 本質的に、これらのマーケティングページのほとんどはかなり静的であり、毎日または毎週作成するだけで十分です（すべてのリクエストでレンダリングする必要があります）。

私の質問/考え:(将来的に） getStaticPathsがルートパラメータではないものに基づいてページを生成する方法はありますが、リクエストレベルでそれらを切り替えるために使用できます（サーバーレスなど）関数は、 locale基づいて静的なビルド済みの結果を返します）

具体的には、 https://mysite.com/my-productとhttps://mysite.co.uk/my-productが2つの異なる静的ページを提供することを意味しますが、次のアプリを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はあまり動的なものと一緒に使用すべきではないため、これが有効なユースケースであるかどうかはわかりませんが、共有するのは興味深いエッジケースだと思いました（取得を担当するRouteAPIエンドポイントを完全に想像できます）別のAPIからのデータを再フォーマットします。

@martpieこのコメントをチェックすることをおhttps ：

Next.js 9.3では、次世代の静的サイト生成（SSG）サポートが安定版としてリリースされました。

このリリースには、「プレビューモード」のサポート、または静的に事前レンダリングされたページをバイパスして、許可されたユーザーに対してオンデマンドでページをレンダリングする機能も含ま

あなたは私たちのブログ投稿でそれについてもっと読むことができドキュメントにアクセスしてください。

Next.js GitHubコミュニティに質問を投稿してください！

これはとてもクールです！ 頑張ってくれてありがとう！

この新機能は現在、sagaとreduxでは機能しないようです