Gatsby: Отключить маршрутизацию на стороне клиента?

Почему вы не знаете, какие пути рендерит сервер?

Дело не в том, что я не буду знать пути (я могу написать регулярное выражение, которое будет им соответствовать), но больше в перекрытии. Фактическая настройка осуществляется за сервером apache, который выполняет обратные прокси-серверы для множества различных приложений, включая сайт gatsby. Если какое-либо из этих приложений становится недоступным или возвращает внутреннюю ошибку сервера, мы возвращаем настраиваемую страницу ошибки, которая является частью сайта 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
  production-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 с исправленным именем пути.

Я до сих пор не понимаю, почему это вызывает ошибку? Страница загружается нормально и работает. В лучшем случае это должно быть предупреждением, когда он не может соответствовать пути.

При этом я не знаю, есть ли более элегантный способ изменения pages.json через конфигурацию и код времени выполнения.

Я хочу затронуть этот вопрос.

В проекте, над которым я работаю, возникает аналогичная проблема. Мы создаем генератор целевых страниц, который будет создавать одностраничные приложения Gatsby. Эта проблема возникает, когда мы пытаемся обслуживать целевую страницу за пределами ее домена.

Так, например, у нас есть основное приложение Gatsby www.example.com . У нас есть служба, которая берет целевые страницы Гэтсби и обслуживает их по www.example.com/trial . Таким образом, URL целевой страницы будет выглядеть как www.example.com/trail/ad-123 . Сначала страница загружается нормально, пока не загрузятся все JS и маршрутизатор не вступит во владение. Целевая страница смотрит на путь и не знает, где он находится, поэтому она пытается изменить путь, чтобы разместить страницу в корне, как это выглядит www.example.com/ad-123 , что приводит к перенаправлению 404.

Есть ли планы добавить настраиваемую опцию, чтобы исправить это? Будет ли команда Гэтсби открыта для пиара?

@ alex-greco-harrys Мне кажется, что в этом сценарии вы захотите использовать префикс пути .

Мне также нужно было отключить маршрутизацию на стороне клиента, чтобы правильно запустить Google AdSense на моем веб-сайте.

Автоматические объявления Google AdSense не определяют маршрутизацию на стороне клиента, и объявления не обновляются при обновлении маршрутов.

Есть ли способ отключить маршрутизацию на стороне клиента?

В таких случаях вы можете использовать теги a вместо gatsby-link

Я смог заставить что-то работать, используя глобальную переменную и «исправляя» ___history и ___loader в onClientEntry . Это очень хрупко из-за зависимости от gatsby, раскрывающей эти глобальные переменные - не уверен, есть ли способ обобщить это и добавить в gatsby.

• История исправлений улавливает звонки с использованием props.location.pathname
  component-renderer.js # L18-L28
• Загрузчик исправлений ловит прямое использование window.location.pathname
  production-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 ? Когда я пытаюсь воспроизвести ваш пример, эти два свойства global равны undfined .

@ alex-greco-harrys Мне кажется, что в этом сценарии вы захотите использовать префикс пути .

@ jgierer12 Это помогает решить первую часть моей проблемы. Вторая часть заключается в том, что конечный путь неизвестен, пока страница не будет отрисована. У нас есть обучающая служба, которая берет набор статических страниц и обслуживает их в зависимости от коэффициента конверсии. Таким образом, по пути example.com/go/ мы можем обслуживать 1 из коллекции страниц. Таким образом, мы не будем обслуживать страницу по пути вроде example.com/go/first-page или example.com/go/second-page . Оба они будут обслуживаться по пути example.com/go/page .

По сути, то, что я пытаюсь достичь, - это обслуживать страницу Гэтсби по тому пути, который я хочу.

@ alex-greco-harrys эти глобальные объекты были обнаружены gatsby v1. С обновлением до версии 2 я знаю, что основной маршрутизатор был переключен с реактивного маршрутизатора на достижимый маршрутизатор, поэтому я предполагаю, что это повлияло на эти глобальные объекты.

Я также надеюсь использовать Gatsby для создания одностраничного приложения и хотел бы полностью отключить маршрутизацию. Кто-нибудь знает обходной путь (а-ля @TuckerWhitehouse ), который был бы совместим с V2?

ОБНОВИТЬ:
Хотя мне не удалось найти решение, которое отключало бы маршрутизацию на стороне клиента, я смог предотвратить перенаправление, на которое ссылается @ alex-greco-harrys и другие, установив:

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

в gatsby-browser.js, который прерывает эту условную проверку в production-app.js. Это условное перенаправление пытается «заставить канонический путь совпадать с фактическим путем» и приводит к (IMO) неожиданному поведению, упомянутому выше.

Мне это тоже нужно.

В настоящее время я использую код, сгенерированный Гэтсби, в другом проекте, и я использую его на нескольких страницах. Я использую Gatsby, поскольку он генерирует статический код. Поэтому я использовал pathPrefix чтобы я мог генерировать все по определенному пути и обслуживать его. Таким образом, все запрашивается здесь, а затем отображается как фрагмент страницы. Однако я все время получаю нежелательные перенаправления на pathPrefix потому что они есть в сценариях. Мне нужно вручную удалить условие, которое @ethagnawl упоминает каждый раз, когда я

Я также надеюсь использовать Gatsby для создания одностраничного приложения и хотел бы полностью отключить маршрутизацию. Кто-нибудь знает обходной путь (а-ля @TuckerWhitehouse ), который был бы совместим с V2?

ОБНОВИТЬ:
Хотя мне не удалось найти решение, которое отключало бы маршрутизацию на стороне клиента, я смог предотвратить перенаправление, на которое ссылается @ alex-greco-harrys и другие, установив:

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

в gatsby-browser.js, который прерывает эту условную проверку в production-app.js. Это условное перенаправление пытается «заставить канонический путь совпадать с фактическим путем» и приводит к (IMO) неожиданному поведению, упомянутому выше.

@ethagnawl У меня есть

Если вы посмотрите на следующий пример Гэтсби: https://github.com/gatsbyjs/gatsby/tree/master/examples/client-only-paths .

Вы можете отредактировать этот файл в строке 15, чтобы он выглядел как <Page path="/*" {...props} /> и удалить строку 16. Когда вы создаете это приложение, любой путь приведет к обслуживанию определенного вами Page . Оттуда вы можете сделать из этого Page все, что захотите. Теперь, если вам нужно разместить эту страницу по произвольному пути, вы не увидите перенаправления.

Мне не удалось понять, как это решение может работать с несколькими страницами в приложении. Целью моего проекта было обслуживание одной страницы Gatsby (маркетинговой целевой страницы) по любому URL-адресу, который я хочу.

Не уверен, поможет ли это в вашем случае, но, возможно, это может послужить толчком для будущих открытий!

Я смог добиться этого, выполнив инструкции по настройке html.js в документации и удалив {this.props.postBodyComponents}

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

Судя по тому, насколько активна эта ветка, кажется, есть нетривиальное количество пользователей, желающих такого поведения.

Чтобы быстро повторить мой вариант использования: я хочу ( действительно! ) Использовать Gatsby в качестве генератора статических _page_ - в отличие от генератора статических _site_ - и потому что «страница» Gatsby вводится в содержащую страницу, URL-адрес которой находится вне мой контроль и может быть изменен, я не хочу, чтобы приложение Gatsby _ever_ сбрасывало URL. По умолчанию Gatsby _ в основном_ поддерживает этот вариант использования, и его очень приятно использовать, но он делает некоторые предположения - опять же, из-за своего стандартного статического варианта использования _site_, которые приводят к необходимости во взломах, подобных упомянутым выше.

Итак, есть ли надежда на то, что возможность отключить маршрутизацию на стороне клиента станет параметром конфигурации верхнего уровня? Я был бы рад отправить PR, но не хочу тратить на это время, если нет шансов, что он будет принят.

Кажется разумным добавить @ethagnawl. Я думаю, ему понадобится очень длинное и неприятное имя, например dangeouslySetInnerHTML, чтобы люди полностью осознавали, что они делают, поскольку это особый крайний случай.

Мой первый проход в PR по этой проблеме можно найти здесь . Буду очень признателен за отзывы от сопровождающих и / или других пользователей, столкнувшихся с этой проблемой.

Спасибо за создание PR @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, которое больше не работает).

ИМО, кодификация этой концепции имеет смысл, поскольку, опять же, она упрощает документацию, и этот флаг также можно использовать для дополнительной оптимизации путем обхода / noop-ing / etc. функциональность, которая не актуальна, когда Гэтсби используется таким образом.

Кроме того, использование 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-plugin-static-site в ваш gatsby-config.js

Дайте мне знать, подходит ли это для вашего варианта использования, у меня нет намерения поддерживать его, поэтому я рад передать его: smile:

Я обновил репо, так как у меня что-то не так в моем файле gitignore (спасибо @ m-allanson). Я также опубликовал его в npm под своим именем.

так что установка может быть выполнена

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

и добавьте @wardpeet/gatsby-plugin-static-site в gatsby-config.json

Если это выглядит хорошо, я могу добавить несколько тестов и несколько параметров, чтобы отключить это поведение для разработки.

Привет!

Этот вопрос утих. Жуткая тишина. 👻

У нас много проблем, поэтому в настоящее время мы закрываем их после 30 дней бездействия. Прошло не менее 20 дней с момента последнего обновления здесь.

Если мы пропустили эту проблему или вы хотите оставить ее открытой, ответьте здесь. Вы также можете добавить ярлык «не устаревший», чтобы эта проблема оставалась открытой!

Спасибо, что стали частью сообщества Гэтсби! 💪💜

Я бы хотел, чтобы он оставался открытым, поскольку, похоже, он ожидает рассмотрения

Я не уверен, что он не устарел, я исправил и надеюсь получить отзывы об этом
https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -470075540

Если никто не ответит, я думаю, что это хорошая идея, так как это, вероятно, решено.

@wardpeet можно ли с помощью этого плагина условно отключить маршрутизацию на стороне клиента?

@wardpeet IIRC, предлагаемое вами исправление - это первый шаг в процессе (возможно, со временем) добавления этой функции в качестве параметра конфигурации Gatsby. Таким образом, это _ в некотором роде_ выходит за рамки того, что касается этой проблемы и Гэтсби, но я могу возразить, что этот вопрос должен оставаться открытым, чтобы продолжить этот разговор.

@wardpeet исходная проблема заключалась в отключении маршрутизации на стороне клиента для определенных маршрутов , @ethagnawl поднял

Мне нужно временно отключить маршрутизацию на стороне клиента, пока я переношу сайт со старой CMS на Gatsby. Я делаю это по одной странице за раз, прежде чем полностью переключить переключатель на просто Гэтсби.

Я пробовал плагин @wardpeet, но, похоже, он не работает.

@brianbento у вас есть репродукция? если вы можете создать проблему в репо https://github.com/wardpeet/gatsby-plugin-static-site, я могу посмотреть, чего не хватает

@wardpeet Я посмотрю, смогу ли я что-нибудь придумать. Основная проблема заключается в том, что ваше ранее упомянутое «исправление» (https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment-465497418) не работает при использовании pathPrefix. Он всегда «корректирует» адрес в соответствии с ожидаемым.

@brianbento Вы пробовали решение, о котором я упоминал выше ? Это хорошо сработало для меня в двух разных проектах.

@ethagnawl Я все еще получаю исправление URL, а затем префикс пути удваивается.

Так "/"становится" //"после канонического не соответствует.

Может я неправильно реализую. Вы использовали префикс пути для своих страниц? Должен ли я активировать плагин статического сайта?

Вы использовали префикс пути для своих страниц?

Да. Я также использовал эту ветку для удаленных ресурсов. Итак, _ возможно_, что эта ветка ввела поведение, благодаря которому исправление работало на меня, а не на вас.

Однако более вероятно, что недавние выпуски Гэтсби (я не следил за ними) сломали мое «решение», поскольку это был взлом с самого начала.

@ethagnawl Очень полезно! Спасибо! Я знаю, что @DSchau сделал несколько плагинов для тестирования функции assetPrefix. Я попробую!

Кажется, что решение __disable_client_side_routing__ которое отключило каноническую проверку. Я был бы счастлив поработать над ним и отправить PR, если он будет рассмотрен для слияния. Есть ли поддержка этой идеи, или вы думаете, что она не вписывается в дорожную карту?

@xavivars Я бы хотел этого и, конечно, считаю полезным.

@xavivars Некоторое время назад я воспользовался этой функцией , которая была закрыта в пользу решения @wardpeet . Если вы собираетесь рассмотреть возможность пересмотра этого подхода, возможно, стоит взглянуть на мою попытку.

Спасибо @ethagnawl ! Я взглянул на ваш подход, и это было примерно то, о чем я думал.

Я думаю, что решение location.href , поэтому оно перемещается "на стороне сервера". Но я не мог заставить его работать для моего варианта использования, потому что первоначальное перенаправление все еще происходит: моя первоначальная гипотеза заключается в том, что существует какое-то взаимодействие с prefixPath которое заставляет это условие оцениваться как true

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

Удалось ли заставить его работать нормально?

Возможно, я смогу поработать над плагином, если кто-нибудь объяснит мне настоящую проблему, поскольку я как бы забыл, что мне нужно исправить. Может быть, большую часть этой проблемы можно решить с помощью недавно объединенной опции assetPrefix?

Извините за непонимание.

@xavivars

Удалось ли заставить его работать нормально?

И мой взлом, и представленный PR работали должным образом для моего варианта использования: генерация одной статической страницы без перенаправления. Я отказался от своего PR, потому что команда Gatsby, похоже, предпочла плагин, а не вариант конфигурации на уровне приложения.

Я так и не дошел до того, чтобы попробовать плагин @wardpeet , так как к моменту его публикации я уже завершил проект Gatsby, над которым работал. Итак, я не могу комментировать, было ли это когда-либо _работало должным образом_.

@wardpeet : assetPrefix это не исправляет. Мне удалось заставить его работать, используя как ваш плагин (в основном, чтобы отключить "навигацию" на стороне клиента при нажатии), так и обходной путь, упомянутый @ethagnawl несколько месяцев назад

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

Этот обходной путь необходим для отключения события «навигация», которое происходит onClientEntry . Мы исправили добавление перехвата и применение этого обходного пути (принуждение page.path к фактическому пути). Но я понятия не имею, есть ли у этого какие-либо побочные эффекты, а также сколько времени пройдет, пока он перестанет работать (это не более чем взлом).

В идеале, я думаю, это должна быть конфигурация уровня приложения, учитывая количество людей, которые, кажется, используют gatsby в качестве «генератора статических страниц».

@xavivars У вас есть ссылка, которой вы можете поделиться с вами?

Не совсем, но вот и все:

Добавьте упомянутый ранее статический плагин и в файл gastby-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 + отключение "навигации", как показано выше.

Похоже, мне все еще трудно понять, что здесь нужно. Я мог бы просто исправить проблему с помощью 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://github.com/gatsbyjs/ gatsby / blob / master / packages / gatsby / cache-dir / production-app.js # L69

@wardpeet : видите ли вы какие-нибудь проблемы с введением такой переменной конфигурации?

Мы скорее не хотим включать эти аварийные люки в ядре. Что я в основном понимаю в этой проблеме, так это:

У меня есть сайт gatsby и путь / my-special-path, а на моем сервере есть маршрут под названием / something-else. Если я перепишу / что-нибудь еще в / gatsby / my-special-path, это не сработает, потому что он пытается изменить страницу на / my-special-path?

Если да, я посмотрю, смогу ли я исправить это в своем плагине. Может быть, у вас есть живая демонстрация этого?

Да, именно в этом и проблема. Я попытаюсь составить еще один PR (который не добавляет чего-то агрессивного в качестве глобальной переменной конфигурации, такой как https://github.com/gatsbyjs/gatsby/pull/15173).

У меня есть кое-что, что может быть приемлемо, и я буду использовать его в качестве еще одного пиара через несколько минут

@wardpeet, это то, что, я думаю, нужно добавить в Gatsby, чтобы ваш плагин можно было расширить. Я добавил несколько примеров и документацию по PR

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

После разговора с @DSchau в Discord кажется, что основные участники согласны с тем, что решение вроде # 15173 или # 15180 должно находиться не в ядре, а в плагине. Поэтому я хотел бы изучить другие варианты решения этой проблемы.

В настоящее время я нашел только один способ: с помощью глобальной переменной конфигурации (# 15173) сократить каноническую проверку перенаправления или разрешить изменить воспринимаемый отображаемый URL-адрес для gatsby (# 15180), поэтому проверка канонического перенаправления напрямую не зависит от 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/

Я только что опубликовал версию 0.1.0 @ wardpeet / gatsby-plugin-static-site. Это должно решить эту проблему. Не стесняйтесь открывать снова, если это не устранило все ваши проблемы.

Лучший способ улучшить поддержку статического сайта - создать проблему в самом плагине. 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`)
}

Я не уверен, что он охватывает все варианты использования, которые охватывает плагин, но в моем случае он отлично работает.