Knaackee هل جربت الاحتمال؟ أنا أتساءل أيضًا عما إذا كان شخص ما قد حصل عليه للعمل مع أي إصدار من RR؟

التالي لديه جهاز التوجيه الخاص به ، لماذا استخدام RR؟

sergiodxa وزن الخيارات عندما أقوم

oyeanuj 🤔 يمكنك الانتقال تدريجيًا إلى التالي ، ما عليك سوى تعيين Next.js للتعامل مع مسار واحد واستخدام وكيل للحصول على كل من تطبيقك الحالي وتطبيق Next.js ، ثم نقل مسار ثانٍ من RR إلى Next.js ، وذلك بالطريقة التي يمكنك من خلالها الاحتفاظ بتطبيقك الحالي أثناء الترحيل ، سيكون لديك في النهاية كل شيء في Next.js

من خلال النظر إلى الأمثلة ، يبدو أن الجدول التالي يحتوي على جدول توجيه واحد مثل RRv2-3 ولا يدعم "المسارات المتداخلة" مثل RRv4. هذه جميلة.

سأحاول استخدام RR أم أن هناك تحذيرًا كبيرًا لا أعرف عنه؟

igl هل

يعد النموذج الجديد لجهاز التوجيه التفاعلي 4 للطرق المتداخلة مغيرًا للعبة ، وهو أمر لا بد منه في مشروعنا الحالي. أتساءل ما إذا كان أي شخص قد نجح في الحصول على rr4 للعمل مع next.js؟

MemoryRouter يعمل ، إن لم يكن على النحو المنشود ...
بخلاف ذلك ، يمكن أن تكون المكونات الديناميكية من جانب العميل فقط ، حيث يعمل HashRouter بشكل جيد ...

const AdminPage = dynamic(
  import('..../AdminPage'),
  { ssr: false }
);

أنا أتبع أيضًا نهج react-router وكل المحتوى الذي يقدمه الخادم باستخدام جهاز التوجيه next .

malixsyspegiadise ، هل يمكنك من فضلك إعطاء المزيد من التفاصيل حول كيفية استخدام جهاز التوجيه التالي والموجه الموجه معًا؟

يمكنك تعيين علامة في componentDidMount وتقديم <Router /> بشكل مشروط عندما تكون العلامة صحيحة. ( componentDidMount لا يعمل على الخادم 😉)

في الواقع ، سنقوم بدمج React Router داخل Next.js قريبًا :)
- https://twitter.com/rauchg/status/948318111828099072

هل هذا مازال يحدث؟ يمكنني رؤية ملاحظات إصدار V6 canary ولا يوجد ذكر لها.

في النهاية. إنه بالتأكيد في أذهاننا. لدينا أولويات أخرى في الوقت الحالي (مكون التخطيط والتطوير الموثوق به وعدد قليل من المشكلات المفتوحة الأخرى التي طال أمدها).

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

timneutkens ستساعد إضافة تكامل جهاز التوجيه التفاعلي في زيادة اعتماد nextjs وتحسين التطوير. يرغب المطورون مثلي في رؤية هذا يحدث ، يرجى التفكير في زيادة الأولوية.

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

نفسه.

هل يمكننا على الأقل إعادة فتح هذه المشكلة حتى يمكن تعقبها؟

سأعيد فتح هذا ، لكن لاحظ أن هذا مشروع مفتوح المصدر وليس لدينا حجة قوية جدًا له في هذه اللحظة لـ zeit.co ، نظرًا لأننا نستخدم Next.js لكل شيء.

لهذا كنت أقول إنه جزء من الأهداف طويلة المدى ولا يمكن تنفيذه على الفور ، لكننا نعمل على تحقيقه.

الميزات التي قدمتها في Next 6 تعمل بالفعل على دعم React Router.

كانت لدينا أولويات أخرى لـ Next 6 ، والتي تعمل على تحسين موثوقية Next.js وقابلية التوسع بشكل كبير ، على سبيل المثال حل أسرع للصفحة 100x ، ومكون التطبيق ، وتنفيذ أعمال التصدير التالية في التطوير ، بابل 7 ، إلخ.

آمل أن يوضح هذا تعليقي السابق.

إذن TLDR هو:

• سنقوم بذلك ، لكن ليس على الفور
• يحتوي Next 6 على العديد من التحسينات لأجزاء مختلفة من Next.js

لتوسيع تعليق timneutkens : نريد بالتأكيد RR ، لكن ليس لدينا أي قيود ملحة في جهاز التوجيه الحالي تجعله أولوية. تم تنفيذ جميع حالات استخدام التوجيه التي يمكنك تخيلها بنجاح باستخدام واجهة برمجة تطبيقات Next.js الحالية

هناك سببان لأننا نريد حقًا دعم React Router من أجل:

• قم بتبسيط قاعدة أكواد Next.js الخاصة بنا ، دون الحاجة إلى صيانة جهاز التوجيه الخاص بنا ، وجعل الأشياء أصغر حجمًا ووحدات معيارية
• تبسيط مسار الترحيل للتطبيقات الكبيرة التي تستخدم بالفعل RR

على هذا النحو ، أوافق على أننا يجب أن نبقي هذه القضية مفتوحة!

كنقطة مقابلة ، يعني عدم وجود جهاز توجيه رد فعل أن التالي يعمل بشكل جيد مع Relay-modern وكان أحد الأسباب التي جعلنا ننتقل إلى التالي من تطبيق جهاز التوجيه القديم الخاص بنا.

merrywhether لقد عملت على تطبيق RRv4 مع Relay-modern العام الماضي. يهمني أن تكون أكثر تحديدا؟
لا أتذكر أننا نواجه مشكلات خطيرة بسبب أي منهما.

igl هذا وفقًا لوثائق الترحيل: https://facebook.github.io/relay/docs/en/routing.html#react -router-https-reactiontrainingcom-reaction-router

تكمن المشكلة في أن نهج المكون الخاص بـ RRv4 لا يسمح بالحتمية أثناء خطوة ما قبل التجميع ، مما قد يؤدي إلى حدوث شلالات للطلب في العميل.

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

dbbk تحقق من تطبيق مثال الجرام التالي (https://github.com/now-examples/nextgram) ، فهو يفعل ذلك بالضبط

في الخطوة الخامسة التالية ، ننجز "الترميز الخارجي" من خلال وجود مكونات تخطيط ذات مستوى أعلى تمتد جميع صفحاتنا: التخطيط الأساسي به تنقل علوي ، ثم بعض التخطيطات الفرعية التي توسع قاعدة القوائم / التفاصيل / إلخ ، ثم تعمل مكونات صفحاتنا على توسيع هذه التنسيقات الفرعية بمحتواها المحدد. في 6 التالية ، يمكنك أيضًا إنجاز "العلامات الخارجية" الأساسية باستخدام _app.js ما أعتقد.

هل سيكون الإصدار التالي قابلاً للتكوين لاختيار حل توجيه ليس React Router؟

مرحبًا ، أحتاج فقط إلى جهاز التوجيه من أجل تمرير الدعائم إلى الصفحات (باستخدام <Route render ={} /> بدلاً من <Route component ={} /> ) ، هل يمكنني فعل ذلك مع Next؟

راجع https://github.com/zachrbrown/next-react-router. هناك عدد قليل من أجهزة الصراف الآلي للمستندات ، ولكن هناك شرح موجز في https://github.com/zachrbrown/next-react-router/blob/master/src/IsomorphicRouter.js

من خلال النظر إلى الأمثلة ، يبدو أن الجدول التالي يحتوي على جدول توجيه واحد مثل RRv2-3 ولا يدعم "المسارات المتداخلة" مثل RRv4. هذه جميلة.

مرحبا،

هل هذا يعني أنني يجب أن أقوم بإنشاء صفحة واحدة لطريق واحد؟

لنفترض أنه إذا كان لدي مساران sign up ، log in . سيكون لدي صفحة واحدة تشترك في نفس التخطيط ، والفرق الوحيد هو مساحة النماذج. هذا هو أنني أريد فقط إنشاء ملف واحد في مجلد pages . ولكن مع المسارات التالية ، يجب أن أقوم بإنشاء ملفين في المجلد pages . فعلا؟

إذا كان الأمر كذلك ، فسيتم إعادة تخطيط التنسيق مع كل تنقل ، وليس فقط منطقة النماذج ، أليس كذلك؟

https://github.com/zeit/next.js/issues/75

@ 7c78 شيء واحد يمكنك القيام به هو الاستفادة من _app.js لتخطيط الصفحة الدائم لجميع الصفحات. الشيء الآخر الذي يجب القيام به هو إنشاء مكونات تخطيط مشتركة يمكنك إعادة استخدامها عبر الصفحات المختلفة لتحقيق ما تبحث عنه:

// pages/login.js

class LoginPage extends React.Component {
  render() {
    return (
      <AuthForm>    // same component can be reused in signup
        <form>
          ...implementation of login
        </form>
      </AuthForm>
    );
  }
}

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

//layouts/baseAuth.js

class BaseAuth extends React.Component {
  abstract formContent();  // we use typescript, but you can have the same concepts
  abstract formSubmit():

  render() {
    return (
      <SomeStyledDiv>
        <form>
          {this.formContent()}
          {this.formSubmit()}
        </form>
      </SomeStyledDiv>
    );
  }
}

ثم تقوم فقط بتوسيع BaseAuth في صفحات تسجيل الدخول والتسجيل الخاصة بك وتحديد formContent و formSubmit في كل منها (هذه أمثلة على لعبة ، لأنني لا أعرف متطلباتك الدقيقة).

تضمين التغريدة
أنا أستخدم منهجك حاليًا ، والأمثلة التالية تستخدمه أيضًا.

لكن ما يشغلني هو أنني بحاجة إلى إنشاء صفحات منفصلة لنماذج منفصلة. هذا هو التصميم المعاد استخدامه ولكن ليس الصفحة. ويتم إعادة تصميم التخطيط مع كل تنقل.

مع RRv4 ، لدينا صفحة واحدة ويتم تقديم / إعادة تحميل النماذج بناءً على المسارات (وليس الصفحة بأكملها). الطرق هي مجرد مكونات.

شكرا للاستجابة السريعة!

@ 7c78 هذا صحيح فيما يتعلق بإعادة التركيب ، على الرغم من أنني أعتقد أن عُقد DOM يُعاد استخدامها لأن vDOM يحل إلى نفس الحالة.

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

merrywhether لست متأكدًا من vDOM لأن الخادم يقوم بإرجاع مستند / html جديد لكل المسارات. آسف ، تجاهل هذا الافتراض ، أنا مجرد مبتدئ.

أوافق على أنه يتعين علينا استخدام هذا النمط على أي حال. شكر!

يمكنك استخدام RR مع next.js من خلال جعل تطبيقك بالكامل موجودًا في الصفحات / index.js ولكنك تفقد بعض الأشياء الجيدة التالية مثل تقسيم الكود خارج الصندوق ويجب عليك إعداد ذلك بنفسك.

سأحب لو تم التفكير في Reach Router. إنه مشابه جدًا لجهاز التوجيه التفاعلي ويقدم بعض الفوائد المهمة:

• إنه يحل بعض مخاوف a11y المهمة المتعلقة بإنشاء الارتباط وإدارة التركيز (https://reach.tech/router/accessibility).
• يزن أقل (وقت كتابة هذا التقرير)
  
  
  
  • @ access / رابط )
  
  
  • رد فعل[email protected] : 44.1 كيلو بايت / 10.4 كيلو بايت ( رابط )
  
  

Reach Router رائع أيضًا 🥇

تعد المسارات الديناميكية بأسلوب RR واجهة برمجة تطبيقات جيدة ، ولكن التوجيه الثابت (والقابل للتحليل الثابت) يجلب الكثير من الفوائد أيضًا. لا يعتبر أي من النهجين فائزًا من البطولات الاربع.

sorokinvj هذا مدعوم فقط عبر مكون إضافي (حاليًا) .. https://github.com/fridays/next-routes

الروابط الثابتة أساسية جدًا لدرجة أنها لا تدعم حتى المعلمات في الروابط ...

أنا أستخدم الطرق التالية لحزمة طرف ثالث في الوقت الحالي https://github.com/fridays/next-routes للتغلب عليها

مرسل من الايفون الخاص بي

في 24 أكتوبر 2018 ، الساعة 23:01 ، كتب Andy Ingram [email protected] :

تعد المسارات الديناميكية بأسلوب RR واجهة برمجة تطبيقات جيدة ، ولكن التوجيه الثابت (والقابل للتحليل الثابت) يجلب الكثير من الفوائد أيضًا. لا يعتبر أي من النهجين فائزًا من البطولات الاربع.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

نحن نستخدم next-routes أيضًا في الوقت الحالي ، لكنني أعتقد أن الفريق التالي يعمل على إضافة معلمات المسار إلى توجيه نظام الملفات عبر أسماء ملفات regex (مستوحاة من Sapper).

merrywhether أنا أستخدم next-routes أيضًا ولكني أفضل أن يكون هذا جزءًا من Next.js core.

ذكرتم

أعتقد أن الفريق التالي يعمل على إضافة معلمات المسار ...

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

curran كان المصدر عبارة عن تغريدة من on of the sapper.js devs ، قائلًا إن الخطوة التالية كانت مستوحاة من sapper.js وتنفيذ regex-filename-routing في إصدار مستقبلي. بالطبع ، نظرًا لكون Twitter على ما هو عليه ، لم أستطع العثور على التغريدة الأصلية طوال حياتي.

أثيرت هذه المشكلة في 5 أبريل 2017 وهي الآن 27 فبراير 2019. ما يقرب من عامين ولا يوجد حل
هل حان الوقت لاستبدال جهاز التوجيه المدمج نصف المؤخر بشيء جيد؟

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

فاتني ReactRouter في البداية. الآن لا أتذكر حتى أن NextJS لديه موجه مختلف حتى يذكرني أحدهم. Verbose Link API سهل الالتفاف مع الوكلاء (اعتمادًا على البيانات / بنية واجهة برمجة التطبيقات) ، على سبيل المثال. مشاركة هذا السر: 😆

import _Link from "next/link"
export function Link({as, children, href}) {
  as = as || QS.parse(U.parse(href).query || "").url || null // QS, U are parsing libs
  return <_Link as={as} href={href}>
    {children}
  </_Link>
}

<Link as="/about" href="/page?url=/about"/> verbose
→
<Link href="/page?url=/about"/> ok

أعتقد أننا جميعًا يجب أن نقضي وقتًا أقل في الشكوى من الأشياء الثانوية 😉

@ ivan-kleshnin نيس أضفت غلافًا مشابهًا

حسب التعليق السابق أود أن أشير إلى https://www.contributor-currency.org/version/1/4/code-of-conduct

لقد أخفيت قال التعليق.

ليس لدي مشكلة مع next/router لمعظم حالات الاستخدام.
ولكن يجب أن يتحسن قليلاً في الجزء universal routing .
في حالة نشر Now 2 ، أرغب فقط في استخدام now.json واستخدامه للتوجيه في طلبي.

إذا كنت ترغب في تنفيذ RR4 في مشروع nextJs ، فأنت بحاجة إلى القيام بأمرين:

1. منع NextJS SSR ، باستخدام next/dynamic يمكنك فعل ذلك.
2. باستخدام HashRouter بدلاً من BrowserRouter -> إذا أعاد المستخدم تحميل الصفحة ، يمكن للمتصفح تحميل الصفحة السابقة (وليس صفحة 404)

إذا كنت ترغب في تنفيذ RR4 في مشروع nextJs ، فأنت بحاجة إلى القيام بأمرين:

1. منع NextJS SSR ، باستخدام next/dynamic يمكنك فعل ذلك.
2. باستخدام HashRouter بدلاً من BrowserRouter -> إذا أعاد المستخدم تحميل الصفحة ، يمكن للمتصفح تحميل الصفحة السابقة (وليس صفحة 404)

شكرا على هذا الرد ساعدني كثيرا

يتم دمج @ access / router وجهاز التوجيه 5: https://reacttraining.com/blog/reach-react-router-future/

كيف يؤثر هذا على next.js؟

@ alp82 نظرًا لأن Next.js لا يزال لا يستخدم React Router أو Reach Router ، فلن يؤثر على Next.js على الإطلاق.

أحتاج إلى تبديل وظيفة المسارات في nextjs لعرض مكونات صفحات متعددة في صفحات الفهرس.
فكيف يمكنني تنفيذ هذا في nextjs ....... ؟؟؟

إذا كنت ترغب في تنفيذ RR4 في مشروع nextJs ، فأنت بحاجة إلى القيام بأمرين:

1. منع NextJS SSR ، باستخدام next/dynamic يمكنك فعل ذلك.
2. باستخدام HashRouter بدلاً من BrowserRouter -> إذا أعاد المستخدم تحميل الصفحة ، يمكن للمتصفح تحميل الصفحة السابقة (وليس صفحة 404)

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

server.get ('your params'، (req، res) => {
const الفعلية الصفحة = '/ your_page'
const queryParams = {id: req.params.id}
app.render (مطلوب ، الدقة ، الصفحة الفعلية ، الاستعلام بارامز)
})

لقد قمت بتوثيق طريقة لاستخدام next.js مع react-router ، وتوفير ملف نقطة إدخال واحد بدلاً من التوجيه المستند إلى نظام الملفات الأصلي والحفاظ بشكل كامل SSR الأصلية .

سأكون سعيدًا لتلقي التعليقات وتحسين ما فعلته.

الوثائق متاحة على النحو التالي:

• مستودع جيثب
• ديف للنشر

في صحتك!

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

timneutkens ربما أكون مخطئا. ولكن مع التحميل البطيء ، يكون تكوين التوجيه مجرد ملف تكوين واحد. لا أرى أنه سيؤثر على قابلية التوسع أو الأداء هنا. أود معرفة المزيد عن هذا.
ميزة جهاز التوجيه التفاعلي هي أن المطورين لديهم سيطرة كاملة على الكود.

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

timneutkens أما بالنسبة للنقاط التي ذكرتها فهي مسألة مقايضات. إن عملي هو تجربة لمعرفة كيفية استخدام Next.js مع إعداد مختلف.

الكثير من التعليمات البرمجية من جانب العميل

يمكن لأي حزمة حديثة تقسيم أصول العميل إلى أجزاء و react-router المسارات هي في الواقع نقاط تقسيم مريحة للغاية.

أوقات بناء أعلى للتطوير

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

لا توجد صادرات ثابتة

أوافق على أن الصادرات الثابتة هي طبقة تحسين مهمة. يتعين على معظم الصفحات التي يخدمها تطبيق Next.js المتوسط ​​استرداد البيانات الديناميكية على أي حال ولا يمكنها الاستفادة من عمليات التصدير الثابتة.

لا يوجد نقص في حل هذا القلق. على سبيل المثال. قد يظل من الممكن التصريح يدويًا عن قائمة المسارات التي سيتم تصديرها بشكل ثابت

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

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

لا يمكنك تسريع بدء تشغيل dev-time بناءً على النهج الذي تتبعه ، ولا يوجد ضبط دقيق محدد لتكوين webpack حيث ستقوم حزمة الويب بتجميع ومشاهدة كل مسار تقوم باستيراده مما يؤدي إلى إبطاء عمليات التحرير على المكونات الشائعة بشكل كبير. لهذا السبب يحتوي Next.js على إدخالات عند الطلب: https://nextjs.org/blog/next-8#improved -on-request-Entries

علاوة على ذلك ، هناك (تلقائي) جلب مسبق للطرق وما إلى ذلك. هناك الكثير من التفاصيل التي يمكنني الخوض فيها هنا ، ولكن tldr هو أنك ستنتهي بتجربة تطبيق وتطبيق أسوأ.

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

ياtimneutkens
هل تحسب بعض المحترفين الذين يجلبهم التحليل الثابت إلى الطاولة وغير ممكنين مع حلول التوجيه الديناميكية؟

شيء مثل هذا https://github.com/jaredpalmer/after.js ؟

لقد قرأت جميع التعليقات وما زلت غير واضح ما إذا كان سيتم تضمين RR4 + أم اختياريًا في التكرار المستقبلي لـ next.js. هل خريطة طريق جهاز التوجيه أم شيء مشابه؟

laurencefass يبدو أنه لا توجد خطة لدعم react-router (اعتبارًا من اليوم).

بالنسبة لي ، أصبح نظام التوجيه في Next.js ناضجًا بدرجة كافية ، لذا ربما لا نحتاج إليه (بعد الآن) على أي حال :)

"بالنسبة لي ، أصبح نظام التوجيه في Next.js ناضجًا بدرجة كافية ، لذا ربما لا نحتاج إليه (بعد الآن) على أي حال :)"

باستثناء أولئك الذين يسعون إلى اعتماد Next.js بشكل تدريجي في قاعدة بيانات موجودة. أعتقد أن المناقشة الأكثر فائدة ربما لا تكون "توجيه Next.js مقابل توجيه جهاز التوجيه التفاعلي". أعتقد أن المناقشة الأكثر فائدة هي "كيف يمكنني ترحيل تطبيق ضخم باستخدام جهاز التوجيه التفاعلي إلى Next.js ، بشكل متزايد؟"

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

dbbk https://github.com/jaredpalmer/after.js

dbbk سمعت أن فريق nextjs يعمل على ذلك.

js التالي مرن جدًا مع أجهزة التوجيه. https://dev.to/toomuchdesign/next-js-react-router-2kl8

أقوم بنقل موقع ويب من أكواد JS و jQuery العادية إلى React. على عكس الرموز القديمة ، أحتاج إلى منع الموسيقى من التوقف عند تغيير الصفحة ، لذلك استخدمت React Router لذلك.

الآن لغرض تحسين محركات البحث ، نظرًا لأن لدي بعض الزيارات الجيدة من بحث Google ، أحتاج إلى الحفاظ على ذلك. لذلك أفضل SSR مع Next.js لأداء أفضل.

هل Next.js قادر على عرض صفحة على جانب الخادم وبعد ذلك بمجرد تحميل الصفحة في جانب العميل ، سيسمح Next.js بالتنقل تحت التحكم في React Router ، بحيث إذا كان المستخدم يستمع إلى الموسيقى ، فإن رابط Next.js سيفوز ' ر مضطر لمغادرة الصفحة الحالية لإيقاف الموسيقى؟

O هل يمكن لـ Next.js أن يجعل التوجيه من جانب العميل فقط؟

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

js التالي مرن جدًا مع أجهزة التوجيه. https://dev.to/toomuchdesign/next-js-react-router-2kl8

@ laurencefass ، هذا أسلوب جيد جدًا ، لقد قرأته من قبل. وتقول المقالة إن فريق Next.js لا يوصي بذلك ، ولا أعرف السبب. لكنها تبدو جيدة بالنسبة لي

KeitelDOG ، لست بحاجة إلى جهاز توجيه رد فعل لذلك ، فإن توجيه Next.js سيوفر لك نفس الفوائد ، بالإضافة إلى أن تطبيقك سيكون أخف بفضل تقسيم الكود التلقائي (الذي لن تحصل عليه بسهولة مع جهاز التوجيه التفاعلي)

_edit: سأضيف هذا فقط: ربما تكون الميزة الوحيدة لجهاز التوجيه التفاعلي هي المسارات المتداخلة السهلة في نفس ميزة العرض ، يجب أن يحل جهاز التوجيه Next.js 95٪ من حالات الاستخدام الخاصة بك_

martpie شكرًا على الرد ، هذا ما رأيته ليلة أمس مع المكون Link . ثم Next.js هو مزيج الخادم والعميل الذي أردته.

وبالنسبة للمكون الذي يتحكم بشكل محبب في المسارات المتداخلة الخاصة به ديناميكيًا ، فقد أعجبني حقًا باستخدام جهاز React Router. لكنني متأكد تمامًا من أنه يمكنني الحصول على حل ، لأنني لا أقوم بتغيير موقع React إلى Next.js ، ولكن بدلاً من ذلك أخطط واختبار لتغيير موقع JS - jQuery إلى تطبيق React متعدد الصفحات دون فقدان مزايا تحسين محركات البحث الخاصة بي على جوجل. لذلك أعتقد أنني يجب أن أختار Next.js

timneutkens أي خطط لدعم هذا في Next.js 10؟

TrejGun شكرا ، هذا بالتأكيد ليس خارج الموضوع.

هل لديك أي خطة؟
next/router رائع ، إنه يوفر الكثير من المساعدة. لكننا نحتاج إلى موجه أكثر احترافًا للتعامل مع التطبيقات المعقدة. React-router هو رائد في جهاز التوجيه.
ربما يمكن الرجوع إلى after.js .

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

React-router على وشك إطلاق الإصدار v6 ، والذي سيكون أفضل جهاز توجيه حتى الآن. إنني أتطلع إلى دعمه بـ next.js .

أفضل طريقة هي فصل next.js و router ، مما يسمح للأشخاص باختيار router المفضل لديهم بحرية.

+1 للتعليق السابق. next.js مذهل ، والسبب الوحيد الذي يجعلني لا أستخدمه هو عدم مرونة جهاز التوجيه. يرجى دعم React Router 6 في الإصدارات المستقبلية أو جعل جهاز التوجيه قابلاً للتبديل.

قد يكون الأشخاص الحريصون حقًا على React Router مهتمين باتباع المشروع الجديد "Remix" ، إنه بديل Next.js الذي يستخدم React Router ، بواسطة نفس المبدعين:

• https://twitter.com/remix_run/status/1253043162714525696
• https://remix.run

أعتقد أن المشكلة تكمن في أن إطار العمل مرتبط بشدة بهذا الموجه بسبب SSR ، ودعامات جانب الخادم ، إلخ ...

تم تصميم Next مع وضع الأداء في الاعتبار ، وللموجه التفاعلي من جانب الخادم تأثير كبير على الأداء في أنه يجب عليك السير في شجرة DOM قبل أن تعرف ما الذي ستحاول تقديمه ، وبالتالي البيانات التي ستحتاج إليها. الغرض الكامل من getInitialProps هو ألا تضطر إلى إجراء عرض سريع للرد قبل جلب البيانات ، وهي مشكلة شائعة تواجهها الكثير من الأطر على الخادم (وفي العميل ، حيث تظهر على أنها طلب الشلالات). من المحتمل أن يتغلب التالي على هذا من خلال جعل كل صفحة من صفحات المستوى الأعلى تعلن _جميع_ أنماط البيانات المختلفة التي قد تحتاجها المكونات الفرعية المختلفة وتتفرع على مسار الطلب الكامل (أو القيام بعملية جلب مفردة ضخمة) ، ولكن هذا سيصبح صعبًا بسرعة لن يكون الأمر مختلفًا في الواقع عن إعلان كل صفحة على حدة.

هذا هو نفس السبب الذي يجعل Relay غير متوافق مع جهاز التوجيه التفاعلي أيضًا ، ولا يمكنك اتهام facebook.com بأنه ليس موقعًا معقدًا.

تميل الإستراتيجية الرئيسية الناجحة للعمل مع جهاز التوجيه التالي إلى القابلية للتركيب (وهو الاتجاه الدافع في React الحديث على أي حال) ، مما يسمح لك بإعادة استخدام المكونات دون تكرار كبير مع وجود SSR فعال قادر على جلب جميع بياناته (عبر getInitialProps ) قبل التحدث إلى عارض React.

أشعر كما لو أن عقوبة أداء المشي على الشجرة مبالغ فيها. العديد من تطبيقات الإنتاج اليوم تقوم بذلك باستخدام Apollo ويبدو أنها جيدة.

بالإضافة إلى أنه يمكنك أيضًا تخزين استجاباتك مؤقتًا في CDN إذا كنت تريد حقًا تخفيف الخادم عن القيام بالكثير من العمل.

بالتأكيد ، أنا فقط أشير إلى السبب الرئيسي وراء عدم توافق جهاز التوجيه التفاعلي (AFAICT) بشكل أساسي مع Next في تنفيذه الحالي. الكثير من المواقع لا تحتاج حقًا إلى الكمال على الإطلاق ، كما يتضح من الأشخاص الذين يستخدمون دينوس Heroku المجاني مع أوقات بداية باردة بطيئة (وأريد أن أؤكد أنني لا أقول هذا بتنازل لأنني أفعل ذلك لبعض المواقع أيضًا وهو يمكن أن يكون مناسبًا تمامًا). لكن Next لن تحظى بشعبية لدى بعض الشركات الكبرى التي تستخدمها إذا كانت أقل شدة فيما يتعلق بالأداء حيث أن تلك الشركات ستهتم بأوقات استجابة الخوادم التي تكون أبطأ بشكل ملموس. إذا لم يكن الأمر مصدر قلق لبعض المواقع ، فلن يستخدم الأشخاص (وينتظرون بفارغ الصبر التحسينات على) عارض تدفق React لبدء الاستجابة قبل اكتمال تصيير واحد ، ناهيك عن اثنين.

يمكنك بالتأكيد تخزين استجاباتك في CDN مؤقتًا ، ولكن هذا يلغي الكثير من خيارات التخصيص / تسجيل الدخول (حيث إنها مقايضة مع انخفاض معدل الوصول إلى الصفحة أو تأجيل عرض الصفحة الجزئي للعميل). إذا كان بإمكانك تخزين تطبيقك بالكامل على CDN مؤقتًا ، فقد يكون من الأفضل لك استخدام CRA و react-snapshot وتجنب الخوادم تمامًا. لا يتعلق الأمر بالضرورة بحجم العمل الذي يقوم به الخادم الخاص بك ولكن بالأحرى المدة التي يستغرقها الرد على الطلب.

ويعد Apollo مثالًا رائعًا على إطار العمل الذي يؤكد على سهولة الاستخدام على الأداء ، مقارنةً بالإطار الأكثر تشددًا / الموجه نحو الأداء مثل Relay. كل هذا طيف.

نعم ، أعتقد أن هذا عادل بما فيه الكفاية. لكنني أشعر بالفضول لمعرفة كيفية ظهور remix.run ، فربما يأتون بنهج جديد لجعله يعمل مع react-router . نعم ، صحيح أن المسارات المتداخلة ليست إلزامية ، ولكن بالتأكيد يجب أن توافق على أنه من البديهي أن يكون لديك أجزاء من واجهة المستخدم الداخلية تتغير مع المسار ، بدلاً من أن يكون لديك صفحات مختلفة ولف كل من تلك الصفحات بتخطيطات مختلفة.

اعتبارًا من 9.3 التالي ، هناك getStaticPaths بالإضافة إلى getServerSideProps لمساعدة إطار العمل على اكتشاف المسارات التي يجب عرضها مسبقًا عندما يكون للمسار معلمات مسار. ربما يمكن اتباع نهج مماثل مع جهاز التوجيه التفاعلي.

merryweather : "تم تصميم Next مع وضع الأداء في الاعتبار ، ولدى جهاز توجيه رد الفعل من جانب الخادم تأثير كبير على الأداء في أنه يجب عليك السير في شجرة DOM قبل أن تعرف ما ستحاول تقديمه"

سؤال ساذج: هل يمكنك فقط عرض روابط المستوى الأعلى والجلب / الجلب المسبق / التخزين المؤقت بمجرد تشغيل الكود على العميل. إذا كنت لا تعرف إلى أين سينتقل العميل ، فهل من المنطقي اجتياز شجرة DOM على الخادم؟

سيناريو العمل الساذج: عندما يطلب العميل عنوان URL ، قم فقط بعرض روابط المستوى الأعلى ومحتوى الرابط النشط الافتراضي و ajax / جلب كل شيء آخر عند الطلب (أو الجلب المسبق في الخلفية بمجرد تحميل الصفحة) ... كل شيء آخر يشمل المستوى الأدنى طرق .. شطف وكرر ..؟

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

@ avin-kavish أنا لست أفضل شخص يجيب على تفاصيل التنفيذ ولكن يحتاج العميل فقط لعرض محتويات الشاشة الأولية: روابط المستوى الأعلى + المحتوى الافتراضي أي شيء آخر لا لزوم له عند أول تحميل على ما أعتقد. فلماذا تسير DOM على الخادم؟

المشكلة الرئيسية في Next.js ليست جهاز التوجيه ، إنها نمط جلب البيانات باستخدام getInitialProps أو getServerProps أو getStaticProps . لماذا ا ؟ لأنه يكسر عزل البيانات للمكون الذي يحتاجها. على سبيل المثال ، تريد الحصول على البيانات الخاصة بالقائمة ، من أين ستجلبها؟ لا أدري، لا أعرف. يجب ألا تعرف المكونات الرئيسية مثل pages أي شيء عنها ، أليس كذلك؟

المشكلة الرئيسية في Next.js ليست جهاز التوجيه ، إنها نمط جلب البيانات باستخدام getInitialProps أو getServerProps أو getStaticProps . لماذا ا ؟ لأنه يكسر عزل البيانات للمكون الذي يحتاجها. على سبيل المثال ، تريد الحصول على البيانات الخاصة بالقائمة ، من أين ستجلبها؟ لا أدري، لا أعرف. يجب ألا تعرف المكونات الرئيسية مثل pages أي شيء عنها ، أليس كذلك؟

هل يمكنك التفصيل من فضلك. وما هو الحل البديل؟

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

إليك نموذج الشفرة الذي أستخدمه لتطبيقي من أجل الوضوح:

const query = `
{
  result:users(
    where:{
      _and:[{
        active:{
          _eq:true
        }
      }, {
        is_exam_manager:{
          _eq:true
        }
      }]
    },
    order_by:{
      created_at:desc_nulls_last
    }
  ){
    id
    key:id
    user_code
    first_name
    last_name
    password
    active
  }
}
`
const Main = (props: any) => {
  const {
    data: { result }
  } = props
  return (
    <div>
      <Add title={'Add user'} role={'exam_manager'} />
      <Table
        columns={columns}
        dataSource={result}
        bordered={true}
        size={'small'}
      />
    </div>
  )
}
const MainWithData = graphql(query)(Main)
export default MainWithData

كما ترى ، لديك مكون واحد ببياناته الخاصة. يمكنك وضعها في أي مكان تريد.

بالطبع ، يمكنك استخدام نمط Next.js دون أي مشكلة ، ولكن في حالتي ، أفضل عزل البيانات والمكونات قدر الإمكان لتسهيل الصيانة وإعادة البناء لاحقًا.

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

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

linshine علينا تنزيل كل ما نحتاجه على مستوى الصفحة العليا.

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

إليك نموذج الشفرة الذي أستخدمه لتطبيقي من أجل الوضوح:

...

كما ترى ، لديك مكون واحد ببياناته الخاصة. يمكنك وضعها في أي مكان تريد.

بالطبع ، يمكنك استخدام نمط Next.js دون أي مشكلة ، ولكن في حالتي ، أفضل عزل البيانات والمكونات قدر الإمكان لتسهيل الصيانة وإعادة البناء لاحقًا.

@ revskill10 لماذا لا يمكنك أن تطلب من الأصل تضمين هذا الجزء في استعلام المستوى الأعلى؟ نظرًا لأنك تقوم بإنشاء المزيد من الأجزاء المرتبطة بالأطفال ، فسيكون لديك عزل مثالي للبيانات. لا يختلف وجود استعلام أصل مع جزء طفل عن إعلان ذلك الطفل في JSX ، لذلك لديك نفس مستوى الاقتران ولكن تجنب طلب الشلالات (أصعب بكثير في REST ، للأسف)

لدينا تطبيق Relay-Next ويعمل هذا النمط بشكل مثالي ، مع تغليف البيانات والتكوين القابل لإعادة الاستخدام ، ونستفيد من getInitialProps بسهولة.

merrywhether ناهيك عن much harder in REST ، نهجك به مشكلة ، لا يمكنك تحديد أي fragments سيكون SSG / SSR أو سيكون CSR.
في منهجي ، يكون الأمر سهلاً تمامًا مثل استيراد هذا المكون باستخدام { noSSR: true/false} .

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

لقد قمت مؤخرًا بمراجعة Next.js لتقييم ما إذا كان ينبغي استخدامه كأساس للنواة المشتركة المشتركة بين عدد من تطبيقات الواجهة الأمامية التي يتم إنشاؤها لعملائنا الحاليين. في حين أن Next.js لديه إمكانات ؛ يعد هذا الموجه أحد الأسباب الرئيسية التي دفعتني إلى رفض Next.js وبدلاً من ذلك احتفظت بـ CRA كقاعدة لهذه التطبيقات.

أنا أفهم صعوبة استخدام واجهة برمجة التطبيقات ذات المستوى الأعلى القائمة على المكون والتي تبلغ react-router / @reach/router كأساس لـ SSR. لكن هذا ليس سببًا وجيهًا لأن يكون التطبيق الأساسي مخصصًا تمامًا. لدى Gatsby's SSG نفس الاهتمامات مثل Next.js وهيكل توجيه شبه مشابه قائم على الملفات ؛ ولكن حسب فهمي ، يستخدم Gatsby @reach/router تحت الغطاء لتشغيل تطبيق التوجيه الخاص به بدلاً من إعادة اختراع العجلة أو الكشف عن واجهة برمجة تطبيقات Link التي تتعارض مع Link API التي تستخدمها المكتبات الأخرى.

dantman هل لي أن أسأل ما الذي اخترته لبديل Next.js. بافتراض أنك بحاجة إلى عرض جانب الخادم ... لقد كنت أجرب After.js ، فربما يمكن أن توفر بعض الإلهام / الأفكار حول كيفية التنفيذ في Next.js إذا لم تكن مدعومة من قبل zeit.

dantman هل لي أن أسأل ما الذي اخترته لبديل Next.js. بافتراض أنك بحاجة إلى عرض جانب الخادم ... لقد كنت أجرب After.js ، فربما يمكن أن توفر بعض الإلهام / الأفكار حول كيفية التنفيذ في Next.js إذا لم تكن مدعومة من قبل zeit.

آسف ، ليس لدي إجابة مفيدة لك. لم يكن SSR متطلبًا صعبًا ، لذلك واصلنا استخدام CRA ، الذي تم بناء النموذج الأولي به.

اعتقدت أن Next.js كان له وعد كإطار عمل عالمي لأنه اكتسب مؤخرًا القدرة على الحصول على مزيج من صفحات SSR / SSG / العميل فقط ويمكن تشغيله كتطبيق متماثل أو كتطبيق ثابت / PWA. كان تخصيص WebPack مغريًا لأن CRA كانت تجعل استخدام برنامج التحويل البرمجي العولمة أمرًا صعبًا. كان خادم Next.js محايدًا / إيجابيًا لأننا كنا بحاجة إلى خادم API على أي حال لجسر GraphQL / REST. وكان خيار SSR / SSG إيجابيًا لأنني أقوم ببناء النواة التي ستعتمد عليها ستة تطبيقات ، وليس من المستحيل أن ينتهي بها الأمر مفيدًا في المستقبل. ومع ذلك ، واجهت أيضًا بعض المشكلات المتعلقة بطريقة عمل SSR الخاص بـ Next.js وهذه الإيجابيات لا تستحق المتاعب التي يسببها جهاز التوجيه.

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

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

من الغريب جدًا تأهيل مكون مفتوح المصدر بواجهة برمجة تطبيقات لم تتغير منذ 3 سنوات نظرًا لاستقراره الكبير و "ملاءمة المنتج / السوق" على أنه "تأمين"

نجح Next.js ولا يزال يُظهر النمو الذي حققه بسبب جهاز التوجيه الخاص به وليس على الرغم منه.

كما رآني الكثيرون أعلق على Twitter ، في يوم من الأيام ، استمتعنا بجدية بالدمج في بعض أجهزة التوجيه (على الرغم من أنني مرتبك بشأن أي واحد هو المعيار في ذهنك ، Reach أو React Router ، وفي أي إصدار رئيسي). لكن العالم جذبنا في اتجاهات أخرى مثيرة للاهتمام. في الواقع ، لم نكن نعرف حتى ما هو الهدف من إضافته ، لأن الجميع استمروا في النجاح مع Next.js وبناء منتجات رائعة.

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

عندما أقول أن Next نجح بسبب جهاز التوجيه ، فهذا لأنه أزال مشكلتين:
1️⃣ فكرة الاضطرار إلى اختيار جهاز توجيه . إن إزالة هذا القرار بأثر رجعي ممتاز. في كل وقت وجود Next.js مع جهاز التوجيه المستقر ، انقسم عالم جهاز التوجيه وأطلق جميع أنواع تغييرات واجهة برمجة التطبيقات

2️⃣ منحنى التعلم لجهاز

أريد أن أؤكد هذه النقطة الأخيرة. فكر في واحد من أحدث وأسرع مواقع الويب نموًا في العالم ، TikTok.com ، المبني على Next.js. يمكن شرح هيكل التوجيه بالكامل لموقع الويب هذا من خلال منحنى التعلم الذي يستغرق ثانيتين. https://www.tiktok.com/@sheezus.christ/video/6824007862197439750 هو pages/[user]/video/[id].js و https://www.tiktok.com/trending هو pages/trending.js

يتم أيضًا تمكين العديد من ابتكارات Next.js الأخيرة التي ذكرت أنك تحبها ، مثل hybrid static / SSG / SSR ، من خلال تصميم جهاز التوجيه الخاص بنا. في الواقع ، سيمكن جهاز التوجيه أيضًا العديد من التحسينات المماثلة الأخرى القادمة في المستقبل لتقديم قدر أقل من JS للعملاء.

ومع ذلك ، واجهت أيضًا بعض المشكلات المتعلقة بطريقة عمل SSR الخاص بـ Next.js وهذه الإيجابيات لا تستحق المتاعب التي يسببها جهاز التوجيه.

أحب أن أسمع عن هؤلاء. المثال أعلاه مدعوم من Next.js hybrid static / SSR ونرى نجاحًا كبيرًا في هذا المجال في جميع المجالات!

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

في النهاية ، جهاز التوجيه التفاعلي ليس هو الحل النهائي لجميع حلول التوجيه. لها إيجابيات وسلبيات ، كما يفعل Next. FWIW ، لا يستخدم Facebook جهاز التوجيه التفاعلي ، وربما يعرفون شيئًا أو شيئين عن استخدام React. لذلك من الجيد أن يكون لديك بدائل ، وفي الواقع أحد الأشياء العظيمة في نظام JS البيئي: دع أشياء مختلفة تتنافس في ساحة الأفكار وفي النهاية نتحرك جميعًا إلى الأمام.

نظرًا لأنني أغلق المشكلة ، أود أن أوضح أننا منفتحون دائمًا على التعليقات وطلبات الميزات وتقارير الأخطاء المتعلقة بإمكانيات التوجيه.

من الناحية المثالية ، ستكون هذه المنتجات مدفوعة ("أحتاج إلى تنفيذ X ولكن هذا غير ممكن" أو "Y ممكن ولكن ليس مريحًا"). نحن نبحث دائمًا عن التحسينات التي تساعدك على إنشاء مواقع وتطبيقات سهلة الاستخدام تتمتع بتجارب مستخدم رائعة 🤗

rauchg هل يمكن أن تشرح سبب وجود اثنين من الدعائم ، href و as للرابط؟ لماذا لا تستطيع الاستدلال على الصفحة المقصودة بناءً على قيمة الخاصية as ؟

على سبيل المثال في express إذا كان لدي مسار مثل /blog/:slug ، يمكنني فقط إرسال طلب http إلى /blog/hello-world وأتوقع أن يوجه جهاز التوجيه إليه. لست مضطرًا لإرسال كلا من /blog/:slug و blog/hello-world إلى الخادم.

@ avin-kavish هذا سؤال رائع. هناك تمييز مهم يجب القيام به بين ما يعرضه عنوان URL والصفحة التي سيتم تحميلها. في الواقع ، يستخدم TikTok ذلك لعرض أشياء معينة في أشكال ، بحيث تصبح صفحات أخرى عند تحديث الصفحة. ومع ذلك ، هناك مجال كبير للتحسين هنا وهو أنه ربما يجب علينا أن نفرض بشكل ثابت أنك تشير إلى صفحة صالحة موجودة في نظام الملفات. سنتابع من خلال إنشاء مناقشة حول هذا الموضوع ووضع علامة عليك!

أعتقد أن هناك مشكلة موجودة بالفعل لهذا https://github.com/zeit/next.js/issues/8207

في حال شاهد شخص ما هذه المشكلة لموجه رد فعل مثل ميزة "المسارات المتداخلة" التي تسمح بالانتقال إلى صفحات جديدة دون إعادة عرض كل شيء كما كنت ، فهناك بالفعل مشكلة مخصصة يمكنك مشاهدتها والتصويت لها. لقد اكتشفت ذلك للتو: https://github.com/zeit/next.js/issues/8193

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

أن نكون واضحين في هذه المسألة الأولية بلدي ليس لعدم وجود API مكون RR / النمط المنال، أنا بخير مع ملف قادرة SSR / التكوين API القائمة. على الرغم من أنني متفائل قليلاً بأن التشويق في المستقبل يمكن أن يجعل واجهات برمجة تطبيقات SSR / التوجيه البديلة قابلة للتطبيق. مشكلتي الأساسية هي أن جهاز التوجيه مخصص تمامًا مع أي مخاوف مشتركة في التنفيذ يتم إعادة تنفيذه بدلاً من مشاركته مع أي جزء من مجتمع React الأوسع.

أجد أن نهج جاتسبي مقبول. لديهم ملف قادر على SSG + واجهة برمجة تطبيقات التوجيه القائمة على التكوين وتصدير مكون الارتباط المحسن الخاص بهم ؛ لكنهم يستخدمون @reach/router لتشغيل التنفيذ الأساسي.

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

من الغريب جدًا تأهيل مكون مفتوح المصدر بواجهة برمجة تطبيقات لم تتغير منذ 3 سنوات نظرًا لاستقراره الكبير و "ملاءمة المنتج / السوق" على أنه "تأمين"

جهاز التوجيه مرتبط بشكل جوهري بـ Next.js. يعني اعتماد Next.js لسبب واحد أن تكون مرتبطًا بالموجه. إذا اعتمدنا Next.js واكتشفنا لاحقًا أن التالي / جهاز التوجيه له قيود تبين أنه معوق لشيء نحاول القيام به ، فلا يوجد مطلقًا فتحة هروب معقولة. "Lock-in" هو وصف جيد تمامًا لذلك.

لن يكون القفل وحده مشكلة كبيرة. استخدام Gatsby لـ @reach/router سيكون أيضًا مقيدًا. ولكن يتم استخدام @reach/router خارج Gatsby فقط. لست مضطرًا إلى الوثوق بمجتمع Gatsby وحده للحفاظ على مكدس جهاز التوجيه بأكمله ؛ يمكنني أن أثق في أن مجتمعًا أكبر يعتمد عليه وأن هناك المزيد من أصحاب المصلحة المعنيين (خاصة بمكدس التوجيه) لضمان صيانته ، ومواكبة مشكلات التوجيه الصعبة (مثل إمكانية الوصول) ، ويعتمد عليه مجتمع أوسع أكثر تنوعًا من المحتمل أن تشارك أي مشاكل معيقة محتملة قد نواجهها في المستقبل.

على الرغم من أنني مرتبك بشأن أيهما هو المعيار في ذهنك ، Reach أو React Router ، وفي أي إصدار رئيسي

من حيث المعيار الواقعي لما يجب أن يبدو عليه <Link> . يشترك كل من Reach و React Router (RR) في واجهات برمجة تطبيقات متشابهة جدًا. على سبيل المثال ، <Link to='/about'>About</Link> صالح في كل من RR و Reach (وبالطبع بالامتداد Gatsby). مما يجعل Next.js ' <Link href='/about'><a>About</a></Link> أكثر إثارة للجدل.

من حيث ما أعتقد أنه يجب على Next.js استخدامه. أنا لست مرتبطًا بمكتبة معينة ، إذا كان Next.js يستخدم بالفعل مكتبة ، فلن أقترح التبديل إلى مكتبة أخرى. شاغلي الرئيسي هو مشاركة تطبيق التوجيه مع مكتبة مع مجتمع أوسع خارج Next.js.

من الناحية العملية على الرغم من أن هذا موضع خلاف نسبيًا حتى الآن لم أر أي جهاز توجيه React إلى جانب RR و Reach مع قاعدة مستخدم كبيرة. وستصبح RR و Reach مكتبة واحدة ، لذا أيهما تبدأ بالنتيجة النهائية ستكون هي نفسها.

لقد جربت Next منذ فترة ولكن الافتقار إلى المرونة على جهاز التوجيه قادني إلى اكتشاف تطبيق Razzle يسمى After.js https://github.com/jaredpalmer/after.js؟utm_source=hashnode.com.

نظرًا لأن جهاز React Router هو مجرد حزمة ، فلا يمكننا استيراده ونقصر التقديم على جانب العميل فقط حتى يعمل مثل SPA حيث يلزمه ويعطينا مسارات مكونات متداخلة؟ أليس جهاز توجيه React مجرد مجموعة من المكونات التي يجب (من المحتمل) تضمينها في الصفحات وتحميلها باستخدام جهاز توجيه الصفحة Next.js مثل أي مكونات أخرى؟

قرأت في خيوط سابقة أن زيت خطط لدمج RR هل هذا لا يزال صحيحًا اليوم؟

لماذا لا نسمح بالمسارات المتداخلة في جهاز التوجيه next.js كملاذ أخير ونوضح أن هذه المناطق لن يتم عرضها مسبقًا. على أقل تقدير ، سيوفر علينا ذلك الجهد المبذول لتجنب كتابة شروط if التي يتعين علينا حتمًا كتابتها عندما نريد تغيير مورد فرعي في الصفحة بناءً على المسار.

أقوم بإضافة تصويتي على هذه المسألة.

مؤيد آخر ، لم يذكر ، هو أن RR أكثر قابلية للاختبار ، (AFAIK لا توجد واجهة برمجة تطبيقات nextjs رسمية لاختبار جهاز التوجيه) ، لديها MemoryRouter لتغليف الاختبارات والقصص.

يحتوي Next.js على الكثير من الميزات الجيدة (حزمة الويب التلقائية ، والملفات الثابتة ، و TypeScript مثل CRA ولكن لأكثر من مجرد PWAs ؛ مسارات API ؛ دعم بدون خادم ، تحديث سريع ، وحتى دعم إكسبو التجريبي للويب + التطبيقات الأصلية) ونواة لـ SSR و SSG حتى لو لم تكن واجهة برمجة التطبيقات الخاصة بها رائعة. ولكن بينما يعمل نظام التوجيه المدمج و SSR / SSG للبعض ؛ بالنسبة للآخرين ، فإنهم يعرقلون التطوير لأن حدود كل من واجهات برمجة التطبيقات تقدم مقايضات خاطئة للمشروع المذكور.

ماذا عن التسوية. يحتوي Next.js بالفعل على مكونات إضافية. بدلاً من استبدال جهاز التوجيه داخليًا ، ماذا لو فصلنا جهاز التوجيه وواجهة برمجة تطبيقات SSR (على سبيل المثال getStaticProps / getServerSideProps في ملفات التوجيه) عن قلب Next.js. على سبيل المثال ، يمكننا وضع الأجزاء الأساسية الأساسية في @next/core ونقل جهاز التوجيه الحالي ذي الرأي و get*Props API إلى @next/router . من أجل البساطة والتوافق مع الإصدارات السابقة ، يمكن أن يكون next إطار عمل يعيد تصدير @next/core ويأتي مُهيأ مسبقًا مع جهاز التوجيه المفضل لـ Vercel. ولكن بعد ذلك سيكون من الممكن أن يطور المجتمع أجهزة توجيه وواجهات برمجة تطبيقات SSR / SSG بمقايضات مختلفة مناسبة بشكل أفضل للمشاريع التي لولاها ستكون عالقة في التخلص من الأجزاء الجيدة من Next.js بمياه الاستحمام.

بعض الأفكار حول ما قد يتطلبه جوهر Next.js من المكوِّن الإضافي لجهاز التوجيه:

• بالنظر إلى الطلب {url، body، etc} ، يتوقع النواة أن يقوم المكون الإضافي للموجه بتقديم هذا الطلب إلى مستند (سلسلة أو دفق) أو تقديم استجابة (أي 404 أو إعادة توجيه).
• عند التصدير ، يتوقع النواة أن يوفر المكون الإضافي لجهاز التوجيه قائمة بالصفحات التي يجب عرضها.

@next/router المحتمل أن يقوم

• عند تقديم طلب ، تحديد مسؤولية ملف المسار وتقديمه كالمعتاد
• على العميل القيام بشيء مشابه لما يفعله حاليًا لمعرفة وقت استدعاء SSR API وعرض المسار الذي يحتاجه (ربما نقل SSR API المستند إلى API إلى مسار API عادي المظهر)
• عند التصدير باستخدام شجرة ملف الصفحات و getStaticPaths لتوفير قائمة الصفحات الثابتة

ربما أرى نفسي أجرب مكوّنًا إضافيًا لجهاز التوجيه باستخدام React Router v6 @apollo/react-ssr و Suspense بـ react-ssr-prepass أو react@experimental . الذي يتجاهل مسارات SSR فقط لمسارات SSR المتشابهة وينفذ SSR / SSG بدون تقييد واجهة برمجة تطبيقات نمط get*Props .

ما أدركته هو أن التوجيه المتداخل + SSG يمكن تحقيقه دون كسر واجهة برمجة التطبيقات الحالية. لذلك لدينا getStaticPaths في الوقت الحالي ، يمكننا استخدام ذلك للتلميح إلى المسارات المتداخلة للعرض المسبق. فمثلا،

بالنظر إلى المسار /foo/[...slug] ،

function FooPage() {

  return (
      <Switch>
          <Route path="/foo/bar">
              <SomeResource />
              <Route path={`${parenthPath}/baz`} component={SomeSubResource} />
          </Route>
          .... more routes
      </Switch>
  )
}

يمكن تقديمها مسبقًا ،

export async function getStaticPaths() {

  return {
    paths: [
      { slug: [ 'bar' ] },
      { slug: [ 'bar', 'baz' ] },
    ],
  }
}

مع ما هو عليه في الوقت الحالي ، فإن next.js يشبه إطار عمل جانب الخادم مع سهولة إنشاء صفحات تفاعلية. لا تبدو قوية مثل react-router . قد يكون للتوجيه المستند إلى الدليل مكانه في بناء مواقع مواجهة للمستهلكين مثل tiktok كما ذكرنا من قبل ، ولكن بالنسبة لبوابات التطبيقات المعقدة التي تعتمد على البيانات ، لا يزال التوجيه المتداخل هو الملك. ولهذا السبب تم إنشاء تطبيقات الصفحة الواحدة في المقام الأول ، فهي تسمح بتغيير أجزاء واجهة المستخدم دون الحاجة إلى استبدال الصفحة بأكملها. يمكن الاستفادة من ذلك لنمذجة علاقات الموارد الفرعية بسهولة تامة. كما هو الحال ، قد أستخدم next.js إذا كنت سأبني الصفحات العامة لموقع المستهلك مثل موقع التجارة الإلكترونية ولكن عندما أحتاج إلى إنشاء المجالات الخاصة مثل بوابات الإدارة والمشتري والبائع قم بالتبديل إلى CRA.

@ avin-kavish ، فإن المشكلة الرئيسية ليست جعلها تعمل ، ولكن لجعلها محسّنة: كل صفحة في Next.js الافتراضية لها حزمة خاصة بها ومُحسّنة للسرعة.

إذا بدأت في إضافة الكثير من المحتوى / المحتوى الفرعي في صفحة واحدة كما فعلت ، فقد ينتهي بك الأمر بمجموعة كبيرة جدًا في النهاية (وهو ليس "فظيعًا" بحد ذاته ، ولكن يجب أن تكون على دراية فقط بـ المقايضات). قد تتمكن من إجراء بعض التحسينات اليدوية باستخدام next/dynamic فكر :)

rauchg ، البعد الوحيد ليس ما إذا كان جهاز التوجيه التالي جيدًا أم سيئًا. شيء آخر مهم للغاية هو الترحيل من وإلى next.js ودعم المجتمع ، و https://github.com/vercel/next.js/issues/1632#issuecomment -633310614 ضعها جيدًا. يعد Next.js حلاً جيدًا لاستخراج الكثير من النموذج المعياري الذي يحتاجه تطبيق SSR عالي الجودة ، وبالتالي فهو هدف ترحيل جذاب للعديد من تطبيقات الويب. تكمن المشكلة الآن في أنه سيحتاج إلى إعادة كتابة كاملة للتوجيه من أجل الترحيل إلى next.js والخروج منه إذا دعت الحاجة.

التوجيه القابل للتوصيل الذي اقترحه

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

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

تخمين بحت ، لكني أتخيل أن الكثير من الأشياء في طي النسيان بينما تنتهي React من التشويق ، نظرًا لأن إنشاء نمط من الدرجة الأولى في المكتبة سيؤثر بشكل كبير على جميع مكتبات أجهزة التوجيه ويعطي أيضًا أساسًا ملموسًا لبناء غير متزامن / قابل للتحميل أنماط الحزمة.

قصة طويلة قصيرة / ملخص جيد لما يلي: لا يوجد شيء مثل "حل واحد يناسب الجميع". كل شيء له مفاضلات. كل "ميزة" للطريقة التي يقوم بها Next.js بالأشياء حاليًا تأتي مع عيب. ما هي المزايا / العيوب الأكثر أهمية هو شيء مختلف لكل مشروع. ومن ثم ، فإن التوصية الخاصة بمعمارية موجّه / ssg / ssr قابلة للتوصيل. تحتاج المشاريع المختلفة إلى أشياء مختلفة ويعمل Next.js الآن فقط مع المشاريع التي تتوافق أولويتها في المقايضات مع الطريقة التي يتم بها ترميز الأشياء في Next.js.

تكمن المشكلة في جهاز التوجيه التفاعلي (وأي حل توجيه متداخل) في أنه يجعل التحليل الثابت أكثر صعوبة لأن مسارات الكود ذات الصلة لأي عنوان URL محدد غير متوفرة بدون تشغيل (أو محاكاة) الشفرة نفسها.

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

إنها ميزة أكيدة ، وبعض الفرق تريد ذلك. ومع ذلك ، فهذه مجموعة فرعية واحدة فقط من مستخدمي Next.js المحتملين. هناك مجموعات أخرى قد ترغب في الحصول على بعض المزايا التي توفرها RR أو مكتبة توجيه أخرى والحاجة إلى الإعلان صراحة عن المسارات الثابتة هي مقايضة مقبولة أو ليست مشكلة. على سبيل المثال ، كانت مشاريعي القليلة الأخيرة من نوع تطبيقات B2B / B2C حيث تكون 100٪ من الأشياء خلف صفحة تسجيل الدخول وليس هناك فائدة من عرض أي منها بشكل ثابت. يتمتع Next.js ببعض المزايا مقارنة بـ CRA التي كانت ستجعل Next.js أفضل ؛ لكن أشياء مثل جهاز التوجيه كانت بمثابة علامات حمراء كبيرة واستمرنا في استخدام CRA. كانت هذه المشاريع مناسبة تمامًا لـ Next.js مع جهاز توجيه رد الفعل الخام.

يفترض هذا أيضًا أن كل شخص لا يريد next/router يريد استخدام نموذج JSX لجهاز التوجيه المتفاعل. هذا ليس النوع الوحيد من البدائل next/router .

نوع آخر من أجهزة التوجيه هو أسلوب Gatsby.js. حيث لا يزال المشروع يستخدم بنية صفحات قائمة على نظام الملفات ، ولكن يتم تنفيذ الأجزاء الداخلية مع مكتبة توجيه أخرى مثل جهاز التوجيه التفاعلي (يستخدم Gatsby @reach/router داخليًا). يمنحك هذا النوع من المكونات الإضافية لجهاز التوجيه نفس مزايا التحليل الثابت. ولكنه سيمنحك أيضًا أي مزايا لم يرتبط بها جهاز التوجيه البديل بالتوجيه المتداخل. على سبيل المثال ، استيعاب التفضيلات المحتملة لـ route API ، والتعامل الأفضل مع إمكانية الوصول ، وتكامل أفضل في النظام البيئي حول جهاز التوجيه هذا.

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

اعتاد مستخدمو جهاز التوجيه التفاعلي على استخدام رد الفعل القابل للتحميل مباشرة لأنه يفوض هذه المسؤولية بالكامل للمستخدمين النهائيين ، لكن Next يحاول تجريد هذا الأمر وأتمته وهو أمر غير سهل.

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

هذه ملاحظة جانبية ، لكنني أشعر بالفضول حيال إمكانية وجود مكون إضافي babel / webpack يقوم بذلك تلقائيًا للطرق.

أيضًا مكتبة قابلة للتحميل هي مكتبة منتهية بشكل فعال (سنتان منذ النشر ، لا تقبل تقارير الأخطاء). أنا شخصياً أفضل أن أقوم بتقسيم الكود يدويًا باستخدام @loadable/components بدلاً من استخدام شيء مدمج تلقائيًا في Next.js استنادًا إلى مفترق داخلي للتفاعل القابل للتحميل.

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

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

تخمين بحت ، لكني أتخيل أن الكثير من الأشياء في طي النسيان بينما تنتهي React من التشويق ، نظرًا لأن إنشاء نمط من الدرجة الأولى في المكتبة سيؤثر بشكل كبير على جميع مكتبات أجهزة التوجيه ويعطي أيضًا أساسًا ملموسًا لبناء غير متزامن / قابل للتحميل أنماط الحزمة.

يمكن أن يكون هذا بحد ذاته حجة جيدة للعمل على نظام توجيه قابل للتوصيل. في الوقت الحالي ، نظرًا لأن جميع عناصر التوجيه و SSR مشفرة بشكل ثابت في Next.js ، فلا يمكن إجراء التجربة بسهولة في أي نوع من أنظمة التوجيه المستقبلية داخل Next.js. كيف يؤثر التشويق على توجيه Next.js ومكتبات التوجيه الأخرى؟ ليس شيئًا يمكنك تجربته (على الأقل فيما يتعلق بـ SSR والتجميع في Next.js) بدون تفرع وإعادة كتابة أجزاء من Next.js.

ستكون المكونات الإضافية لجهاز التوجيه مكانًا رائعًا للقيام بهذا النوع من التجارب. طالما أن API البرنامج المساعد هو على مستوى منخفض بما فيه الكفاية أنه سيكون من الممكن لمفترق فقط next/router المساعد ومحاولة كتابة الرد @ تجريبي إصدار المستندة + المعلق من أن جهاز التوجيه. ونظرًا لأن هذا مكون إضافي (ليس مفترقًا لجميع ملفات Next.js) ، سيكون من السهل الاشتراك في التجربة واختبار جهاز التوجيه الجديد القائم على التشويق. هذا مهم الآن وليس لاحقًا لأن هذا النوع من التجارب هو سبب وجود رد فعل @ تجريبي ، لجمع التعليقات من مشروعات حقيقية.

@ dantman أنا لا أختلف مع أي شيء قلته. _ هو _ كل شيء عن المقايضات. أكبر مقايضة هي ما يقضي الفريق التالي وقته فيه. حتى الآن ، يبدو أن SSR عالي الأداء كان تركيزهم الرئيسي. أفهم أن هذا ليس بالضرورة مناسبًا لجميع المستخدمين ، ولكنه الزاوية التي استخدمها Next في البداية للتميز (وهذا هو سبب اختيارنا لهم في العمل). لقد حفروا مؤخرًا المزيد في SSG ، على ما يبدو بسبب شعبية Gatsby و Jamstack ، لكنهم ما زالوا الأفضل لـ SSR imo.

بصراحة ، هذا مهم فقط إذا كنت تستخدم SSG ولديك مجموعة من المسارات غير الديناميكية

لست متأكدًا مما تقصده بهذا ، لأن SSG مقابل SSR لا يهم حقًا لمحاولة تقديم أصغر حمولة ممكنة من JS للصفحة الأولى ("المسار الحرج" JS) ، ولا المسارات الديناميكية. يعد تقليل أصول المسار الحرج أمرًا مهمًا بشكل عام لتطبيقات SSR (وبالتالي كل الجهد) لذا فإن هذا موضع تقدير. وبصراحة ، إذا كان كل ما تقوم به هو تطبيقات المسؤولية الاجتماعية للشركات المحجوزة في جدار تسجيل الدخول فقط ، فإن التالي _ يفعل _ لديه الكثير من الجوانب السلبية مقارنة بـ CRA (لن يكون SSR ملائمًا مثل CSR). يبدو أنك تستبعد تلك التطبيقات التي تقوم بالفعل بتشغيل SSR (مع معالجة جانب الخادم لتسجيل الدخول / التخصيص) خصيصًا لتحقيق انتصارات الأداء. ليس كل شيء يناسب ثنائية SSG مقابل CSR.

البعض منا على ما يرام في التعامل مع تقسيم الشفرة بأنفسنا

البعض منا قادر تمامًا على التعامل مع webpack ، و response-dom / server ، وما إلى ذلك بأنفسنا أيضًا. يبدو أن هدف Next حتى الآن هو جعل هذا الطرد نادرًا ونادرًا مثل CRA. وأنت على حق ، كان يجب أن أقول رد الفعل - التحميل على حد سواء ، لأن هناك الكثير من الحلول في هذا الفضاء ، وهي تزداد غرابة فقط مع أنماط البيانات الإضافية الناشئة من مكتبات مثل Relay.

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

بصراحة ، هذا مهم فقط إذا كنت تستخدم SSG ولديك مجموعة من المسارات غير الديناميكية

لست متأكدًا مما تقصده بهذا ، لأن SSG مقابل SSR لا يهم حقًا لمحاولة تقديم أصغر حمولة ممكنة من JS للصفحة الأولى ("المسار الحرج" JS) ، ولا المسارات الديناميكية.

ربما نفكر في أسباب مختلفة لضرورة القدرة على التحليل الثابت للطرق الموجودة. بافتراض أننا نتحدث عن "التحليل الثابت" على أنه "القدرة على تحديد قائمة المسارات (على سبيل المثال ['/about', '/', '/profile'] ) في وقت الإنشاء بمجرد قراءة الرمز".

يبدو أنك تتحدث عن نوع من تحسين حزمة JS؟ التي لم أجد أي معلومات عنها في الوثائق ، لذا فأنا لست على دراية بنوع التحسين على أساس تحليل المسار الثابت الذي تفكر فيه.

كنت أفكر في أن هذا التحليل الثابت للطرق كان مفيدًا بشكل أساسي لـ SSG. على سبيل المثال ، نظرًا لوجود ملف pages/about.js عند إنشاء موقعك ، فإن Next.js يعرف أن المسار /about موجود ويحتاج إلى تقديم html مسبقًا لهذا المسار ، على الرغم من أنك لم تخبره بذلك صراحة هناك مسار /about للعرض المسبق.

لا يحتاج SSR إلى لغة تأشير النص الفائق مسبقة الإنشاء لأنه لا يفعل ذلك إلا عند ورود طلب (عند هذه النقطة يقوم بتشغيل الكود ولديه مسار واحد لتقديمه) لا تحتوي الصفحات التي يعرضها العميل على HTML معروض مسبقًا على الإطلاق. وإذا كانت صفحة SSG الخاصة بك ديناميكية ، فأنت بحاجة إلى إعلان جميع المسارات على أي حال. ومن هنا أفكاري.

وبصراحة ، إذا كان كل ما تقوم به هو تطبيقات المسؤولية الاجتماعية للشركات المحجوزة في جدار تسجيل الدخول فقط ، فإن التالي _ يفعل _ لديه الكثير من الجوانب السلبية مقارنة بـ CRA (لن يكون SSR ملائمًا مثل CSR).

ما هي الجوانب السلبية التي تفكر فيها في Next.js فيما يتعلق بتطبيقات المسؤولية الاجتماعية للشركات؟ بصرف النظر عن مشاكل جهاز التوجيه المذكورة أعلاه.

حسب فهمي ، فإن Next.js يدعم النطاق الكامل لطرق SSR / SSG / CSR. لذلك من المفترض أنها لا تزال مناسبة لكتابة تطبيقات CSR المقيدة بجدار تسجيل الدخول فقط.

شخصيًا وجهة نظري هي بالتأكيد من شخص يكتب الكثير من تطبيقات CSR إلى حد كبير ، مع احتياجات SSR و SSG من حين لآخر ، ويرغب في الحصول على مجموعة أدوات قوية واحدة لجميع مشاريعي ، بغض النظر عن مزيج SSR / SSG / CSR الذي يحتاجون إليه.

من واقع خبرتي ، فإن CRA لديها عدد لا بأس به من العيوب حتى داخل تطبيقات المسؤولية الاجتماعية للشركات فقط والتي يمكن أن تجعل صفحات CSR الخاصة بـ Next.js مفيدة. يعد تخصيص تكوين WebPack بدون إخراج أمرًا كبيرًا. لقد تسبب لي هذا في الكثير من الألم عندما لم أتمكن ببساطة من استخدام المكون الإضافي WebPack Globalize-compiler عندما كنت أضيف i18n إلى أحد التطبيقات. تعد القدرة على الاشتراك في SSR / SSG لصفحات معينة حتى لو كانت معظم الصفحات CSR ميزة أيضًا (على سبيل المثال ، 99.9 ٪ من صفحاتك هي CSR وخلفية صفحة تسجيل الدخول ؛ ولكن لديك صفحة مقصودة وربما شروط / جهة اتصال الصفحات التي تريد SSG أو SSR عليها). لا يمكن القيام بأي من هذه الأشياء بشكل معقول مع أشياء مثل CRA.

البعض منا على ما يرام في التعامل مع تقسيم الشفرة بأنفسنا

البعض منا قادر تمامًا على التعامل مع webpack ، و response-dom / server ، وما إلى ذلك بأنفسنا أيضًا. يبدو أن هدف Next حتى الآن هو جعل هذا الطرد نادرًا ونادرًا مثل CRA

بصراحة ، يعد إجراء تقسيم التعليمات البرمجية استنادًا إلى المسار يدويًا (التأكد من تعديل أحدها لاستخدام مكونات مسارك عبر React.lazy أو مكتبة بديلة بدلاً من الاستيراد المباشر) بعيدًا عن إدارة تكوين WebPack المخصص أو الكتابة يدويًا معالجات SSR الخاصة بك مع react-dom/server .

من المعقول تمامًا ألا ترغب في كتابة تهيئة WebPack بالكامل يدويًا أو خادم SSR مخصص (أي تريد استخدام إطار عمل واسع الاستخدام مثل Next.js) ، ولكن لا يزال بإمكانك استخدام جهاز التوجيه التفاعلي والقيام يدويًا بتنفيذ التعليمات البرمجية القائمة على المسار- شق. خاصة إذا كان الاشتراك في تقسيم رمز قاعدة المسار التلقائي يعني فقدان مكتبة جهاز التوجيه المستخدمة على نطاق واسع واستخدام جهاز توجيه يفتقد إلى عدد من الميزات التي قد تحتاجها مع واجهة برمجة تطبيقات مختلفة تمامًا عن أي من أجهزة التوجيه في الاستخدام الأوسع.

دائمًا ما أواجه هذه المشكلة عند البحث عن طريقة لدمج react-router مع NextJS التي لا تتطلب إنشاء خادم مخصص ، لذلك قررت أن أجربها بنفسي.

باستخدام react-router v6 (تجريبي) ، أنشئ _app مخصصًا:

// _app.js || _app.tsx
import * as React from 'react'
import App from 'next/app'
import NextRouter from 'next/router'

export default class CustomApp extends App {
    render() {
        const { Component, pageProps } = this.props

        if (process.browser) {
            const { Router } = require('react-router-dom')
            const { createMemoryHistory } = require('history')
            const history = createMemoryHistory({
                initialEntries: [this.props.router.asPath],
            })

            history.listen(function ({ action, location }) {
                const url = {
                    hash: location.hash,
                    pathname: location.pathname,
                    search: location.search,
                }
                switch (action) {
                    case 'PUSH':
                        return NextRouter.push(url)
                    case 'REPLACE':
                        return NextRouter.replace(url)
                    default:
                        return void 0
                }
            })

            return (
                <Router location={history.location} navigator={history} action={history.action}>
                    <Component {...pageProps} />
                </Router>
            )
        } else {
            const { StaticRouter } = require('react-router-dom/server')
            return (
                <StaticRouter location={this.props.router.asPath}>
                    <Component {...pageProps} />
                </StaticRouter>
            )
        }
    }
}

لماذا ا

ليس من السهل إدارة _ التقاط جميع المسارات الاختيارية_ في NextJS (على سبيل المثال: /foo/[[...bar]].js ) ، لذلك أنا أستكشف طريقة تمكن من استخدام react-router لهذا النوع من الصفحات. ربما يكون للآخرين أسباب مختلفة ولكن هذا هو شاغلي الرئيسي و react-router يوفر واجهة برمجة تطبيقات لطيفة ، خاصة في الإصدار 6 الذي يوجد حاليًا في مرحلة تجريبية.

كيف تعمل

إنه ينشئ فقط MemoryRouter مخصصًا بدلاً من BrowserRouter حتى لا نعبث في سجل المتصفح من خلال وجود جهاز توجيه NextJS وجهاز توجيه NextJS. يستمع إلى تغييرات محفوظات الذاكرة لـ PUSH و REPLACE لذا يمكنك استخدام خطافات react-router أو Link للتنقل ولكن تحت الغطاء ، سيكون استدعاء طرق جهاز التوجيه NextJS .push و .replace .

يلزم استدعاء طرق جهاز توجيه NextJS ، وإلا فلن تؤدي تغييرات المسار فعليًا إلى تشغيل طرق NextJS get*Props . بمعنى آخر ، ستعمل بشكل مشابه كخيار shallow باستخدام NextJS Link . الجانب السلبي لاستخدام react-router s Link هو عدم وجود prefetch . ومع ذلك ، لا يزال بإمكانك استخدام NextJS Link بدلاً من ذلك ، ولا يزال بإمكان react-router التفاعل مع تغييرات المسار.

الشيء الرائع في الأمر أنه يمكنك الآن الاستفادة من مسارات NextJS dynamic و react-router والقيام بأشياء مثل:

// /foo/[[...bar]].js
import * as React from 'react'
import { Route, Routes } from 'react-router-dom'
import dynamic from 'next/dynamic'

const Home = dynamic(() => import('src/views/Home'))
const About = dynamic(() => import('src/views/About'))
const Navigation = dynamic(() => import('src/views/Navigation'))

export default function Root() {
    return (
        <>
            <Navigation />
            <Routes>
                <Route path="/foo/" element={<Home />} />
                <Route path="/foo/about" element={<About />} />
            </Routes>
        </>
    )
}

على أي حال ، آمل أن يساعد هذا شخصًا ما. لم أستخدم هذا في الإنتاج وهذا الرمز مأخوذ من ملعب محلي أملكه ، لذلك ربما هناك أشياء يمكن تحسينها ولكنها بداية.

استخدام React Router مع Next.js 9.5+

إذا كنت تستخدم Next.js 9.5 أو أحدث ، فإن الطريقة الصحيحة للقيام بذلك هي باستخدام Rewrites . _ لا تستخدم خادمًا مخصصًا_! يوجد برنامج تعليمي مفصل حول كيفية القيام بذلك هنا: https://colinhacks.com/essays/building-a-spa-with-nextjs

الفكرة الأساسية:

1. إنشاء تطبيق مخصص ( /pages/_app.tsx )

2. إرجاع null إذا typeof window === "undefined" . هذا مطلوب لمنع جهاز توجيه رد الفعل من إلقاء أخطاء أثناء خطوة SSR!

// pages/_app.tsx

import { AppProps } from 'next/app';

function App({ Component, pageProps }: AppProps) {
  return (
    <div suppressHydrationWarning>
      {typeof window === 'undefined' ? null : <Component {...pageProps} />}
    </div>
  );
}

export default App;

السمة suppressHydrationWarning هي منع التحذيرات التي تطلقها React عندما يختلف المحتوى المعروض على الخادم مع المحتوى المقدم من قبل العميل.

1. أعد كتابة جميع المسارات إلى الصفحة الرئيسية

// next.config.js

module.exports = {
  async rewrites() {
    return [
      // Rewrite everything else to use `pages/index`
      {
        source: '/:path*',
        destination: '/',
      },
    ];
  },
};

ثم يمكنك استخدام React Router كالمعتاد! يوجد الكثير من السياق / الشرح في البرنامج التعليمي المرتبط ولكن هذا سيساعدك على البدء. https://vriad.com/essays/building-a-spa-with-nextjs

colinhacks حل لطيف يمكن أن يؤكد أنه يعمل. ربما يكون هناك شيء يجب التفكير فيه هو نقل التطبيق إلى صفحته الخاصة مثل app.js أو route.js أو شيء من هذا القبيل. ثم بعد إعادة كتابة ل

// next.config.js

module.exports = {
  async rewrites() {
    return [
      {
        source: '/app/:path*',
        destination: '/app',
      },
    ];
  },
};

مجرد شيء للتفكير فيه ، حلك هو أفضل ما وجدته.