Next.js: [RFC] دعم CSS

أظن أن المكونات الإضافية مثل @zeit/next-sass تعمل بالفعل مع النكهة الحالية المدعومة لوحدات CSS التي ستعمل أيضًا .module.scss ؟ أم أن عبارة "وحدات CSS الخالصة" تعني .module.css ؟

دعم Sass هو تحقيقه أو كسره لمعظم المشاريع بالنسبة لي.

سيتم إهمال المكونات الإضافية @zeit/next-css/sass/less/stylus لصالح RFC (دعم مدمج). ما زلنا نناقش إلى أي مدى سيكون sass جزءًا من النواة مقابل المكون الإضافي. تفكيري الحالي هو أنه عندما تضيف node-sass فإنه سيمكن دعم sass. على غرار ما نفعله مع TypeScript. السبب في أننا لن نضيفه كتبعية هو أنه كبير جدًا وبطيء جدًا في التثبيت بسبب الارتباطات الأصلية وما إلى ذلك.

هذا محمس! لقد تعثرت بسبب أسماء فئات css المتضاربة كما هو الحال اليوم!

سؤال ، كيف يعمل مع TypeScript؟ أحد أسباب عدم تمكين وحدة css هو أن استيراد وحدة css سيعطي أي كائن (ربما يكون شيء سحري بعض الشيء ، مثل .foo-bar سيصبح حقلًا يسمى fooBar ؟) ، وهي ليست ودية TS. نظرًا لأن Next هو TS الآن افتراضيًا ، أتخيل أنه يمكننا القيام بعمل أفضل في هذا الأمر؟

لست متأكدًا مما إذا كانت "الإصلاح التلقائي للأخطاء المرنة المعروفة للمستخدم" ستكون فكرة جيدة.

أخشى أننا سننتهي في سيناريوهات مربكة حيث تتصرف مكتبات مكونات الطرف الثالث في npm ، والتي تتضمن أوراق أنماط css ، بشكل مختلف في بيئات nextjs عن غيرها (مثل create-reaction-app).

TheHolyWaffle إصلاح

zenozen حسب مواصفات CSS Modules ، فإنه لا يفعل أي شيء خيالي بالنسبة لك. إذا كنت تستخدم أسماء الفئات مع شرطة ( class-name ) ، فستحتاج إلى الوصول صراحةً إلى ذلك على الكائن.

على سبيل المثال

import Everything from './file.module.css'

// later on

Everything['class-name']

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

declare module '*.module.css' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.scss' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.sass' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

مهما فعلنا هنا ، يمكننا التأكد من أنه لا يزال من السهل استخدام مكونات PostCSS المخصصة كما هو الحال الآن مع @zeit/next-css ؟ سيكون عارًا حقيقيًا إذا فقدنا الدعم لذلك - CRA لا تدعم هذا وبسبب ذلك من المستحيل استخدام أدوات مثل Tailwind CSS بأي طريقة معقولة.

سأكون حذرا بشأن هذه الميزات الثلاث في هذا الصدد:

• استخدم Autoprefixer لإضافة بادئات خاصة بالبائع تلقائيًا (بدون دعم Flexbox القديم)
• Polyfill أو تجميع ميزات Stage 3+ CSS مع ما يعادلها
• إصلاح الأخطاء المرنة المعروفة تلقائيًا للمستخدم

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

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

TL ؛ DR يرجى الحرص على عدم كسر قدرة المستخدمين على التحكم الكامل في PostCSS ، فأنا حرفياً لا يمكنني استخدام CRA بسبب هذا وسأكون حزينًا للغاية إذا لم أتمكن من استخدام التالي بعد الآن.

Secondingadamwathan - سيكون من الرائع الحصول على مزيد من التفاصيل هنا حول كيفية ظهور تخصيص خيار postcss. سيكون من الرائع حقًا أن يكون لديك خيار لتعديل تهيئة postcss عبر المكون الإضافي التالي بالإضافة إلى postcss.config.js ، بحيث يمكن إدخال التكوينات المشتركة عبر مشاريع متعددة بسهولة دون ملف إضافي.

أعتقد أنه من الأفضل تمكين وحدات css لجميع عمليات استيراد css (ليس فقط لاحقة .module ) ، والتي نريد أن تكون عالمية سنحتاج إلى تحديد لاحقة .global .

وحدات CSS ستكون رائعة. أعتقد أن الاحتفاظ بالمواصفات *.module.(css|scss) أمر جيد لأنه يتوافق مع create-react-app ، ويسمح بالكتابة المطبوعة ، ويسمح بعمليات ترحيل أسهل للمستخدمين الآخرين الجدد على Next.js

باستخدام typecript ، يمكنك فرض كتابة وحدات CSS عن طريق إنشاء كتابات *.d.ts لكل ملف *.(css|scss) باستخدام وحدات typed-css-modules و typed-scss-modules ولكن إذا كنت لا تريد القيام بذلك و ما زلت تريد الإكمال التلقائي ، يمكنك استخدام امتداد VS Code التالي:
https://marketplace.visualstudio.com/items؟itemName=clinyong.vscode-css-modules

تطمئن adamwathan أننا سنسمح بتهيئة PostCSS! لسنا متأكدين من الشكل الذي سيبدو عليه تنفيذ _exact_ حتى الآن ، ولكن يجب أن يظهر بشكل طبيعي مع طلب سحب CSS.

هذا عظيم!! هل هناك جدول زمني لهذا؟ هل يحدث هذا العام؟

andreisoare نحن على وشك دمج النصف العالمي من RFC هذا: https://github.com/zeit/next.js/pull/8710

سنستمر في دعم وحدات CSS في أسرع وقت ممكن!

سوفadamwathanTimer يكون رائعا لو تمكنا من الاستمرار في استخدام ملف postcss.config.js التقليدية في جذر المشروع، ما في وسعنا الآن مع next-sass .

سعيد جدا لرؤية هذا يتحول إلى جوهر.

هل سيتم دعم عرض المسار الحرج لصفحات AMP بواسطة RFC هذا؟

للسجل ، إذا استطعت ، يجب عليك استخدام style-jsx لأنه يسمح لك بتغليف css و html و js في فكرة واحدة ، مكون. إذا لم تكن قد أدركت هذا بالفعل (هذه ملاحظة لمستخدمي next.js وليس المشرفين) ، فهذا يسمح لك بعدم الاضطرار إلى الشراء في مجموعة CSS UI Kit مثل bootstrap ، يمكنك تجربة مكون واحد وإذا لم يكن كذلك لا يناسب احتياجاتك ، فأنت ترميها دون عبء التعامل مع عبء تلك التبعية الخارجية لـ CSS.

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

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

أعتقد أن أحد أقوى الأشياء حول التفاعل هو حقيقة أنه يحتوي على CSS و HTML و JS من أجلك. وإذا قمت بتحميل جانبي (استيراد) CSS ، فأنت نوع من الخطوة الجانبية التي تمنحك الاستفادة من التفاعل.

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

للتسجيل: ابتسم :: استخدام SASS ، LESS مع إطار مثل Bootstrap لا يزال شيئًا ويعمل بشكل رائع حقًا! يجب ألا يحدث التغليف على مستوى JS. استخدام BEM هو بديل. دعم كلا الاتجاهين ضروري.

timer هل النصف الأول من هذا (https://github.com/zeit/next.js/pull/8710) يعني أن تقسيم مسار CSS يعمل الآن؟ أم أن هذا لم يأت بعد؟

(ذات صلة ، https://github.com/zeit/next-plugins/issues/190)

لا يمكن تقسيم المسار العام لـ CSS ، لذا لا. فقط وحدات CSS النمطية (المستوردة على مستوى المكون) سيتم تقسيم المسار. 👍

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

مرحبا. نحن نتطلع إلى ترقية تطبيق React الخاص بنا إلى next.js في الغالب للاستفادة من الأدوات الرائعة وعرض جانب الخادم.

ومع ذلك ، فمن الصعب بالنسبة لنا أن نكون قادرين على استخدام وحدات CSS. لقد حاولنا مع المكون الإضافي التالي لـ CSS ولكن ذلك دمر الخراب بمشاكل مثل # 9392 # 9385 والمزيد.

هل هناك أي وقت متوقع لوحدات CSS (حتى التجريبية)؟ أي طريقة للمساعدة في تسريع تطويره؟

إذن لا يمكننا استيراد css على مستوى المكون؟

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

آسف على السؤال الغبي: بقدر ما يذهب CSS العالمي ، كيف يكون هذا مختلفًا / أفضل من مجرد تضمين رابط في الرأس؟

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

يعتمد عليك إذا كانت هذه ميزة. أتخيل أن معظم الناس يتطلعون إلى وحدات CSS بحيث يتم تحميل CSS اللازمة لمكون معين فقط عند تحميل المكون.

بالنسبة للسياق ، لدينا فريق من المطورين الذين استخدموا NextJS على مدار العامين الماضيين لبناء ما يقرب من 40 تطبيقًا على الويب للشركات الناشئة في مراحلها الأولى.

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

التنفيذ الحالي

• نحتفظ بتطبيق "مجموعة المبتدئين" الذي يحتوي على الكثير من وظائف التطبيق الأساسية التي تم إنشاؤها مسبقًا. يتم استنساخه كنقطة بداية لأنه يحتوي على الكثير من الوظائف الممتدة من مجرد استخدام Bootstrap.
• نحن نستخدم Bootstrap و Reactstrap كأساس لنظام التصميم الخاص بنا. نظرًا لأننا نريد نظام تصميم متماسك ، فإننا نستخدم إرشادات SASS العالمية مع http://prntscr.com/qc8r0g.
• بالنسبة للكثير من مشاريعنا ، يمكننا الحصول عليها من خلال التصميم في الغالب من خلال فئات المرافق التي يوفرها إعداد Bootstrap الموسع ، ولكن هناك استثناءات. لهذه الاستثناءات ، نستخدم المكوّن الإضافي SASS مع style-jsx . سبب استخدامنا للمكوِّن الإضافي SASS هو أننا نستورد متغيرات bootstrap ووظائفنا وخلطاتنا من جلوبال لدينا للحفاظ على تماسك نظام التصميم. لقد قمنا باستيراد خاص يسمى "jsx-helper" يقوم بإحضار هذه العناصر إلى style-jsx. لقطة الشاشة: http://prntscr.com/qc8xbr.
• في حالة بعض مكونات التخطيط التي تحتاج إلى لمس علامات html و body و root div ، أو بعض المكونات الإضافية التي تنشئ ترميزًا خاصًا بها ، أو npms التي تستخدم البوابات وتحتاج إلى CSS للمس الترميز الذي لا يمكن الوصول إليه من المكون ، نستخدم الخيار العام المصمم -jsx. هذا هو الملاذ الأخير ولكنه مطلوب لمكون التخطيط لدينا كما ترى هنا: http://prntscr.com/qc8yo6

العيوب / القضايا الحالية

• نفضل عدم استخدام كود SASS المحقون (مشكلات IDE ونقص الدعم مع اللغات المحقونة) مع مكوناتنا ، لكن خطأ تجميع معروف مع المطلوب الأسلوب npm . يبدو المشروع غير مدعوم في هذه المرحلة ، لذا أوصي بشدة بعدم وجوده في أي سلسلة أدوات مقترحة بواسطة NextJS.
• لم يتم الكشف عن التغييرات التي تم إجراؤها على متغيرات SCSS العالمية التي تم استيرادها إلى style-jsx SASS. في الواقع ، هناك نوع من ذاكرة التخزين المؤقت العامة لوحدة npm لا يمكننا توضيح أنه يبدو أنه يجعل webpack غير قادر على إعادة تحميل التغييرات التي تنتشر من متغيرات Bootstrap العامة الخاصة بنا. عند القيام بكامل npm ci لإعادة إنشاء المجلد node_modules بالكامل ، ومسح ذاكرة التخزين المؤقت للمتصفح ، فإن الأمر clear force console لا يعمل نظرًا لوجود بعض ذاكرة التخزين المؤقت العامة npm للعمل هنا. لذلك نود بشدة إعادة التحميل السريع للعمل بشكل صحيح عند تحديث الملفات المستوردة إلى وحدات CSS / SASS المطبقة على المكونات. باختصار ، أي معالجة SASS تتم بواسطة المكونات يجب أن تراقب التغييرات على الواردات وتحافظ على إعادة التحميل الساخن. كان من الممكن حل هذا من خلال خيار أداة تحميل حزمة الويب المذكورة في الرمز النقطي السابق.
• كان علينا التوصل إلى حل لمشاركة تكوين PostCSS الخاص بنا في مكانين منفصلين حيث تم إنشاء SASS و style-jsx بشكل منفصل.

مخاوف بشأن التغييرات المقترحة

نحن مهتمون بشكل معتدل بفكرة حظر الخيار العام بوحدات CSS / SASS المكونة لأن لدينا بعض حالات الاستخدام التي تحتاج ، بناءً على المكون ، إلى لمس علامات html والجسم والجذر div بالإضافة إلى حالات HTML التي تم إنشاؤها هذا ليس ضروريًا داخل المكون المذكور بسبب وضعه عبر بوابات وما إلى ذلك. أعتقد أنه يمكننا حل بعض من هذا باستخدام SASS العالمي وبعض إعادة الهيكلة حتى لا نعتمد على المكون الذي يتم تحميله لتطبيق CSS عالمي معين.

نريد السيطرة الكاملة على PostCSS ونفضل ألا نضطر إلى التعامل مع إجبارنا على تطبيق مجموعة محددة من الإعدادات الافتراضية.

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

Soundvessel ،

نحن مهتمون بشكل معتدل بفكرة حظر الخيار العام بوحدات CSS / SASS المكونة لأن لدينا بعض حالات الاستخدام التي تحتاج ، بناءً على المكون ، إلى لمس علامات html والجسم والجذر div بالإضافة إلى حالات HTML التي تم إنشاؤها لا يوجد بالضرورة داخل المكون المذكور

إذا فهمتك بشكل صحيح ، فلا يزال يتعين عليك تحقيق ذلك باستخدام :global في وحدات CSS.

@ daniellt1

إذا فهمتك بشكل صحيح ، فلا يزال يتعين عليك تحقيق ذلك باستخدام :global في وحدات CSS.

انظر ملاحظتهم أعلاه

يُسمح باستخدام محدد CSS Modules عند دمجه مع اسم فئة محلي

في حالة مكون التنسيق الخاص بنا ، فإننا نستهدف <html> و <body> و root div بدون اسم فئة محلي.

تم ذكره أيضًا في مقطع فيديو حول هذا الموضوع أنهم يفكرون في حظر خيار :global تمامًا وهو أمر غير منطقي بالنسبة لي نظرًا للعدد الكبير من واجهات برمجة تطبيقات npms و CMS التي تنشئ ترميزًا لا يمكن لمسه بواسطة وحدات css المحددة النطاق.

مرحبًا Soundvessel - هذا هو الفيديو الخاص بي الذي قمت بتسجيله داخليًا لفريقي (كيف تمكنت من الوصول إلى هذا؟) ، ولا يمثل بشكل مباشر مشاهدات فريق nextjs ، كما أنه لا يضمن تحديث المعلومات منذ إنشائه خلال المراحل التجريبية المبكرة. اعتبر RFC أن يكون الشريعة في هذا الموضوع 😁

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

فقط أريد أن أضيف ، ما لم فاتني بعض الإشارة أعلاه ، أن الاكتشاف التلقائي / التمكين لـ Sass رائع ، لكن خيارات Sass API تحتاج إلى الكشف عنها في مكان ما أيضًا: أنشأ [email protected] نمطًا جيدًا بما في ذلك السماح يختار المستخدم أي محرك ساس لتطبيقه ؛ يمكن اتخاذ خياراتهم على مدى 1: 1 ...

أود أن أقترح أن يكون امتداد وحدات CSS النمطية قابلاً للتكوين.
ربما يعرض مصفوفة لدعم أكثر من امتداد غير .module.css ؟
يبدو أن إنشاء ملف .module.css واستيراده import "Component.module.css" عندما يكون لديك العديد من المكونات لبعض المطورين أمر مبالغ فيه بعض الشيء.

في حالتي ، أود أن أتمكن من إنشاء ملف بامتداد: .m.css ، قل Component.m.css واستيراده كـ import "Component.m.css"

ما لم يذكر فريق Next.js أن هناك بعض الصعوبات التقنية التي تحول دون القيام بذلك.

لا أعتقد أنه يجب فتح أي تكوين لملحقات التسمية لأن ذلك يبدو وكأنه زيادة غير ضرورية في البصمة ، لكنني أشكك في _need_ للامتداد .module.css إذا كان هذا سيكون جزءًا من التنفيذ:

سيسمح لك Next.js فقط باستيراد Global CSS ضمن صفحات مخصصة / _app.js.

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

هل يتم فرض هذا على أنه مجرد اتفاقية وليس مجرد حاجة؟

يتعارض اختيار اتفاقية module.css مع الدير الذي أنشأه بالفعل https://github.com/css-modules/css-modules
أمثلة هنا:
https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/
و هنا:
https://www.gatsbyjs.org/docs/css-modules/

نعم ، ربما يؤدي جعل الامتداد قابلاً للتكوين إلى تعقيده أكثر من اللازم. لكن على الأقل يمكنك تحديد .module.css في ملف ثابت وليس مشفرًا في عدة أماكن لتغييره عن طريق الترقيع القرد

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

الفرق بين هذا التنفيذ المقترح و create-react-app هو أن استيراد "ورقة أنماط عادية" مثل المثال الذي ربطته بـ another-stylesheet.css لن يُسمح به على الإطلاق. في هذا المثال ، يتم استخدام .module.css لتحديد ورقة الأنماط التي يجب التعامل معها بأي طريقة بواسطة أدوات الإنشاء.

لا تؤسس مواصفات وحدات CSS النمطية اصطلاح تسمية على الإطلاق.

أعلم أن CSS Modules لا تؤسس أي اصطلاح على امتداد الملفات ولكن كيف يتم استيراد الوحدات.

ما أريد أن أذهب إليه هو أن .module.css هو الاصطلاحات التي اختارتها فرق Next.js ويجب عليهم "تسهيل" إمكانية تغيير بعض المستخدمين حتى لو كان ذلك عن طريق وحدة ما بعد التثبيت التي تعمل monkey patching

أعتقد أن .module.css هو أول اصطلاح تسمية |

يتعارض اختيار اتفاقية module.css مع الدير الذي تم إنشاؤه بالفعل بواسطة css-modules / css-modules
أمثلة هنا:
create-react-app.dev/docs/adding-a-css-modules-stylesheet
و هنا:
gatsbyjs.org/docs/css-modules

نعم ، ربما يؤدي جعل الامتداد قابلاً للتكوين إلى تعقيده أكثر من اللازم. لكن على الأقل يمكنك تحديد .module.css في ملف ثابت وليس مشفرًا في عدة أماكن لتغييره عن طريق الترقيع القرد

أنت تتعارض مع وجهة نظرك هنا ، يتم استخدام .module.css بواسطة تطبيق create-react-app و gatsby لنفس الميزة. إنه نمط ثابت.

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

أعتقد أن .module.css هو أول اصطلاح تسمية | التمديد الذي فرضه Next.Js. أرجوا أن تصحح لي إذا كنت مخطئا.

ينشئ Next.js اصطلاحات حول خيارات التكوين ، على سبيل المثال:

• يجري الدليل pages المسارات
• pages/api مسارات API
• دعم .js .tsx .tsx

مرحباtimneutkens

النمط هو كيف يحدد CSS Modules كيفية استيراد ملفات CSS إلى كائنات JS ، واسم CSS المعني هامشي. في هذا الصدد ، لا يستخدم Next.js هذا النمط المحدد مع التنفيذ الجديد.
تم تنفيذ CSS Modules كما في Gatsby و CRA بالفعل في Next من قبل: https://github.com/zeit/next-plugins/tree/master/packages/next-css

أنا لا أشكك في الاتفاقية المستخدمة ، .module.css ، حتى مع العلم أنه يمكنني الخلط بين مستخدمي CRA و Gatsby وبين CSS Modules . من الصعب اختيار اسم مناسب ولا يسعد الجميع دائمًا.

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

على أي حال ، تهانينا على وحدات CSS. لقد قمت بعمل رائع ، بدت مهمة شبه مستحيلة.

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

أتخيل أن .module.css يدعم postCSS تمامًا كما تفعل ملفات .cs العالمية حاليًا.

أعلم ما يحدث ، أعتقد أنني بحاجة إلى إجازة.

عند مراجعة العلاقات العامة: https://github.com/zeit/next.js/pull/9686 اعتقدت أنني "رأيت" أن وحدات CSS تم استيرادها في نطاق كما يتم استيراد الوحدات النمطية العالمية.

اعتقدت بصدق أنني قرأت هذا الرمز:

index.module.css

.redText {
  color: net;
}

import './index.module.css'

export default function Home () {
  return (
    <div id = "verify-red" className = "redText">
      This text should be red.
    </div>
  )
}

من الواضح أنه لا علاقة له بالواقع. في الواقع الكود الحقيقي هو هذا.

import {redText} from './index.module.css'

export default function Home () {
  return (
    <div id = "verify-red" className = {redText}>
      This text should be red.
    </div>
  )
}

فقط وحدات CSS كما في CRA أو Gatsby. ومن هنا جاء الارتباك والارتباك.

أعتذر للجميع عن الخطأ.

:-(

عند استخدام وحدات CSS ، فإن المشكلة الرئيسية هي:

استخدم CSS Modules في مشروعي ، وبعض مكونات الطرف الثالث تستخدم CSS Modules أيضًا.
لكن ... تستخدم بعض مكونات الجهات الخارجية CSS العالمية.

أعتقد أن حل امتداد .module.css سهل الفهم والتنفيذ.
وقد توصلت الأطر الأخرى (CRA-Gatsby) إلى توافق في الآراء.

حتى الآن ، لم أواجه أي مشاكل حول حل التمديد.
لذلك ، آمل تعزيز تطوير امتداد .module.css .

إذا كان هناك حل آخر لمشكلة وحدات CSS ، فمن الأفضل.

تضمين التغريدة
على الرغم من أن .m.css أقصر ، لكنني لا أعتقد أنه أفضل.
هل هو min.css أم module.css ؟

@ xyy94813 أو العكس تمامًا ، جميع عمليات استيراد css عبارة عن وحدات نمطية ، والملفات التي تحتوي على .global.scss ستكون ملفات عالمية

تضمين التغريدة
لكن ، من غير المناسب للمكونات المنشورة.

أعتقد أن الاتفاقية هي خيار افتراضي جيد ، ولكن يجب إتاحة بعض خيارات التكوين الخاصة بوحدات CSS في النهاية ، على سبيل المثال تلك التي يتم تمريرها إلى css-loader ، حيث سيريد بعض المستخدمين التحكم في كيفية "النطاق" يتم إخراج أسماء الفئات. يمكن إضافة خيار لتوفير regex يحدد ملفات CSS التي يتم تحميلها على أنها "وحدات"

لأن بعض المستخدمين سيرغبون في التحكم في كيفية إخراج أسماء الفئات "المحددة النطاق"

أمثلة لماذا تريد ذلك؟ لا أستطيع التفكير في أي شيء.

أمثلة إذا كنت تريد ذلك؟ لا أستطيع التفكير في أي شيء.

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

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

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

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

عند العمل مع مطوري React الجدد ، وجدت دائمًا أنه من الأسهل بكثير نقل مفهوم أنماط النطاق إلى مكون عبر className. فقط أعط العنصر الخارجي في المكون الخاص بك className فريدًا ، عادةً ما يكون هو نفسه اسم المكون الخاص بك ، واكتب النمط الخاص بك مثل هذا إذا كنت تستخدم SCSS:

.Navbar {
  .logo { ... }
  .nav-item { ... }
}

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

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

ما لم أساء فهم شيء ما ، لا أعتقد أن شيء CSS Modules حصري ، بل سيطبق المُحمل محلل CSS Modules فقط إذا كان الملف الذي تستورده يحتوي على نمط التسمية *.module.css ، أو *.module.scss لذاك السبب

@ lunelson-bl

إنه شبه حصري على عكس كيفية قيام CRA أو Gatsby بتمكين المحلل اللغوي فقط عند استخدام نمط التسمية ، لن يسمح Next بالاستيراد غير المعياري مباشرة إلى مكون JS.

من RFC:

/* components/button.js */
import { btnLarge } from './button.module.css'

// import '../styles.css'; // <-- this would be an error

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

أنا مستخدم جديد لـ next.js. بعد أن قرأت هذا العدد وأشعر ببعض الارتباك. أعتقد أنه إذا كان next.js يدعم build-in-css-support ، لذلك لا نحتاج إلى @ next-css plugin ، لكنه لا يعمل ويظهر خطأ حول "ModuleParseError".
إذا قمت بإضافة @ next-css plugin لإضافة دعم استيراد CSS ، فإنه يعمل ، فكيف build-in-css-support بدون @ next-css ، هل يمكنك تقديم مثال؟
شكرا لكم جميعا.

أنا مستخدم جديد لـ next.js. بعد قراءة هذا العدد وأنا في حيرة من أمري. أعتقد أن next.js يدعم دعم build-css ، لذا لا نحتاج إلى المكون الإضافي @ next-css ، لكنه لا يعمل ولا يظهر خطأ بشأن "ModuleParseError".
إذا أضفته إلى المكون الإضافي @ next-css لإضافة دعم لاستيراد CSS ، فإنه يعمل ، فكيف يمكنك إنشاء css-build بدون @ next-css ، هل يمكنك إعطاء مثال؟
شكرا @ ALL .

أضف config إلى next.config.js الخاص بك مثل هذا:

module.exports = {
  experimental: {
    css: true
  }
}

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

Timer هل يمكنك تقديم مثال لاستيراد تصميم النمل باستخدام دعم

ما زلت أواجه مشكلة مع Router.push ("/") عندما أكون في ارتباط آخر. أي شخص لديه حل لذلك؟ ارجوك ساعدني شكرا جزيلا

: تحذير: الرجاء التوقف عن استخدام هذا الموضوع كما أتمنى جيدا وتعقب المشكلة. هذا هو RFC وما زالوا ينفذونه.

آخر تعليق هادف من الفريق هو https://github.com/zeit/next.js/issues/8626#issuecomment -531415968 يمكنك تقييم التنفيذ الحالي من خلال تمكينه عبر https://github.com/zeit/next .js / issues / 8626 # issuecomment -568736218

أفتقد إمكانية تتبع العمل. كيف يمكن أن نساعد؟ Timer هل من الممكن ربط RFC هذا بالمعالم ، خارطة طريق؟ ما الذي تم عمله من النقاط في RFC؟

لا فكرة ، كيف تحافظ على المسار الصحيح: مرتبك:

StarpTech هذا RFC تم تنفيذه بالكامل ؛ تعمل وحدات CSS و CSS العالمية وفقًا لوصف RFC.

يمكنك اختبار كلاهما بعلم تجريبي واحد!

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

هبطت في 9.2: https://nextjs.org/blog/next-9-2