استطلاع : للتعبير عن الاهتمام بالمعايير الاختيارية ، يرجى الرد بـ "+1" هذا التعليق.

ملاحظة : المعلمات الاختيارية ممكنة بالفعل مع RFC هذا ، ولكن ليس لديهم صيغة واضحة (انظر قسم التحذيرات ).

استطلاع : للتعبير عن الاهتمام بالمعلمات الشاملة ، يرجى الرد بـ "+1" هذا التعليق.

ملاحظة : يرجى مشاركة حالة الاستخدام الخاصة بك للمعلمات الشاملة في هذا الموضوع! نود أن نفهم مساحة المشكلة أكثر.

محفوظة 3

في ricardo.ch ، نستخدم بادئة محلية لكل مسار مما يجعل التوجيه أكثر تعقيدًا.

مثال على المسارات الصالحة:

• / - الصفحة الرئيسية ذات اللغة المكتشفة تلقائيًا
• /:locale - الصفحة الرئيسية ذات الإعدادات المحلية المفروضة
• /:locale/search - صفحة البحث
• /:locale/article/:id - صفحة المقالات

هل تعتقد أنه يمكن دعم معلمات البادئة هذه؟

في الوقت الحالي ، نستخدم https://www.npmjs.com/package/next-routes

شيء آخر: بالنسبة لصفحة المقالة ، ندعم أيضًا slug قبل المعرف مثل /de/article/example-article-123 حيث سيكون المعرف 123. يتم ذلك عبر regex معقد جدًا باستخدام next-routes وأنا لا أفعل انظر كيف يمكن التعبير عن ذلك باستخدام واجهة برمجة تطبيقات نظام الملفات.

ValentinH ، جميع المسارات المتوفرة ممكنة باستخدام واجهة برمجة تطبيقات نظام الملفات - نظرًا للمسارات المقدمة:

• / => pages/index.js
• /:locale => pages/$locale/index.js
• /:locale/search => pages/$locale/search.js
• /:locale/article/:id => pages/$locale/article/$id.js

نحن ندعم أيضًا slug قبل المعرف مثل / de / article / example-article-123 حيث يكون المعرف 123

تم تناول حالة الاستخدام هذه أعلاه:

لا يمكن أن تظهر المعلمات المسماة في منتصف اسم المسار.

هذا يعني أن الصفحة المسماة blog-$id.js سيتم تفسيرها حرفيًا ولن تتم مطابقتها بـ /blog-1 . يمكنك إما إعادة هيكلة صفحاتك لتصبح /blog/$id.js أو تحويل جزء URL بالكامل إلى معلمة محددة والتعامل مع تجريد blog- في كود التطبيق الخاص بك.

هل هذا الحل لا يلبي احتياجاتك؟ نود معرفة المزيد عن متطلباتك المحددة.

شكرا جزيلا للإجابة.

لم أفكر في استخدام $locale/index.js كمجلد وملف ، فهذا رائع حقًا!

فيما يتعلق بـ "المعلمة المسماة في المنتصف" ، فقد أغفلتها لأنني اعتقدت أن وجود سبيكة ديناميكية أمر مختلف. ومع ذلك ، فأنت محق تمامًا ويتم تناول ذلك في الفقرة التي ذكرتها. سيكون وضع شريط في رمز التطبيق هو السبيل للذهاب 🙂

هل سيكون شيء من هذا القبيل (تحليل المعلمات من .files / .folders) ممكنًا؟

pages/
├── .root.js
├── blog/
│ ├── .id/
│ │ ├── index.js
│ │ └── comments.js <-- optional?
├── customers/
│ ├── .customer/
│ │ ├── .post/
│ │ │ └── index.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

أو اترك $ حتى يتمكن المرء من العثور على ملفاته: D ولكن دائمًا استخدم المجلد $ للإشارة إلى المعلمة؟

pages/
├── $root.js
├── blog/
│ ├── $id/
│ │ ├── index.js
│ │ └── comments.js <-- optional?
├── customers/
│ ├── $customer/
│ │ ├── $post/
│ │ │ └── index.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

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

• /packages/express
• /packages/express/dependencies
• /packages/@babel/core
• /packages/@babel/core/dependencies

لذلك ، تعتبر معلمة النطاق اختيارية ، ولكنها أيضًا نطاق فقط عندما تبدأ بـ @ .
لذا ، فإن /packages/express/dependencies و /packages/@babel/core لهما نفس المقدار من الشرائح ، لكن في حالة واحدة يكون /dependencies express و في الحالة الأخرى /index من @babel/core .

في النهاية تم حلها بـ react-router بالمسارات التالية:

<Switch>
  <Route path={`/packages/`} exact component={PackagesOverview} />
  <Route path={`/packages/:name(@[^/]+/[^/]+)`} component={PackageView} />
  <Route path={`/packages/:name`} component={PackageView} />
</Switch>

لست متأكدًا من أنني أرى حلاً لحالة الاستخدام هذه في RFC.

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

سنتان: علامات الدولار في أسماء الملفات فكرة سيئة لأنها تستخدم من قبل القذائف كوسيلة سيجيل. ستربك الأشخاص الذين يحاولون تشغيل rm $root.js . تبدو الخطوط السفلية بديلاً لائقًا.

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

مثل ValentinH ، نستخدم $ locale var ، لكنه اختياري.

هل يجب أن نستخدم /page.ts و /page/$locale/page.ts؟

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

لكن لدينا المزيد من حالات الاستخدام: / car / search / $ Optional-filter-1 / $ Optional-filter-2 / $ Optional-filter-3

حيث اختياري الفلتر 1: اللون الأحمر ، مرشح اختياري 2: العلامة التجارية فورد ، إلخ ...

وبالنسبة إلى المعلمات الاختيارية ، هناك شيء مثل / $ required-param / و / $$ Optional-param /؟

من الرائع أن هذا سيظهر في خريطة الطريق!

لا بد لي من الرنين في دعم @ Timdp رغم ذلك. عندما لا تستطيع حتى touch $file سيؤدي ذلك إلى الكثير من الالتباس. عليك أن تتذكر الهروب عند كل تفاعل. سيفتح touch \$file; vim $file vim بدون ملف (لأن $ file ليس متغيرًا محددًا).
وبالمثل ، فإن إكمال علامة التبويب في قذيفة سيسرد جميع المتغيرات ، مما يؤدي مرة أخرى إلى حدوث ارتباك.

أقترح بديلين أشعر أنهما يقدمان الارتباطات الصحيحة ويجب أن يعملوا في قذائف:

• = يمكن قراءته كـ page is a customer مقابل =customer . يمكنك حتى تشويهها عقليًا لتصبح القولون ممدودًا للتو ، وبالتالي تشبه الشكل الأكثر شيوعًا للمعلمات المسماة.
• @ لأنه يقرأ جيدًا إلى حد ما. a customer مقابل @customer

قد يكون الخيار الآخر هو استخدام الأقواس المتعرجة (ما لم تكن أحرفًا محجوزة في بعض أنظمة الملفات). يعتبر بناء جملة المعلمة هذا أيضًا "حالة التقنية الصناعية السابقة" ويتم استخدامه بواسطة العديد من أجهزة التوجيه الأخرى:

pages/
├── {root}.js
├── blog/
│ └── {id}.js
├── customers/
│ ├── {customer}/
│ │ ├── {post}.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

سيسمح هذا بوجود معلمات في منتصف مقطع المسار ومعلمات متعددة لكل مقطع حيث أنه من الواضح مكان بدء المعلمة وأين تنتهي ، على سبيل المثال /product-{productId}-{productColor} .

متحمس جدًا لأن المسارات الديناميكية تأتي إلى Next.js!

فيما يتعلق بصياغة المعلمات المسماة ، هذا شيء تمت مناقشته على Spectrum: https://spectrum.chat/next-js/general/rfc-move-parameterized-routing-to-the-file-system~ce289c5e-ff66 -4a5b-8e49-08548adfa9c7. قد يكون من المفيد استخدام ذلك كمدخل للمناقشة هنا. أنا شخصياً أحب الطريقة التي يقوم بها Sapper باستخدام [brackets] . هذا أيضًا شيء ستقوم Nuxt بتنفيذه في الإصدار 3. وجود أطر عمل مختلفة تستخدم نفس التنسيق للمسارات الديناميكية القائمة على نظام الملفات يبدو أمرًا جيدًا.

فيما يتعلق باستخدام <Link /> ، أعتقد أن المطورين سوف ينسون بسهولة تعيين السمتين href و as . أدركت أنه من غير الممكن "دمج" هذه في السمة href لأنها ستحدث تغييرًا مفاجئًا ، لكنني أشعر أنه يمكن حلها بطريقة أكثر أناقة.

يتم استخدام الأقواس المتعرجة للأسف بواسطة Bash لتجميع الأوامر.

أتفق مع @ stephan281094 بخصوص استخدام <Link /> ، سيكون مصدر أخطاء.

يُعد التوجيه الديناميكي ميزة مفيدة للغاية ، لذا من الرائع حقًا أن أطلعتم عليه يا رفاق وتوصلوا إلى حل ، دعائم ضخمة!

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

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

نظرًا لتعارض $ مع متغيرات shell ، فأنا شخصياً أعارضها بشدة.

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

يبدو أن : هو حرف محظور في Windows ، لذا فهو على الأرجح غير آمن. استخدام _ ليس مثاليًا أيضًا ، حيث يمكن استخدام الشرطات السفلية في عناوين URL. السبب في أنني أعتقد أن [brackets] هو حل جيد ، لأنه دليل مستقبلي أكثر. إذا أراد Next.js دعم مسارات مثل post-12345 في المستقبل ، باستخدام بناء الجملة هذا يمكن القيام به دون إدخال تغيير جذري.

لذا فإن قائمة الشخصيات التي يجب تجنبها ستكون:

• التعارضات مع أنظمة الملفات: : ، * ، " ، < ، > ، |
• التعارض مع متغيرات الصدفة: $
• تتعارض مع توسيع قوس bash { ، }

أي شيء آخر؟

لن يلغي هذا حاجتنا إلى ملف مسار مركزي لسببين:

• لدينا خريطة موقع تم إنشاؤها تلقائيًا ، ونظام الملفات وحده لا يكفي لتعريفها.
• استخدمنا المسارات المسماة ويتم تحديد "الصفحات" الوجهة بالبيانات ، بدلاً من شيء يمكن معرفته في وقت الإنشاء. المنطق لمعرفة الصفحة المراد تحميلها بناءً على الاسم والمعلمات مدفوع بتكوين المسار.

نقوم أيضًا بإنشاء مجلد صفحاتنا للأسباب التالية:

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

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

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

لقد قمت بمراجعة بعض حالات الاستخدام الخاصة بي في مكان آخر: https://gist.github.com/AndrewIngram/8d4c4ccd9bd10415a375caacade9f5ca

الشيء الرئيسي الذي لا أراه هو دعم المعلمات الضمنية التي لم يتم التعبير عنها في نظام الملفات ، على سبيل المثال تجاوزات URL.

لنفترض أن لدينا عنوان URL مثل هذا:

/some-vanity-url/

حيث في مصطلحات Next.js الحالية ، نرغب في تعيينها إلى صفحة منتج تحتوي على عدد من معاملات الاستعلام ، على سبيل المثال Product.js?id=foo&language=en

وبالمثل ، فإن معظم "مواقع" البلدان على موقعنا يتم تحديد نطاقها بواسطة شريحة من المستوى الأعلى ، مثل es أو ie ، لكن موقع gb مثبت بدون هذا المقطع. هذا يعني أن جميع صفحات gb تحتوي على معلمة country ضمنية ، في حين أنها صريحة في جميع البلدان الأخرى.

الجانب السلبي الآخر ، هو أنه في حالتنا ، يمكن أن توجد "الصفحة" نفسها عند نقاط تثبيت متعددة في بنية عنوان URL ، سننتهي بعدد أكبر من الحزم (أي عدة نقاط دخول مكررة) أكثر مما نحن في الواقع تحتاج في الممارسة.

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

أنا أؤيد اقتراح {id} . إنها تسمح بمعلمات متعددة وأعتقد أنها تبدو أفضل كثيرًا. كما أنه يتناسب بشكل أفضل مع React.

أنا أؤيد الحرف file/&param.js . مأخوذة مباشرة من عناوين url ولا يبدو أنها تتعارض مع أنظمة الملفات أو bash.

سأستخدم _ وربما أسمح بتجاوز في next.config.js لأولئك الذين يحتاجون حقًا إلى شيء مختلف.

نقدر العمل على هذا. كنت تريد ذلك لفترة من الوقت! ❤️

رائعة حقا! 🎉🎉🎉

مشكلتي الوحيدة هنا هي أن Link يحتاج إلى معلمات href و as .

أعتقد أنه يمكننا كتابة <Link to="blog/123" /> : نظرًا لأن Nextjs تعرف بالفعل جميع المسارات استنادًا إلى الملفات الموجودة في مجلد الصفحات ، فيمكن ترجمتها بسهولة إلى "/blog/$id" .

لذا فإن قائمة الشخصيات التي يجب تجنبها ستكون:

& هو عامل تحكم في bash يدير الجانب الأيسر من الوسيطة في مجموعة فرعية غير متزامنة. نص عادي: سيتم تشغيل open pages/&customer open pages/ في الخلفية والأمر customer في الغلاف الأمامي.

هذا يبدو رائعًا حقًا.

يبدو أن هذا سيؤدي إلى إنشاء عدد كبير من أدلة الملفات الفردية (مثل /blog/$id في المثال الأصلي). يصبح هذا الأمر أكثر تعقيدًا إذا كنت تريد اثنين من معاملات المسار اللاحقة (مثل /git/compare/$hash1/$hash2 ).

لا أحب أيضًا أن يكون اسم الملف الخاص بنسخ منشور مدونة هو $id.js . إن تسميته blog.js سيكون أكثر وصفيًا.

ربما تتحد مع مصمم الديكور @customRoute ؟

// pages/blog.js
import {useRouter, @customRoute} from 'next/router'

@customRoute('/blog/:id')
function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

export default BlogPost

يبدو أن هذا يوفر حلاً أنظف للمعلمات الشاملة المقترحة أيضًا.

لا يمكن تطبيق الديكور على الوظائف (ربما تغير هذا منذ أن قرأته آخر مرة؟) وربما يكون الاقتراح بعيدًا على أي حال

حسنًا ، لنفترض أنك تسير في هذا الطريق ، فمن المحتمل أن تفعل ذلك بالطريقة التي يتم بها تهيئة AMP الآن:

// /pages/blog.js
export const config = {
  amp: true,
  dynamicRoute: true // adds a [blog] property to the query object
  // dynamicRoute: /\d+/ // could even support regex if you want
};

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

من فضلك ، تأكد من استخدام شخصية صديقة مع حلول بدون خادم! (في Aws ، هناك بعض الشخصيات التي يمكن أن تسبب مشاكل)

لا أكره تصدير كائن تكوين بمفتاح مكون.

يمكنك أيضًا استخدام المكوّن الإضافي

function BlogPost(props) {
    return <div />
}

export default withCustomRoute(BlogPost, "/blog/:id")

ماذا لو أضفنا بعض الحقول الثابتة إلى الصفحة (مثل getInitialProps)؟

// pages/blog.js
import {useRouter} from 'next/router'

function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

// By default it would be as it is now
BlogPost.route = '/blog/:id';

export default BlogPost

@ dmytro-lymarenko ماذا يحدث عند الانتقال إلى /blog في المتصفح؟ أ 404؟

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

كنت بحاجة إلى شيء يمكن تحليله بشكل ثابت. لن تكون الخاصية الثابتة أو ذات الترتيب الأعلى

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

ماذا يحدث عند الانتقال إلى / blog في المتصفح؟ أ 404؟

kingdaro - IMO ، نعم. إذا كنت تريد استخدام كلا المسارين /blog و /blog/:blogId ، فأنت تستخدم الدليل. أنت تفرط في تحميل هذا المسار ، لذا فإن بنية الدليل لها ما يبررها.

pages/
├── blog/
│ ├── $id.js
│ └── index.js

مراجعة سريعة لجميع خيارات الشخصيات المذكورة حتى الآن:

حسب ترتيب الظهور

شار | عيوب
--- | -
$ | تعتبر علامات الدولار في أسماء الملفات فكرة سيئة لأنها تستخدمها الأصداف كعنصر سيجيل
_ | عادة ما يشير إلى طريق داخلي
= |
@ | عامل splat في بوويرشيل
{...} | يستخدمه Bash لتجميع الأوامر
[...] | إنشاء اسم الملف في zsh
: | ليس اسم ملف صالحًا
& | هو عامل تحكم في bash يدير الجانب الأيسر من الوسيطة في قشرة فرعية غير متزامنة

حسنًا ، لنفترض أنك تسير في هذا الطريق ، فمن المحتمل أن تفعل ذلك بالطريقة التي يتم بها تهيئة AMP الآن:

// /pages/blog.js
export const config = {
  amp: true,
  dynamicRoute: true // adds a [blog] property to the query object
  // dynamicRoute: /\d+/ // could even support regex if you want
};

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

أعتقد أن استخدام config هو فكرة سيئة لأنك تحتاج إلى المرور عبر ملفات متعددة ، لمعرفة ما هو ديناميكي بالفعل. إذا قمت بتعيينه في نظام الملفات ، يمكنك رؤيته من النظرة الأولى.

أتساءل عما إذا كان يجب وضع أكثر من حل توجيه قياسي واحد في الاعتبار.

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

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

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

لا أكره تصدير كائن تكوين بمفتاح مكون.

يمكنك أيضًا استخدام المكوّن الإضافي

function BlogPost(props) {
    return <div />
}

export default withCustomRoute(BlogPost, "/blog/:id")

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

كان تفكيري الأصلي مع اقتراح تهيئة محلية (في الملف) مقابل تكوين عالمي ( route.js ) ، هو معالجة السيناريوهات المحددة المذكورة في تعليقي الأول (الملفات المتداخلة بشدة والتي هي الملف الوحيد في دليلهم ، أسماء الملفات غير الدلالية ، و catch-all-params).

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

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

merelinguist لا أعتقد أن = محظور في Windows كما كتبته في جدول الملخص. أنت تعيد الارتباط بكيفية حظر : ، ولكن وفقًا لمستندات تسمية ملفات Microsoft Windows ، يُسمح بالحرف المتساوي.

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

سؤال محدد ، هل ستدعم ميزة @ canary API الجديدة

{ path: '/api/:customer', page: '/api/$customer/index.js' }

لقد جربته للتو مع [email protected] وحصلت على 404 غير موجود ، لذلك أظن أنه لم يتم العثور عليه بعد. يبدو أنه من المنطقي أن يكون لهاتين الميزتين (API + المسارات الديناميكية) تكافؤ في توجيه URL.

remy لم يتم تنفيذه بعد ، إنه

يجب أيضًا ألا نأخذ في الاعتبار أنظمة Windows و Linux فحسب ، بل أنظمة أخرى أيضًا:
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations

أود إضافة المزيد من المعلومات حول اقتراحي:

ماذا لو أضفنا بعض الحقول الثابتة إلى الصفحة (مثل getInitialProps)؟

// pages/blog.js
import {useRouter} from 'next/router'

function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

// By default it would be as it is now
BlogPost.route = '/blog/:id';

export default BlogPost

1. لا يمكن للمطور استخدام متغير وقت التشغيل لخاصية المسار هذه

const route = `/blog/${somethingElse}`;
BlogPost.route = route; // is not allowed

1. عندما نبني بيان الصفحة باستخدام RFC الحالي (حيث يحتوي المجلد على بعض الأحرف لتحديدها ديناميكيًا) لا أرى الفرق إذا قمنا ببناء بيان الصفحة هذا بقراءة الملف والعثور على خاصية المسار الثابت على الصفحة. بنفس الطريقة التي يعمل بها lingui : لا يسمحون لمعرف Trans أن يكون ديناميكيًا

<Trans id="msg.docs" /* id can only be static string */>
   Read the <a href="https://lingui.js.org">documentation</a>
   for more info.
 </Trans>

بالانتقال إلى قائمة البادئات المدرجة بالفعل - أتساءل عما إذا كان هناك أي سبب قوي _not_ لاستخدام بادئة رمز @ ؟

أشك إذا كانت ذات قيمة ، لكنك تحصل على التكافؤ مع Nuxt - مما يعني أن شخصًا ما يتحول من أحدهما أو الآخر سيعرف على الفور كيف يعمل.

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

مجرد فكرة.

متابعة لاقتراحremy ، لماذا لا تفتح واجهة برمجة التطبيقات (API) بالكامل لكيفية قيام Next بتوزيع المسارات من نظام الملفات. منح المستخدمين قدرًا كبيرًا (أو قليلاً) من المرونة كما يحتاجون ، وإلهام حلول توجيه موثوقة من جهات خارجية.

@ scf4 كان لدي مكتبة وهي PoC ، والتي تستخدم now.json مسارات التكوين للقيام بالتوجيه العام مع nextjs هنا أيضًا

آمل أن يقوم فريق Zeit أيضًا بفتح المصدر محلل المسار في مكتبة جانب العميل أيضًا.

بالنظر إلى Nuxt ، أعتقد أن _id.js ليس سيئًا للغاية. نعم ، نحن بالفعل نستخدم _app و _document.js كما ذكرت وهو غير قابل للتوجيه بشكل عام. ولكن يمكن أيضًا اعتبار المسار الديناميكي على أنه غير قابل للتوجيه لأن هذا نموذج للعديد من الصفحات

كيف سيتم التعامل مع هذا لتصدير الموقع الثابت؟

(لا تهتم بهذا)

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

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

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

@ scf4 Next.js لديه بالفعل القدرة على القيام بتوجيهات معقدة باستخدام خيار الخادم المخصص. ما تقترحه يتم تحقيقه تقريبًا بنفس المقدار من التعليمات البرمجية باستخدام الأدوات المتاحة بالفعل.

آه نعم ، عادل بما فيه الكفاية.

أعتقد أن وجود ملف مسارات واحد يمكن تحريره هو خيار أفضل بكثير على أي حال!

لقد كتبت بعض الأفكار حول التوجيه باستخدام نظام الملفات ، لكن يمكنني تلخيص النتائج التي توصلت إليها هنا:

• [param] الأكثر أمانًا (ويستخدمه Sapper).
• : مألوفًا لمستخدمي Express ، لكن كان بإمكاني أن أقوم بالإحزام_ واجهت مشكلات في Windows FS.
• $ و {param} للمتغيرات وتوسيع الدعامة في الصدفة ، لذلك قد يكون هذا أكثر إشكالية عندما تكون في CLI.
• _ _could_ ، ولكنه شائع جدًا كمؤشر "خاص".

لقد حصلت شخصيًا على تجارب أفضل مع ملفات القائمة البيضاء للمسارات ( /^index\. ) مقابل القائمة السوداء ( /^_/ ) ، لكن هذا سيكون مشكلة توافق عكسي مع /pages .

مع المناقشات الأخيرة لدعم مسارات API (# 7297) ، قد تكون هذه فرصة لدعم /api و /pages كلاهما تحت منزل جديد /routes .

ومع ذلك ، فهو نظام "مع ذلك" قوي ، فإن النظام البيئي Next.js كبير بما يكفي لضمان إضافات ميزة إضافية ، مقابل "مهلا ، إذا كان علينا القيام بذلك مرة أخرى ، فسنقوم بذلك _هذا_ الطريقة".

يتم استخدام الأقواس المربعة ( [example] ) بواسطة zsh لمطابقة الأنماط ، لذلك لن يكون ذلك قابلاً للتطبيق أيضًا.

شاهد أمثلة في إنشاء اسم الملف

يتم استخدام الأقواس [] بواسطة zsh لمطابقة الأنماط ، لذلك لن يكون ذلك قابلاً للتطبيق أيضًا.

يبدو أنهم صنعوها للتو في https://github.com/zeit/next.js/pull/7623

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

لقد جربت [id] واستخدامه فقط في المسارات هو ألم (على سبيل المثال cd \[id\]/view.js ). يبدو لي أن الخطوط السفلية المزدوجة __id (على سبيل المثال cd __id/view.js ) تعمل أيضًا بشكل جيد ويمكن تمييزها (قد يكون الألبوم محيرًا بعض الشيء) من الملفات / المجلدات الداخلية (على سبيل المثال _app.js ).

AaronDDM هل تستخدم zsh ؟ لا تحتاج إلى الهروب من [ أو ] في bash.

نعم ، يحدث هذا أيضًا مع zsh - مزعج للغاية للتفاعل مع هذه الدلائل.

$ mkdir [asdf]
zsh: no matches found: [asdf]
$ mkdir \[asdf\]
$ cd [asdf]
zsh: no matches found: [asdf]
$ cd \[asdf\]

وبما أن zsh سيصبح غلافًا افتراضيًا في macOS Catalina ، فربما ينبغي فعل شيء حيال هذا بعد كل شيء ...

أتفق مع __id.js

حسنًا ، لا أحب حقًا __ ، فقط لا يبدو رائعًا بالنسبة لي.

merelinguist em ، استخدم __tests__ لمجلد الاختبار الافتراضي ، أعتقد أن __ منطقي في بعض الحالات.

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

1. معقول ، افتراضي عبر الأنظمة الأساسية ، مثل =
2. الخيار في next.config.js لتخصيص حرف المسار الخاص المستخدم
3. توثيق الشخصيات التي تمثل مشكلة في أي مواقف

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

لاحظ أيضًا = محجوز بواسطة zsh. من المستندات :

إذا بدأت الكلمة بعلامة '=' غير مقتبسة وتم تعيين خيار EQUALS ، فسيتم أخذ باقي الكلمة كاسم للأمر. في حالة وجود أمر بهذا الاسم ، يتم استبدال الكلمة باسم المسار الكامل للأمر.

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

هذه تعمل في zsh و bash دون الحاجة إلى الهروب ، حتى الآن:

[email protected]
example~.js
example=.js

أوه. ليست لاحقة ولكنها طريقة للإشارة إلى معلمات URL اللاحقة.

لذا فإن [email protected] يصبح blog/:id .

يصبح compare@[email protected] compare/:a/:b .

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

لا يبدو الأمر خياليًا ، ولكن ماذا عن شيء على غرار:

/blogs/_var_blog-id/index.js
/blogs/_var_blog-id.js

البادئة _var_ أي نوع من يحاول تقليد تعريفات متغير JS. أم أنه يجب أن يكون شيئًا قصيرًا للغاية من شخصية واحدة؟

ماذا عن ~ حرف؟

مثل /blogs/~id .

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

لا يمكن اعتبار أي حرف لا يتطابق مع [0-9a-zA-Z-._] (regex) آمنًا كبادئة عبر أنظمة التشغيل والأصداف وأنظمة الملفات.

بعض الأحرف ليست مضمنة آمنة أيضًا. انظر مستندات zsh

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

• يبدو استخدام الأقواس مقابل [params].js أكثر أناقة واستخدامًا على نطاق واسع. (sapper ، nuxt v3؟).
• عادة ما تكون بادئة الشرطة السفلية pages/_helper.js لوظيفة خاصة وربما لا يجب عرضها. هذا يسمح لنا بإنشاء مكونات مساعدة داخل مجلد الصفحات

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

mmahalwy ضرب المسمار على الرأس.

يُنشئ Next.js بالفعل تهيئة المسارات (بناءً على نظام الملفات). أعتقد أن جعل هذا التكوين أكثر وضوحًا و / أو السماح للمستخدم "بإخراجه" إذا رغب في ذلك سيكون الحل الأكثر سلاسة هنا

mmahalwy @ scf4 FWIW ، المبرر المهم لمسارات نظام الملفات هو إزالة الحاجة إلى وجود ملف مركزي. في الواقع ، يمكن للمرء أن يجادل بسهولة بأن واجهة برمجة تطبيقات Next.js الكاملة للروابط والتوجيه مصممة حول هذا القيد.

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

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

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

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

لذلك كما ذكرت من قبل ، فيما يتعلق بهذا الاقتراح ، يبدو أنه جيد طالما تم بيعه على أنه يحل مشكلة التوجيه تمامًا ، لأن ذلك سيكون مضللًا بعض الشيء :)

AndrewIngram أنا أفهم من أين أتيت ولكن هذا القيد يحد من القوة التي يتمتع بها nextjs. تقدم Nextjs الكثير من خارج الصندوق بحيث لا ينبغي أن يكون هناك تفكير لأي مشروع أو شركة جديدة لاستخدامه. لكن التحدي يكمن في صعوبة الرأي في التوجيه الذي يجعله غير قابل للرفض في المستقبل (وكشركة كبيرة ، فأنت تفكر دائمًا في استراتيجية الخروج في حالة فقدان المشاريع للاهتمام أو الصيانة).

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

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

كل شيء يبدو خارج الموضوع من RFC هذا. لا أعتقد أن أي شخص ، بما في ذلك OP ، قد اقترح أن هذا هو الحل النهائي للتوجيه. هذا فقط يحسن التوجيه القائم على نظام الملفات.

لقد كنت أستخدم المسارات الديناميكية لمشروع صغير خلال الأسابيع القليلة الماضية (باستخدام $ الرغم من أنني لاحظت أنه تم نقله إلى [param] 3 أيام مضت في canary repo ، ولكن على أي حال).

لقد بدأت باستخدام getRequestHandler وأعتقد أنه لا يتم التقاط التوجيه الديناميكي من جانب الخادم.

هل هذا خطأ أم مقصود (مثل بعض التغيير إلى getRequestHandler ) أم شيء آخر أم أن استخدام getRequestHandler إلى إيقاف التوجيه الديناميكي تمامًا (وهو الأمر الذي يبدو منطقيًا الآن أفكر فيه ...) ؟

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

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

كل شيء يبدو خارج الموضوع من RFC هذا. لا أعتقد أن أي شخص ، بما في ذلك OP ، قد اقترح أن هذا هو الحل النهائي للتوجيه. هذا فقط يحسن التوجيه القائم على نظام الملفات.

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

FWIW نستخدم المسارات المستندة إلى FS على غرار [param] في Pinterest (وإن لم يكن التالي). لقد تم تحجيمها جيدًا حتى الآن. أكبر انتقاد هو أن Jest يفسر [] أنه أزواج regexp لذا قد يكون من الصعب استهداف اختبارات معالجات param-ful.

chrislloyd ما هي تجاربك في إنشاء وإدارة الملفات باستخدام هذا التنسيق للمسارات / الملفات في بيئات مختلفة ، مع الأخذ في الاعتبار أن أي شخص يستخدم zsh ، أو أداة تفسر هذه بشكل مختلف؟

نظرًا لأن [] يستخدم لمطابقة الأنماط في zsh (وكما تقول مع Jest) ستحتاج إلى الهروب من هذه المسارات. هذه ليست مشكلة كبيرة إذا كنت تعرف هذا ، ولكن بالنظر إلى أنه يجب أن يكون قابلاً للاستخدام ومفهومًا من قبل المبتدئين ، فإن لدي شكوك في أن هذا هو الشكل الصحيح المناسب.

لدي فكرة عن استخدام ! كمعامل مطلوب ، مثل /pages/id!.js و ? للمعلمة الاختيارية ، كما في /pages/posts/id?.js .

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

لا يسمح Windows بعلامات الاستفهام في أسماء الملفات ، وكلاهما؟ و! لها معنى خاص في باش.

تدعم مسارات API الآن المعلمات الديناميكية # 7629 🚀

من المتوقع أن يتعامل getRequestHandler مع التوجيه الديناميكي - لقد أكدت للتو أنه يفعل ذلك محليًا. هل يمكنك تقديم خطأ / مشكلة منفصلة مع خطوات الاستنساخ حتى نتمكن من التحقيق؟ :صلى:

مرحباً بالجميع! شكرًا للاستجابة الرائعة لهذا RFC.

تم تنفيذ طلب التعليقات هذا وإصداره باعتباره مستقرًا في Next.js 9.
يمكنك قراءة المزيد عنها في منشور المدونة .

سننشر RFC جديدًا في المستقبل للتعامل مع جميع التعليقات المتقدمة الواردة هنا. سننشر تحديثًا هنا عندما يكون متاحًا.