Gatsby: クライアント側ルーティングを無効にしますか？

サーバーがレンダリングしているパスがわからないのはなぜですか？

パスがわからないということは少なくなりますが（パスに一致する正規表現を記述できます）、重なりが大きくなります。 実際のセットアップは、gatsbyサイトを含む多数の異なるアプリへのリバースプロキシを行うApacheサーバーの背後にあります。 これらのアプリのいずれかが使用できなくなった場合、または内部サーバーエラーが返された場合は、gatsbyサイトの一部であるカスタムエラーページが返されます。

したがって、いつでもapp1が使用できないか誤動作している場合、/ app1へのリクエストは/error/unavailable.htmlまたは/error/internal.htmlのコンテンツを返し、app2などにも同じことが当てはまります。 。

使用してmatchPathのように/^(app1|app2)/.*/ので、両方とも使用できない内部エラーページ上ではないが行う作業をfindPage知らない私は実際に意図したページ（URLに基づきます）ユーザーに表示します。

グローバル変数を使用し、 ___historyと___loaderをonClientEntry 「パッチ」することで、何かを機能させることができました。 これらのグローバルを公開するgatsbyに依存しているため、非常に脆弱です。これを一般化してgatsbyに追加する方法があるかどうかはわかりません。

• パッチ適用履歴は、 props.location.pathnameを使用して通話をキャッチします
  component-renderer.js＃L18-L28

• パッチローダーはwindow.location.pathname直接使用をキャッチします
  プロダクション-app.js＃L155

// gatsby-browser.js
exports.onClientEntry = () => {
  // Check for a custom pathname
  const pathname = global.___pathname
  if (!pathname) return

  // Override the history location
  const history = global.___history
  history.location.pathname = pathname

  // Patch the resource loader
  const loader = global.___loader
  const { getResourcesForPathname } = loader

  loader.getResourcesForPathname = (path, ...args) => {
    return getResourcesForPathname(path === location.pathname ? pathname : path, ...args)
  }
}

// src/pages/page1.js
import React from "react"
import Helmet from 'react-helmet'

export default () => (
  <div>
    <Helmet>
      <script>{`window.___pathname = '/page1'`}</script>
    </Helmet>
    <div>Page 1!</div>
  </div>
)

また、この機能を無効にするビルドオプションが必要であることに同意します。 また、型にはまらない設定があり、完全なGatsbyサイトへの移行が完了するまで、この機能を一時的に無効にします。

ビルド時の単純なフラグが最適です。

これはどう？ これに対する解決策はありますか？

最終的に、必要なパスに一致するようにpages.jsonを変更しました。 基本的に、パス名を修正してaddPagesArrayを呼び出します。

なぜこれがエラーをスローするのかまだわかりませんか？ ページは正常に読み込まれ、機能します。 これは、パスと一致しない場合、せいぜい警告になるはずです。

そうは言っても、configsvsランタイムコードを介してpages.jsonを変更するよりエレガントな方法があるかどうかはわかりません。

この問題をぶつけたい。

私が取り組んでいるプロジェクトでも同様の問題が発生しています。 シングルページのギャツビーアプリを構築するランディングページジェネレーターを構築しています。 この問題は、ドメイン外のランディングページを提供しようとしたときに発生します。

たとえば、メインのGatsbyアプリwww.example.comます。 Gatsbyのランディングページを取得してwww.example.com/trial提供するサービスがあります。 したがって、ランディングページのURLはwww.example.com/trail/ad-123のようになります。すべてのJSが読み込まれ、ルーターが引き継ぐまで、ページは最初は正常に読み込まれます。 ランディングページはパスを確認し、それがどこにあるかわからないため、パスを変更してページをルートに配置しようとします。これは、このwww.example.com/ad-123 、結果として404リダイレクトになります。

これを修正するための構成可能なオプションを追加する計画はありますか？ ギャツビーチームはPRを受け入れますか？

@ alex-greco-harrysパスプレフィックスは、そのシナリオで使用したいもののようです。

また、自分のWebサイトでGoogle Adsenseを適切に実行するには、クライアント側のルーティングを無効にする必要がありました。

Google Adsenseの自動広告はクライアント側のルーティングを検出せず、ルートが更新されても広告は更新されません。

とにかく、クライアント側のルーティングを無効にすることはできますか？

そのような場合は、 gatsby-link代わりにaタグを使用できます

グローバル変数を使用し、 ___historyと___loaderをonClientEntry 「パッチ」することで、何かを機能させることができました。 これらのグローバルを公開するgatsbyに依存しているため、非常に脆弱です。これを一般化してgatsbyに追加する方法があるかどうかはわかりません。

• パッチ適用履歴は、 props.location.pathnameを使用して通話をキャッチします
  component-renderer.js＃L18-L28
• パッチローダーはwindow.location.pathname直接使用をキャッチします
  プロダクション-app.js＃L155

// gatsby-browser.js
exports.onClientEntry = () => {
  // Check for a custom pathname
  const pathname = global.___pathname
  if (!pathname) return

  // Override the history location
  const history = global.___history
  history.location.pathname = pathname

  // Patch the resource loader
  const loader = global.___loader
  const { getResourcesForPathname } = loader

  loader.getResourcesForPathname = (path, ...args) => {
    return getResourcesForPathname(path === location.pathname ? pathname : path, ...args)
  }
}

// src/pages/page1.js
import React from "react"
import Helmet from 'react-helmet'

export default () => (
  <div>
    <Helmet>
      <script>{`window.___pathname = '/page1'`}</script>
    </Helmet>
    <div>Page 1!</div>
  </div>
)

@TuckerWhitehouseどこから___history 、 ___loaderを入手していますか？ あなたの例を複製しようとすると、グローバルのこれら2つのプロパティはundfinedです。

@ alex-greco-harrysパスプレフィックスは、そのシナリオで使用したいもののようです。

@ jgierer12それは私の問題の最初の部分を解決するのに役立ちます。 2つ目は、ページがレンダリングされるまで最終パスが不明であるということです。 静的ページのコレクションを取得し、コンバージョン率に基づいてそれらを提供する学習サービスがあります。 したがって、パスexample.com/go/で、ページのコレクションの1つを提供できます。 したがって、 example.com/go/first-pageやexample.com/go/second-pageようなパスでページを提供することはありません。 これらは両方ともexample.com/go/pageパスで提供されます。

基本的に、私が達成しようとしているのは、好きなパスでgatsbyページを提供することです。

@ alex-greco-harrysこれらのグローバルはgatsbyv1によって公開されました。 v2へのアップグレードにより、基盤となるルーターがreact-routerからreach-routerに切り替えられたことがわかっているので、これらのグローバルが影響を受けたと思います。

また、Gatsbyを使用してシングルページアプリケーションを構築したいと考えており、ルーティングを完全に無効にしたいと考えています。 V2と互換性のある回避策（ @TuckerWhitehouseの）を知っている人はいますか？

更新：
クライアント側のルーティングを_無効にする_解決策を見つけることはできませんでしたが、次のように設定することで、@ alex-greco-harrysなどによって参照されるリダイレクトを防ぐことができました。

window.page = window.page || {};
window.page.path = window.location.pathname;

gatsby-browser.jsで、production-app.jsのこの条件付きチェックを短絡します。 その条件付きリダイレクトは、「正規パスを実際のパスと一致させる」ことを試み、上記で参照されている（IMO）予期しない動作を引き起こします。

私もこれが必要です。

現在、ギャツビーが生成したコードを別のプロジェクトで使用しており、複数のページで使用しています。 Gatsbyは静的コードを生成するため、使用しています。 したがって、 pathPrefixを使用して、特定のパスの下ですべてを生成して提供できるようにしました。 そうすれば、すべてがそこで要求され、ページのフラグメントとしてレンダリングされます。 ただし、スクリプト内にあるため、 pathPrefixへの不要なリダイレクトが常に発生します。 ビルドするたびに、

また、Gatsbyを使用してシングルページアプリケーションを構築したいと考えており、ルーティングを完全に無効にしたいと考えています。 V2と互換性のある回避策（ @TuckerWhitehouseの）を知っている人はいますか？

更新：
クライアント側のルーティングを_無効にする_解決策を見つけることはできませんでしたが、次のように設定することで、@ alex-greco-harrysなどによって参照されるリダイレクトを防ぐことができました。

window.page = window.page || {};
window.page.path = window.location.pathname;

gatsby-browser.jsで、production-app.jsのこの条件付きチェックを短絡します。 その条件付きリダイレクトは、「正規パスを実際のパスと一致させる」ことを試み、上記で参照されている（IMO）予期しない動作を引き起こします。

@ethagnawl私は、任意のURLで提供できるシングルページアプリを作成するためのハッキーな種類のソリューションを持っています。 単一ページとは、実際にはルーティングがまったくない単一ページを意味します。

次のGatsbyの例を見ると、 https ：

15行目でこのファイルを編集し<Page path="/*" {...props} /> 、16行目を削除できます。このアプリケーションをビルドすると、どのパスでも、定義したPageが提供されます。 そこから、そのPage好きなように作ることができます。 これで、このページを任意のパスでホストする必要がある場合、リダイレクトは表示されません。

このソリューションがアプリ内の複数のページでどのように機能するかを理解できませんでした。 私のプロジェクトの目標は、任意のURLで単一のギャツビーページ（マーケティングランディングページ）を提供することでした。

これがユースケースに役立つかどうかはわかりませんが、将来の発見につながる可能性があります。

ドキュメントのhtml.jsのカスタマイズの指示に従い、 {this.props.postBodyComponents}を削除することで、これを実現できました。

https://www.gatsbyjs.org/docs/custom-html/

このスレッドがどれだけアクティブであるかに基づいて、この動作を望むユーザーの数は自明ではないようです。

ユースケースをすばやく繰り返すために：静的な_site_ジェネレーターではなく静的な_page_ジェネレーターとしてGatsbyを使用したい（

それで、クライアント側のルーティングを無効にしてトップレベルの構成オプションになる機能に期待はありますか？ 私はPRを提出したいと思いますが、それが受け入れられる可能性がない場合は、それに時間を費やしたくありません。

これは、@ ethagnawlを追加するための合理的な機能のようです。 これは非常に特殊なエッジケースであるため、人々が自分のしていることを完全に意識できるように、dangeouslySetInnerHTMLのような非常に長くて不快な名前が必要になると思います。

この問題に対処するPRでの私の最初のパスは、ここにあります。 この問題にぶつかったメンテナや他のユーザーからのフィードバックをいただければ幸いです。

aPR @ ethagnawlを作成していただきありがとうございます

次の機能が機能しない理由をもう一度思い出してください。

// Implement the Gatsby API “onCreatePage”. This is
// called after every page is created.
exports.onCreatePage = ({ page, actions }) => {
  const { createPage } = actions;
  page.matchPath = `${page.path}*`;
  createPage(page);
};

@wardpeet私はそれがうまくいくと確信しており、私が上で述べた解決策に似て@TuckerWhitehouseが提供するソリューションを参照してください。これは機能しなくなりました）。

IMOは、この概念を体系化することは価値があります。これも、ドキュメントをより簡単にし、このフラグを使用して、バイパス/ヌーピングなどによって追加の最適化を行うこともできるためです。 Gatsbyがこのように使用されている場合は関係のない機能。

さらに、 matchPathを使用するには、レンダリングするページを反映するブラウザのURLが必要ですが、これは、gatsbyサイトを不明な場所に挿入しているときに機能しなくなります。 （私の最初の問題は、Apacheリバースプロキシの背後にギャツビーがあり、特定のページがレンダリングされる原因となるルートがわからないことでした）。

@ethagnawlページレベル（ page.__disable_client_side_routing__ = true ）でルーティングを無効にすることは可能だと思いますか？ これはおそらく私が抱えていた元の問題も解決するでしょう。

ページレベルでルーティングを無効にすることは可能だと思いますか

なぜだかわかりませんか？ それは私の提案した解決策に追加されるのでしょうか、それとも代わりになるのでしょうか？ 後者の場合、ページレベルでそれを行うことに利点はありますか？

私はこのリポジトリを設定しました:)
https://github.com/wardpeet/gatsby-plugin-static-site

これがユースケースで機能するかどうかわからない。
今のところあなたはする必要があります

git clone https://github.com/wardpeet/gatsby-plugin-static-site
npm install
npm run build
npm link

cd "into your project"
npm link gatsby-plugin-static-site

gatsby-config.jsにgatsby-plugin-static-siteを追加します

これがあなたのユースケースに問題がないかどうか教えてください、私は実際にそれをサポートするつもりはないので、私はそれを転送してうれしいです：smile：

gitignoreファイルに問題があったため、リポジトリを更新しました（@ m-allansonに感謝）。 また、自分の名前でnpmに公開しました。

だからインストールを行うことができます

npm install --save @wardpeet/gatsby-plugin-static-site

@wardpeet/gatsby-plugin-static-siteをgatsby-config.jsonに追加します

これが良さそうな場合は、開発のためにこの動作を無効にするためのいくつかのテストといくつかのオプションを追加できます。

ひや！

この問題は静かになりました。 不気味な静か。 👻

多くの問題が発生しているため、現在、30日間使用されなかった後に問題をクローズしています。 ここでの最後の更新から少なくとも20日が経過しています。

この問題を見逃した場合、または開いたままにしておきたい場合は、ここに返信してください。 この問題を開いたままにするために、「古くない」というラベルを追加することもできます。

Gatsbyコミュニティに参加していただきありがとうございます。 💪💜

レビューを待っているように見えるので、これを開いたままにしておきたい

古くないかどうかはわかりませんが、修正を加えてフィードバックをもらいたいと思っています。
https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -470075540

誰も応答しない場合は、おそらく解決されているので、これを閉じることをお勧めします。

@wardpeetは、そのプラグインを使用して、クライアント側のルーティングを条件付きで無効にすることは可能ですか？

@wardpeet IIRC、提案された修正は、この機能をGatsby構成オプションとして追加するプロセスの最初のステップです（おそらく最終的に）。 したがって、この問題とギャツビーに関する限り、その_sort of_は帯域外になりますが、その会話を続けるには、この問題を開いたままにしておく必要があると主張するかもしれません。

@wardpeetの元の問題は、特定のルートのクライアント側ルーティングを無効にすることでした。@ ethagnawlは、プラグインが対処していると私が信じているサイト全体のルーティングを無効にするユースケースを提起しました。

古いCMSのサイトをGatsbyに移行する間、クライアント側のルーティングを一時的に無効にする必要があります。 スイッチを完全にギャツビーに切り替える前に、一度に1ページずつ実行しています。

@wardpeetプラグインを試し

@brianbento複製はありますか？ リポジトリhttps://github.com/wardpeet/gatsby-plugin-static-siteで問題を作成できる場合は、不足しているものを確認できます

@wardpeet私は何かを起こすことができるかどうかを確認します。 主な問題は、pathPrefixを使用すると、前述の「修正」（https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment-465497418）が機能しないことです。 常にアドレスを期待どおりに「修正」します。

@brianbento上記の解決策を試しまし

@ethagnawlそれでもURL修正を取得すると、パスプレフィックスが2倍になります。

そう "/「は」になります//「カノニカルが一致しなかった後。

多分私はそれを間違って実装しています。 ページにパスプレフィックスを使用しましたか？ 静的サイトプラグインをアクティブにする必要がありますか？

ページにパスプレフィックスを使用しましたか？

はい。 また、このブランチを使用してリモートアセットを許可していました。 したがって、ブランチが動作を導入して、修正が機能するようになったのは_可能性があります_。

ただし、最初はハックだったため、最近のGatsbyリリース（私は追いついていない）が私の「解決策」を破った可能性が高くなります。

@ethagnawlとても役に立ちました！ ありがとうございました！ @DSchauがassetPrefix機能をテストするためにいくつかのプラグインを作成したことを私は知っています。 試してみます！

パスプレフィックスも使用する必要がある場合、 @ wardpeetソリューションは機能しないよう__disable_client_side_routing__を提案したようなソリューションがあると、非常に便利です。 合併を検討される場合は、喜んで取り組み、PRを提出させていただきます。 そのアイデアに対するサポートはありますか、それともロードマップに適合しないと思いますか？

@xavivars確かに、それが欲しいのですが、便利だと思います。

@xavivarsしばらく前にその機能をパスしましたが、 @ wardpeetのソリューションを支持して閉じられました。 そのアプローチを再検討することを検討する場合は、私の試みを検討する価値があるかもしれません。

ありがとう@ethagnawl ！ 私はあなたのアプローチを調べました、そしてそれは私が考えていたものとほとんど同じでした。

@wardpeetソリューションは別のユースケースをカバーしていると思います。リンクが実際にブラウザーlocation.href変更しているため、アプリはSPAとして動作しないため、「サーバー側」に移動します。 しかし、最初のリダイレクトがまだ行われているため、ユースケースで機能させることができませんでした。私の最初の仮説は、この条件をtrueと評価するprefixPathとの何らかの相互作用があるというものです。

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/cache-dir/production-app.js#L65

正常に動作させることができましたか？

修正が必要なことをちょっと忘れてしまったので、誰かが実際の問題を説明してくれれば、プラグインでさらに作業を行うことができるかもしれません。 たぶん、これのほとんどは、新しくマージされたassetPrefixオプションによって解決できますか？

理解できなくてすみません。

@xavivars

正常に動作させることができましたか？

私のハックと提出されたPRはどちらも、私のユースケースでは「適切に機能」していました。リダイレクトのない単一の静的ページ生成です。 Gatsbyチームは、アプリレベルの構成オプションではなくプラグインを好むようだったので、PRをあきらめました。

@wardpeetのプラグインを試すことはできませんでした。公開されるまでに、作業中のGatsbyプロジェクトをすでにまとめていたからです。 ですから、それが_正しく機能していた_かどうかについてはコメントできません。

@wardpeet ：assetPrefixはそれを修正しません。 プラグイン（基本的に、クリックするとクライアント側の「ナビゲーション」を無効にする）と、数か月前に@ethagnawlが言及した回避策の両方を使用して機能させることができました。

https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -453244611

この回避策は、 onClientEntryで発生する「navigate」イベントを無効にするために必要です。 そこにフックを追加し、その回避策を適用することを修正しました（page.pathを実際のパスに強制します）。 しかし、それが何らかの副作用を持っているかどうか、そしてそれが機能しなくなるまでにどれくらいの時間がかかるのか私にはわかりません（ハック以上ではありません）。

理想的には、gatsbyを「静的ページジェネレーター」として使用していると思われる人の数を考えると、これはアプリレベルの構成である必要があると思います。

@xavivars回避策として共有できるリンクはありますか？

実際にはそうではありませんが、これはほとんどそれです：

前述の静的プラグインをgast​​by-browser.jsに追加します

exports.onClientEntry = () => {
    window.page = window.page || {};
    window.page.path = window.location.pathname;
}

以下も機能しますが、gatsbyの内部に依存しています。

export function onInitialClientRender() {
  window.___navigate = (to, { replace }) => {
    if (replace) {
      window.location.replace(to);
    } else {
      window.location.assign(to);
    }
  };
}

https://github.com/wardpeet/gatsby-plugin-static-site＆assetPrefixの使用は機能し

例を機能させたリンクされた問題。これが実際に必要なものかどうかわからない。
https://github.com/wardpeet/gatsby-plugin-static-site/issues/1#issuecomment -494802726

私にとっては、gatsbyプラグインの静的サイト+ AssetPrefix +上記のように「ナビゲート」を無効にするという3つのことすべてで機能しました

ここで何が必要かを理解するのにまだ苦労しているようです。 gatsby-plugin-static-siteとassetPrefixで問題を修正できました。

@wardpeet gatsby-plugin-staticを使用するデモへのリンクはありますか？

@ethagnawlお待たせして申し訳ありません。

私はデモを作りました：
https://github.com/wardpeet/gatsby-demos/tree/static-asset-prefix

サイトはライブです：
https://zen-wright-33c2d8.netlify.com/

予想どおり（および@TuckerWhitehouseと@ethagnawlが予想）、 https： //github.com/gatsbyjs/gatsby/issues/4337#issuecomment -453244611で提供されているような壊れやすいソリューションは、変更により機能しなくなりましたGatsby 2.9.2では、いくつかの理由があります。

最初のものは、解決可能ですが、この行は
window.page.path = window.location.pathname;
に置き換える必要があります
window.pagePath = window.location.pathname;
URLクライアント側の変更を回避するため。

ただし、これには望ましくない副作用があります。pagePathは_wrong_パスで設定され、page-data.jsonはロードされなくなります（ページの元のパスに依存し、最終的にレンダリングされるパスではないため）

https://github.com/gatsbyjs/gatsby/commit/49fd769f695ccfa6e990e3eaae7c886f073db19b#diff -2d21ea42ec874a0988977e57b17251aa

これを機能させる唯一のオプションは、 __disable_client_side_routing__ような変数を実際に導入するか、少なくとも__disable_client_side_canonical_redirect__を導入して、この条件を短絡させることだと思われます： https ：

@wardpeet ：そのような構成変数の導入に問題はありますか？

むしろ、これらのエスケープハッチをコアで有効にしたくありません。 私がこの問題について基本的に理解しているのは、これです。

gatsbyサイトとパス/ my-special-pathがあり、サーバー上に/ something-elseというルートがあります。 / somethingを/ gatsby / my-special-pathに書き換えると、ページを/ my-special-pathに変更しようとするため、機能しませんか？

もしそうなら、プラグインで修正できるかどうかを確認します。 これのライブデモはありますか？

はい、それはまさに問題です。 別のPRをまとめようとします（https://github.com/gatsbyjs/gatsby/pull/15173のようにグローバル構成変数として侵襲的なものを追加しません）。

数分で別のPRとしてプッシュするのに受け入れられるかもしれない何かがあります

@wardpeetこれは、プラグインを拡張できるようにGatsbyに追加するために必要だと私が思うものです。 PRにいくつかの例とドキュメントを追加しました

https://github.com/gatsbyjs/gatsby/pull/15180

Discordで@DSchauと会話した後、コアの貢献者は、＃15173や＃15180のようなソリューションはコアではなく、プラグインに存在するべきであると調整されているようです。 だから私はそれを解決するために他のオプションを探求したいと思います。

現在、私が見つけた唯一の方法は、グローバル構成変数（＃15173）を使用して正規リダイレクトチェックを短絡するか、gatsby（＃15180）の認識されたレンダリングURLを変更できるようにすることでした。したがって、正規リダイレクトチェックは直接依存しません。 window.locationですが、フィルター可能な変数です。

私見、課題は、プラグインを使用して、現在拡張可能/オーバーライド可能ではないように見えるものを拡張/オーバーライドすることです（どこからも値を挿入せずにwindow.location直接依存すると、私にとって非常に困難になります）、ただし、コアのコードを変更せずにこの動作を実装する方法は他にもあるかもしれません。

@xavivars https://github.com/wardpeet/gatsby-plugin-static-site/pull/4をマージし、この修正を公開します。

デモ：（5ページには正規のリダイレクトがあります）
https://static-asset-prefix--zen-wright-33c2d8.netlify.com/

@ wardpeet / gatsby-plugin-static-siteバージョン0.1.0を公開しました。 これでこの問題が修正されるはずです。 すべての問題が解決しなかった場合は、お気軽に再開してください。

静的サイトのサポートを改善する最善の方法は、プラグイン自体に問題を作成することです。 https://github.com/wardpeet/gatsby-plugin-static-site/issues/new

上記のプラグインを使用した後、誰かがこれに遭遇し

GatsbyJSの現在のバージョンで機能する回避策はありますか？

私は試した：
https://github.com/wardpeet/gatsby-plugin-static-site

しかし、それは私にとってはうまくいきません。 私はここで問題を提起しました：
https://github.com/wardpeet/gatsby-plugin-static-site/issues/13

また、リダイレクトの問題を再現するためのサンプルリポジトリを作成しました。
https://github.com/isi-gach/gastby-static/tree/create-react-app

@ isi-gach根本的な問題（あなたが期待していること、あなたが見ていること、あなたが見たいこと）についてのあなたの見解を提供していただけませんか？ このスレッドの私たちの何人かは試しましたが、それを新たに理解するのに役立つかもしれません。

こんにちは@ethagnawl

ブラウザのURLが変更されないことを期待していますが、URLが変更されています。次のビデオでは、URLが/demo/index.htmlから/public/変更されています。
https://www.youtube.com/watch?v=SxYbaDidnkY

そのビデオは、私が作成したサンプルリポジトリを使用して記録されました。
https://github.com/isi-gach/gastby-static/tree/create-react-app

@wardpeet/gatsby-plugin-static-siteを使用してリダイレクトを防止しようとしていますが、機能していないようです。

こんにちは@ isi-gach @ethagnawl 、

あなたが言及している問題を解決するはずの@wardpeetプラグインに開かれているプルリクエストがいくつかあります。

それらがマージされている間、代わりに私のフォークを使用できます

こんにちは@xavivars
フォークからnpmを試しましたが、URLは変更されませんが、白いページが表示されます。
https://www.youtube.com/watch?v=uNzk9UYVCxk

そのビデオは、プラグインによってwardpeetをあなたのものに置き換えた次のサンプルリポジトリを使用して記録されました。
https://github.com/isi-gach/gastby-static/tree/create-react-app

単一ページに対してのみクライアント側ルーティングを無効にするにはどうすればよいですか？

あなたはこれを使うことができます

exports.onPreBootstrap = ({ store }) => {
  const { program } = store.getState()
  const filePath = path.join(program.directory, '.cache', 'production-app.js')

  const code = fs.readFileSync(filePath, {
    encoding: `utf-8`,
  })

  const newCode = code.replace(
    `const { pagePath, location: browserLoc } = window`,
    `const { pagePath } = window
    let { location: browserLoc } = window

    if (window.parent.location !== browserLoc) {
      browserLoc = {
        pathname: pagePath
      }
    }
  `
  )

  fs.writeFileSync(filePath, newCode, `utf-8`)
}

プラグインがカバーするすべてのユースケースをカバーしているかどうかはわかりませんが、私の場合は問題なく動作します。