Haml: طلب الميزة: مجلد استيراد

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

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

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

أيضًا ، لدينا الأسبقية في أن استيراد مجلد يعد "أمرًا جيدًا". يسمح لك بيان استيراد Java باستيراد حزم كاملة أو فئات محددة من هذه الحزم.

يعتبر ترتيب الواردات مهمًا في الحالة العامة لأن المحددات التي لها نفس الوزن يتم حلها وفقًا لأمر المستند. يعني Globbing أن إضافة ملف يمكن أن يغير ترتيب الدقة العام للمحددات بشكل غير متوقع.

مشكلات الطلب هذه غير موجودة في الكود وأين توجد (مثل الياقوت) لا توجد مثل هذه الميزة.

سأكون مهتمًا بمعرفة ما إذا كانت هناك طريقة للقيام بذلك في Sass دون تغيير آلية استيراد sass الأساسية. سيسمح هذا للأطر والأفراد الذين يستخدمون sass بتطوير نظام globbing الخاص بهم على النحو الذي يرونه مناسبًا. على سبيل المثال:

<strong i="8">@import</strong> file-list("foo/*.sass");

اعتدنا أن يكون لدينا منطق تحليل خاص لـ @import كان من شأنه أن يمنع ذلك ، لكننا لم نعد كذلك.

تكمن مشكلة السماح بعمليات الاستيراد الديناميكية حقًا (مثل عبر الوظائف) في أنه عندئذٍ يصبح من المستحيل اكتشاف بنية التبعية الخاصة بالوثيقة ديناميكيًا. هذا يعني أن التخزين المؤقت والتجميع الانتقائي يصبحان أقل فائدة بكثير.

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

من المفترض أن مثل هذا النهج عبر globbing قد يعني استخدام محددات متداخلة لمنع مثل هذه المشكلات.

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

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

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

تماما مثل استيراد ملفات معينة يعمل. يناسب بعض المواقف دون غيرها.

يجب أن يكون الاختيار متروكًا للمطور.

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

الامتداد الذي أعتبره سيسمح بملفات globs القياسية - ربما تلك المدعومة بـ Dir.glob . سيكون هذا قابلاً للحل في وقت الترجمة ، وسيوفر درجة معقولة من القوة.

ما زلت بعيدًا عن الاقتناع فيما يتعلق بالفائدة.

من المهم مراعاة أن الطلب عبر Dir.glob يعتمد على نظام الملفات وقد يتغير عبر الأنظمة الأساسية - لقد تأثرت بالفعل بهذا الاختلاف بين Mac و Linux. لذلك إذا انتهينا من تنفيذ مثل هذه الميزة ، فمن المهم بالنسبة لنا فرز القائمة وفقًا لنهج موثق جيدًا ومفهوم بسهولة (على سبيل المثال ، التصنيف المصغر)

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

سنقوم بالتأكيد بترتيب الملفات بشكل حاسم بطريقة أو بأخرى. يعتبر التصنيف Upcased vs downcased سؤالًا مثيرًا للاهتمام ... ربما ينبغي علينا التقليل من قيمته باستخدام upcased باعتباره فاصلًا فاصلًا (لأنه سيسمح بالعلاقات على أنظمة الملفات الحساسة لحالة الأحرف).

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

يبدو أن الخيارين التاليين يجب أن يكونا كافيين:
-Cherry اختيار الملفات باستخدامimport
-استيراد دليل كامل باستخدام import folder_name

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

يعد استيراد الأدلة عبر <strong i="5">@import</strong> dir غامضًا جدًا عند استيراد الملفات الفردية. يجب علينا بالتأكيد إضافة ما لا يقل عن * globs.

ما زلت غير مقتنع ، رغم ذلك.

من المفيد إذا كان لديك "أنماط" مختلفة للصفحة. مثال:
عام / (ملفات xx sass هنا)
style1 / (ملفات xx sass هنا والتي تضيف / تستبدل الأنماط إلى تلك الموجودة في عامة)
style2 / (ملفات xx sass هنا والتي تضيف / تستبدل الأنماط إلى تلك الموجودة في عامة)
style1.sass (ببساطة: @ استيراد عام / _ ، style1 / _)
style2.sass (ببساطة: @ استيراد عام / _ ، style2 / _)

لماذا لا يمكنك فقط الحصول على _generic.sass الذي يستورد كل شيء في الدليل العام؟

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

تحديد "أوراق الأنماط المحددة النطاق"؟

أوراق الأنماط التي تتداخل مع معظم محدداتها أو جميعها. على سبيل المثال ، body.foo

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

إذًا ليس لديك حقًا إطار عمل لأن ملفاتك لا يتم فصلها بشكل صحيح.

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

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

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

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

ورقة الأنماط هذه منفصلة جيدًا ، ولكنها لا تزال تعتمد على الطلب.

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

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

تجاهل الواردات التي لم يتم العثور عليها بصمت لم يعد يمثل مشكلة في sass3. سيتم تجاهل عمليات استيراد css فقط بصمت.

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

إذا لم يتم العثور على وارداتي (أحدد دائمًا .sass للواردات) ، فستفشل اختباراتي.

هناك إضافة: بسيطة بقدر الإمكان وليس أبسط.

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

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

سأذهب وأغلق هذا.

gah ، هذا مقرف ... لدي مجلد يسمى page_specific / في أصول تطبيق rails الخاص بي ...
يجب تجميع كل هذه العناصر في blob الأصول الكبيرة ، ويتم تغليف كل منها بالكامل
body # page1 {} ، body # page2 {} ، إلخ ...

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

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

بالتأكيد يمكننا التفكير في طريقة لتقليل مشكلة الطلب البسيطة هذه. الترتيب الحتمي هو البداية. استدعاء it @ import-dir ، كما أن توثيق مشكلة الطلب المحتملة سيساعد أيضًا. توفر القضبان بالفعل خدمة required_tree ، ويبدو أن الأشياء هناك تعمل بشكل جيد. الاستثناء الوحيد هو أن الملفات يتم تجميعها بشكل فردي مما يؤدي إلى إسقاط المزيجات والمتغيرات الخاصة بي على الأرض. ألاحظ أن المزيجات هي الجزء الوحيد الذي تم تحديد موقعه على أنه مستقل عن النظام بشكل صريح ، فلماذا لا يعمل هذا مع sass عندما يعمل مع أي شخص آخر؟

https://github.com/chriseppstein/sass-globbing

تضمين التغريدة (وآسف على الصراخ مثل الجميع مجنون)