Gatsby: تعطيل التوجيه من جانب العميل؟

لماذا لا تعرف ما هي المسارات التي يعرضها الخادم؟

ليس الأمر أقل أنني لن أعرف المسارات (يمكنني كتابة تعبير عادي يطابقهم) ولكن أكثر التداخل. الإعداد الفعلي وراء خادم اباتشي يقوم بعكس الوكلاء لمجموعة من التطبيقات المختلفة ، بما في ذلك موقع غاتسبي. في حالة عدم توفر أي من هذه التطبيقات ، أو إرجاع خطأ داخلي في الخادم ، فإننا نعيد صفحة خطأ مخصصة تشكل جزءًا من موقع gatsby.

لذلك في أي وقت ، إذا كان app1 غير متاح أو يعمل بشكل سيء ، فإن أي طلبات إلى / app1 ستعيد محتوى /error/unavailable.html أو /error/internal.html ، وسيكون الأمر نفسه صحيحًا بالنسبة إلى app2 ، وهكذا .

باستخدام matchPath like /^(app1|app2)/.*/ ، في كلتا الصفحتين غير المتوفرتين ، لا تعمل صفحات الخطأ الداخلية لأن findPage لا أعرف (بناءً على عنوان url) الصفحة التي أنويها بالفعل لتظهر للمستخدم.

تمكنت من الحصول على شيء يعمل باستخدام متغير عام و "تصحيح" ___history و ___loader في onClientEntry . إنه هش للغاية بسبب الاعتماد على غاتسبي في فضح تلك الكرة الأرضية - لست متأكدًا مما إذا كانت هناك طريقة ما لتعميم هذا وإضافته إلى غاتسبي.

• سجل التصحيح يمسك المكالمات باستخدام props.location.pathname
  المكون-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 باسم المسار المصحح.

ما زلت لا أفهم لماذا يلقي هذا خطأ؟ يتم تحميل الصفحة بشكل جيد وتعمل. يجب أن يكون هذا تحذيرًا على الأكثر عندما يتعذر عليه مطابقة المسار.

ومع ذلك ، لا أعرف ما إذا كانت هناك طريقة أكثر أناقة لتعديل pages.json من خلال كود config vs runtime.

أريد أن أتطرق إلى هذه المشكلة.

يواجه مشروع أعمل عليه مشكلة مماثلة. نحن نبني منشئ الصفحات المقصودة التي ستنشئ تطبيقات Gatsby من صفحة واحدة. تحدث هذه المشكلة عندما نحاول خدمة صفحة مقصودة خارج نطاقها.

على سبيل المثال ، لدينا تطبيق Gatsby الرئيسي www.example.com . لدينا خدمة تأخذ صفحات Gatsby المقصودة وتخدمها بسعر 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 . إنه هش للغاية بسبب الاعتماد على غاتسبي في فضح تلك الكرة الأرضية - لست متأكدًا مما إذا كانت هناك طريقة ما لتعميم هذا وإضافته إلى غاتسبي.

• سجل التصحيح يمسك المكالمات باستخدام props.location.pathname
  المكون-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 من؟ عندما أحاول تكرار مثالك ، فإن هاتين الخاصيتين للعالميتين هما undfined .

@ alex-greco-harrys يبدو لي أن بادئة المسار هي ما تريد استخدامه في هذا السيناريو.

@ jgierer12 هذا يساعد في حل الجزء الأول من example.com/go/ يمكننا تقديم صفحة واحدة من مجموعة الصفحات. لذلك لن نعرض الصفحة في مسار مثل example.com/go/first-page أو example.com/go/second-page . سيتم تقديم كلاهما في المسار example.com/go/page .

ما أحاول تحقيقه بشكل أساسي هو تقديم صفحة غاتسبي في أي مسار أريده.

@ alex-greco-harrys تم الكشف عن تلك الكرة الأرضية بواسطة gatsby v1. مع الترقية إلى الإصدار 2 ، أعلم أن جهاز التوجيه الأساسي قد تم تبديله من جهاز التوجيه المتفاعل إلى جهاز التوجيه للوصول ، لذلك أعتقد أن تلك الكرة الأرضية قد تأثرت.

آمل أيضًا استخدام Gatsby لإنشاء تطبيق من صفحة واحدة وأود تعطيل التوجيه تمامًا. هل يعرف أي شخص حلًا بديلًا (a

تحديث:
على الرغم من أنني لم أتمكن من العثور على حل من شأنه تعطيل التوجيه من جانب العميل ، إلا أنني تمكنت من منع إعادة التوجيه المشار إليها بواسطة @ alex-greco-harrys وآخرين من خلال إعداد:

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

في gatsby-browser.js التي تقصر هذا الفحص الشرطي في production-app.js. تحاول إعادة التوجيه الشرطي هذه "جعل المسار الأساسي يطابق المسار الفعلي" ويؤدي إلى السلوك غير المتوقع (IMO) المشار إليه أعلاه.

أنا أيضا أحتاج هذا.

أستخدم حاليًا رمزًا تم إنشاؤه بواسطة Gatsby في مشروع آخر وأستخدمه في صفحات متعددة. أنا أستخدم Gatsby لأنه ينشئ رمزًا ثابتًا. لذلك ، استخدمت pathPrefix حتى أتمكن من إنشاء كل شيء تحت مسار محدد وتقديمه. بهذه الطريقة ، يتم طلب كل شيء هناك ثم يتم عرضه على هيئة جزء من الصفحة. ومع ذلك ، أحصل على عمليات إعادة توجيه غير مرغوب فيها طوال الوقت إلى pathPrefix لأنه موجود في البرامج النصية. لا بد لي من إزالة الشرط الذي ذكرته ethagnawl في كل مرة أقوم فيها ببناء. لقد جربت للتو حله ولكنه لم ينجح معي.

آمل أيضًا استخدام Gatsby لإنشاء تطبيق من صفحة واحدة وأود تعطيل التوجيه تمامًا. هل يعرف أي شخص حلًا بديلًا (a

تحديث:
على الرغم من أنني لم أتمكن من العثور على حل من شأنه تعطيل التوجيه من جانب العميل ، إلا أنني تمكنت من منع إعادة التوجيه المشار إليها بواسطة @ alex-greco-harrys وآخرين من خلال إعداد:

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

في gatsby-browser.js التي تقصر هذا الفحص الشرطي في production-app.js. تحاول إعادة التوجيه الشرطي هذه "جعل المسار الأساسي يطابق المسار الفعلي" ويؤدي إلى السلوك غير المتوقع (IMO) المشار إليه أعلاه.

ethagnawl لدي نوع من الحلول

إذا نظرت إلى مثال Gatsby التالي: 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 _ مطلقًا_ مع عنوان URL. من خارج الصندوق ، يدعم Gatsby _ غالبًا_ حالة الاستخدام هذه ويسعد استخدامه كثيرًا ، ولكنه يقدم بعض الافتراضات - مرة أخرى ، بسبب حالة الاستخدام القياسية الثابتة للموقع - والتي تؤدي إلى الحاجة إلى عمليات اختراق مثل تلك المذكورة في الاعلى.

إذن ، هل هناك أي أمل في أن تصبح القدرة على تعطيل التوجيه من جانب العميل خيار تكوين عالي المستوى؟ سأكون سعيدًا بتقديم PR ، لكن لا أريد أن أضيع الوقت فيه إذا لم تكن هناك فرصة لقبوله.

تبدو هذه ميزة معقولة لإضافةethagnawl. أعتقد أنه سيحتاج إلى اسم طويل جدًا وبغيض مثل dangeouslySetInnerHTML بحيث يدرك الأشخاص تمامًا ما يفعلونه لأن هذه حالة خاصة جدًا.

يمكن العثور على أول تصريح مرور لي في العلاقات العامة يعالج هذه المشكلة هنا . سأكون ممتنًا للغاية للتعليقات من المشرفين و / أو المستخدمين الآخرين الذين واجهوا هذه المشكلة.

شكرًا لإنشاء aPRethagnawl

هل يمكنك تذكيرني مرة أخرى لماذا لا يعمل التالي؟

// 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 ، يعد تدوين هذا المفهوم مفيدًا لأنه ، مرة أخرى ، يجعل التوثيق أكثر وضوحًا ويمكن أيضًا استخدام هذا العلم لإجراء تحسينات إضافية عن طريق تجاوز / noop-ing / إلخ. وظيفة غير ذات صلة عند استخدام Gatsby بهذه الطريقة.

بالإضافة إلى ذلك ، يتطلب استخدام matchPath عنوان url في المتصفح ليعكس الصفحة التي تريد عرضها ، ولكن هذا ينهار عندما تقوم بحقن موقع gatsby في مكان غير معروف. (كانت مشكلتي الأصلية تتعلق بوجود 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 إلى gatsby-config.js

اسمحوا لي أن أعرف ما إذا كان هذا مناسبًا لحالة الاستخدام الخاصة بك ، وليس لدي أي نية لدعمه فعليًا ، لذلك يسعدني نقله: ابتسم:

لقد قمت بتحديث الريبو نظرًا لوجود خطأ ما في ملف 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. لذا ، فإن هذا النوع من _ يجعله خارج النطاق فيما يتعلق بهذه القضية و Gatsby ، لكنني قد أجادل في أن هذه القضية يجب أن تظل مفتوحة من أجل مواصلة تلك المحادثة.

wardpeet كانت المشكلة الأصلية تتعلق بتعطيل التوجيه من جانب العميل لمسارات محددة ، أثارethagnawl حالة استخدام تعطيل التوجيه لموقع بأكمله وهو ما أعتقد أنه عناوين المكون الإضافي الخاص بك.

أحتاج إلى تعطيل التوجيه من جانب العميل مؤقتًا أثناء ترحيل موقع على CMS قديم إلى Gatsby. أقوم بذلك صفحة واحدة في كل مرة قبل قلب المفتاح بالكامل إلى 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 ثم يضاعف بادئة المسار.

وبالتالي "/"يصبح" //"بعد أن لا يتطابق الكنسي.

ربما أقوم بتنفيذها بشكل خاطئ. هل استخدمت بادئة المسار لصفحاتك؟ هل من المفترض أن يكون المكون الإضافي للموقع الثابت نشطًا؟

هل استخدمت بادئة المسار لصفحاتك؟

نعم. كنت أستخدم هذا الفرع أيضًا للسماح بالأصول البعيدة. لذا ، من الممكن أن يقدم هذا الفرع السلوك الذي جعل الإصلاح يعمل بالنسبة لي وليس لك.

ومع ذلك ، فمن الأرجح أن إصدارات Gatsby الأخيرة (لم أتابعها) كسرت "الحل" الخاص بي ، لأنه كان اختراقًا في البداية.

ethagnawl سوبر مفيدة! شكرا لك! أعلم أن DSchau قد صنع بعض المكونات الإضافية لاختبار ميزة الأصول. أنا سوف إعطائها بالرصاص!

يبدو أن حل wardpeet لا يعمل عندما تحتاج أيضًا إلى استخدام بادئة المسار. إن وجود حل مثل الحل المقترح __disable_client_side_routing__ والذي قام بتعطيل الفحص الأساسي سيكون رائعًا للغاية. سأكون سعيدًا للعمل عليها وتقديم PR إذا كان سيتم النظر في دمجها. أي دعم لهذه الفكرة ، أم تعتقد أنها لا تنسجم مع خارطة الطريق؟

xavivars أود ذلك

xavivars لقد قمت بتمرير هذه الميزة منذ فترة ، والتي تم إغلاقها لصالح حل wardpeet . إذا كنت ستفكر في إعادة النظر في هذا النهج ، فقد يكون من المفيد إلقاء نظرة على محاولتي.

شكرا ethagnawl ! لقد ألقيت نظرة على نهجك ، وكان هذا إلى حد كبير ما كنت أفكر فيه.

أعتقد أن حل wardpeet يغطي حالة استخدام مختلفة: التطبيق لا يتصرف مثل SPA لأن الروابط في الواقع تغير المتصفح location.href ، لذلك يتنقل بعد ذلك "جانب الخادم". لكنني لم أستطع أن أجعلها تعمل مع حالة الاستخدام الخاصة بي لأن إعادة التوجيه الأولية لا تزال تحدث: فرضيتي الأولية هي أن هناك نوعًا من التفاعل مع prefixPath مما يجعل هذا الشرط للتقييم إلى true

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

هل تمكنت من جعله يعمل بشكل صحيح؟

قد أكون قادرًا على القيام بمزيد من العمل على المكون الإضافي إذا كان بإمكان أي شخص شرح المشكلة الفعلية لي لأنني نسيت ما أحتاج إلى إصلاحه. ربما يمكن حل معظم هذا عن طريق خيار الأصول المدمجة حديثًا؟

آسف لعدم الفهم.

تضمين التغريدة

هل تمكنت من جعله يعمل بشكل صحيح؟

كان كل من الاختراق و PR المقدم _ يعملان بشكل صحيح_ لحالة الاستخدام الخاصة بي: إنشاء صفحة واحدة ثابتة بدون عمليات إعادة توجيه. لقد تخليت عن العلاقات العامة الخاصة بي لأن فريق Gatsby يبدو أنه يفضل مكونًا إضافيًا بدلاً من خيار التكوين على مستوى التطبيق.

لم أتمكن مطلقًا من تجربة البرنامج المساعد wardpeet ، حيث أنني انتهيت بالفعل من مشروع Gatsby الذي كنت أعمل عليه بحلول وقت نشره. لذلك ، لا يمكنني التعليق على ما إذا كان ذلك يعمل بشكل صحيح أم لا.

wardpeet : الأصل لا يصلحها. تمكنت من تشغيله باستخدام كل من المكون الإضافي (لتعطيل "التنقل" من جانب العميل بشكل أساسي عند النقر حوله) والحل البديل الذي ذكره 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 & الأصولPrefix يعمل؟

المشكلة المرتبطة التي جعلت المثال يعمل ، لست متأكدًا مما إذا كان هذا هو ما تحتاجه بالفعل.
https://github.com/wardpeet/gatsby-plugin-static-site/issues/1#issuecomment -494802726

بالنسبة لي ، عملت مع جميع الأشياء الثلاثة: موقع ثابت للمكوِّن الإضافي gatsby + الأصولPrefix + تعطيل "التنقل" كما هو موضح أعلاه

يبدو أنني ما زلت أجد صعوبة في فهم ما هو مطلوب هنا. يمكنني فقط حل المشكلة مع gatsby-plugin-static-site & AssassPrefix.

wardpeet هل لديك رابط لعرض يستخدم gatsby-plugin-static؟

ethagnawl آسف

قمت بعمل عرض توضيحي:
https://github.com/wardpeet/gatsby-demos/tree/static-asset-prefix

الموقع مباشر:
https://zen-wright-33c2d8.netlify.com/

كما هو متوقع ( ومتوقع بواسطة 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 /pack / gatsby / cache-dir / production-app.js # L69

wardpeet : هل ترى أي مشكلة في إدخال متغير التكوين هذا؟

نحن لا نريد تمكين فتحات الهروب هذه في جوهرها. ما أفهمه بشكل أساسي عن المشكلة هو:

لدي موقع gatsby ومسار / مسار خاص بي وعلى خادمي لدي مسار يسمى / شيء آخر. إذا قمت بإعادة كتابة / شيء آخر إلى / gatsby / my-special-path ، فلن يعمل لأنه يحاول تغيير الصفحة إلى / my-special-path؟

إذا كان الأمر كذلك ، فسأرى ما إذا كان بإمكاني إصلاحه في المكون الإضافي الخاص بي. هل لديك عرض حي لهذا؟

نعم ، هذه هي المشكلة بالضبط. سأحاول تجميع علاقات عامة أخرى (لا يضيف ذلك شيئًا غازيًا كمتغير التكوين العام مثل https://github.com/gatsbyjs/gatsby/pull/15173).

لدي شيء قد يكون مقبولاً سأدفعه كعلاقات عامة أخرى في غضون بضع دقائق

wardpeet هذا ما أعتقد أن

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

بعد محادثة مع DSchau في

في الوقت الحالي ، كانت الطرق الوحيدة التي وجدتها هي عبر متغير تكوين عام (# 15173) لتقصير دائرة فحص إعادة التوجيه الكنسي ، أو عن طريق السماح بتعديل عنوان URL الذي تم عرضه لـ gatsby (# 15180) ، لذلك لا يعتمد فحص إعادة التوجيه الكنسي بشكل مباشر على window.location ، ولكن على متغير قابل للتصفية.

IMHO ، يتمثل التحدي في استخدام مكون إضافي لتوسيع / ​​تجاوز شيء لا يبدو أنه قابل للتوسيع / ​​يمكن تجاوزه في الوقت الحالي (الاعتماد المباشر على 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- gachethagnawl ،

هناك بعض طلبات السحب المفتوحة في المكون الإضافي ذكرتها .

أثناء دمجهم ، يمكنك استخدام شوكة بلدي بدلاً من ذلك

مرحبًا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`)
}

لست متأكدًا مما إذا كان يغطي جميع حالات الاستخدام التي يغطيها المكون الإضافي ، لكنه يعمل بشكل جيد في حالتي.