Haml: फ़ीचर अनुरोध: आयात फ़ोल्डर

मुझे इसकी उपयोगिता पर संदेह है। मुझे नहीं लगता कि सभी प्रासंगिक फाइलों को मैन्युअल रूप से सूचीबद्ध करना वास्तव में बोझिल है। साथ ही, ऐसा लगता है कि जब आप जिस फ़ाइल की अपेक्षा करते हैं वह मौजूद नहीं होने पर वास्तविक संकलन त्रुटियां न होने का खतरा हो सकता है। इसके बजाय, शैली मनमाने ढंग से गायब हो जाती है।

मैं आपके तर्क को समझता हूं, हालांकि, मुझे नहीं लगता कि आप अन्य प्रकार की स्थिति देख रहे हैं जिसकी इसकी आवश्यकता है। वर्तमान में मेरे पास एक फ़ोल्डर है जिसमें 60+ Sass फ़ाइलें होंगी। किसी फ़ोल्डर को @import करने की क्षमता के बिना, मुझे एक फ़ाइल बनाए रखने की आवश्यकता है जो प्रत्येक फ़ाइल को अलग-अलग आयात करती है।

प्रत्येक फ़ाइल को व्यक्तिगत रूप से शामिल करने में कई समस्याएं हैं। सबसे पहले, यदि आप किसी फ़ाइल को शामिल करना भूल जाते हैं, तो आपको कोई चेतावनी नहीं मिलती है। अगला, यदि आपके पास Sass पर काम करने वाले डेवलपर्स की एक टीम है, तो उनमें से प्रत्येक को फ़ाइल को फ़ोल्डर में बनाने के बाद मैन्युअल रूप से आयात करना याद रखना होगा। सही काम करने के लिए लोगों के आधार पर अंततः टूट जाएगा।

साथ ही, हमारे पास प्राथमिकता है कि एक फ़ोल्डर आयात करना एक "अच्छी बात" है। जावा का आयात विवरण आपको संपूर्ण पैकेज या उन पैकेजों के विशिष्ट वर्गों को आयात करने की अनुमति देता है।

आयात का क्रम सामान्य मामले में महत्वपूर्ण है क्योंकि समान भार के चयनकर्ता दस्तावेज़ आदेश के अनुसार हल करते हैं। ग्लोबिंग का अर्थ है कि फ़ाइल जोड़ने से चयनकर्ताओं का वैश्विक रिज़ॉल्यूशन क्रम अप्रत्याशित रूप से बदल सकता है।

इस तरह के ऑर्डरिंग मुद्दे कोड में मौजूद नहीं हैं और जहां वे हैं (रूबी की तरह) ऐसी कोई सुविधा नहीं है।

मुझे यह देखने में दिलचस्पी होगी कि एसएएस कोर आयात तंत्र में बदलाव के बिना एसएएस में ऐसा करने का कोई तरीका है या नहीं। यह ढांचे और व्यक्तियों को एसएएस का उपयोग करने के लिए अपने स्वयं के ग्लोबिंग सिस्टम को विकसित करने की अनुमति देगा जैसा कि वे फिट देखते हैं। उदाहरण के लिए:

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

हमारे पास @import लिए विशेष पार्सिंग तर्क हुआ करता था जो इसे रोकता, लेकिन अब हम नहीं करते हैं।

वास्तव में गतिशील आयात (जैसे कार्यों के माध्यम से) की अनुमति देने में समस्या यह है कि तब दस्तावेज़ की निर्भरता संरचना को गतिशील रूप से समझना असंभव हो जाता है। इसका मतलब है कि कैशिंग और चयनात्मक संकलन बहुत कम उपयोगी हो जाते हैं।

समस्याओं का आदेश देने के लिए, हम हमेशा फाइलों को वर्णानुक्रम में या कुछ नियतात्मक (यद्यपि मनमाना) क्रम के साथ आने के लिए क्रमबद्ध कर सकते हैं। यह अभी भी समस्या प्रस्तुत करता है कि यदि फ़ाइल का नाम बदलता है, तो ऑर्डर करना कार्यक्षमता को बदल सकता है और बाधित कर सकता है।

संभवतः, ग्लोबिंग के माध्यम से इस तरह के दृष्टिकोण से ऐसे मुद्दों को रोकने के लिए नेस्टेड चयनकर्ताओं का उपयोग करना होगा।

मेरी राय में, फाइलों की एक पूरी निर्देशिका ट्री को आयात करने से स्पष्ट आयात दृष्टिकोण पर केवल मामूली उपयोगिता है और उपयोगकर्ता को प्राथमिकता के मुद्दों पर विचार करने के लिए प्रोत्साहित करता है। यदि हम ऐसी कोई सुविधा जोड़ते हैं, तो मैं चाहूंगा कि यह केवल निर्देशिका स्तर की तुलना में अधिक सामान्य उद्देश्य हो।

अंत में, मुझे लगता है कि आप सही हैं कि निर्भरता ग्राफ के बाहर एक ग्लोब पेश करना और एसएएस इंजन के लिए केवल एक आयात के रूप में प्रकट होता है, इसका मतलब है कि जब नई निर्भरताएं ग्लोब से मेल खाती हैं तो फाइलों को अमान्य करना कठिन होता है।

मैं सहमत हूं कि किसी फ़ोल्डर को आयात करने से फ़ाइलों का आयात करने का एक अस्पष्ट क्रम होगा। हालांकि, यह तय करने के लिए उपयोगकर्ता पर निर्भर होना चाहिए कि क्या यह उनके लिए सही बात है। यह कुछ स्थितियों में फिट होगा लेकिन अन्य में नहीं। ऐसी प्रणाली की कल्पना करना निश्चित रूप से संभव है जहां किसी फ़ोल्डर की सामग्री समान तत्वों को लक्षित नहीं करती है (मेरा नहीं)।

जैसे विशिष्ट फाइलों को आयात करना काम करता है। यह कुछ स्थितियों में फिट बैठता है लेकिन अन्य में नहीं।

पसंद डेवलपर पर निर्भर होना चाहिए।

उपयोगकर्ता के लिए स्टाइलशीट होना बहुत आसान है जो ऑर्डर-निर्भर हैं और इसे नहीं जानते हैं। कुछ भी पुन: आदेश को ट्रिगर कर सकता है और लेआउट बग बना सकता है जिसे ट्रैक करना बहुत मुश्किल होगा। और यह पर्याप्त रूप से स्पष्ट नहीं होगा कि निर्देशिका आयात करने से कोई व्यक्ति ऐसे मुद्दों के लिए खुला रह जाएगा। फ़ाइल नाम के माध्यम से ऑर्डर करना शायद इसके लिए एक अच्छा पर्याप्त समाधान होगा, हालांकि, यह गंभीर बाधा नहीं है।

मैं जिस एक्सटेंशन पर विचार करूंगा, वह मानक फ़ाइल ग्लोब की अनुमति देगा - शायद वे Dir.glob द्वारा समर्थित हैं। यह संकलन-समय पर हल करने योग्य होगा, और उचित मात्रा में शक्ति प्रदान करेगा।

मैं अभी भी उपयोगिता के रूप में आश्वस्त होने का एक तरीका हूं, हालांकि।

यह विचार करना महत्वपूर्ण है कि Dir.glob माध्यम से ऑर्डर करना फाइल सिस्टम पर निर्भर है और सभी प्लेटफार्मों में बदल सकता है - मुझे वास्तव में मैक और लिनक्स के बीच इस अंतर से काट लिया गया है। इसलिए यदि हम इस तरह की सुविधा को लागू करते हैं, तो हमारे लिए सूची को एक अच्छी तरह से प्रलेखित और आसानी से समझ में आने वाले दृष्टिकोण के अनुसार क्रमबद्ध करना महत्वपूर्ण है (जैसे डाउनकेस सॉर्ट)

मैं अभी भी इस सुविधा के खिलाफ थोड़ा झुक रहा हूं। कंपास द्वारा उपयोग किया जाने वाला आयात दृष्टिकोण वास्तव में रखरखाव का बोझ नहीं रहा है। हालाँकि, यह निश्चित रूप से एक सामान्य रूप से अनुरोधित विशेषता है। मुझे लगता है कि इसे अब लगभग 4 या 5 बार मेलिंग सूची और ट्विटर पर लाया गया है।

हम निश्चित रूप से किसी भी तरह फाइलों को निश्चित रूप से ऑर्डर करेंगे। अपकेस बनाम डाउनकेस सॉर्ट एक दिलचस्प सवाल है ... हमें शायद एक टाईब्रेकर के रूप में अपकेस के साथ डाउनकेस करना चाहिए (क्योंकि यह केस-संवेदी फाइल सिस्टम पर संबंधों की अनुमति देगा)।

मैं सहमत हूं। मैं एक पैरामीटर को सीधे Dir.glob पर पास करने में सक्षम होने के खिलाफ हूं। यह वास्तव में एक अनावश्यक विशेषता की तरह लगता है। क्या आप लोग ऐसे परिदृश्य के साथ आ सकते हैं जहां उस हद तक नियंत्रण रखना फायदेमंद हो?

ऐसा लगता है कि निम्नलिखित दो विकल्प पर्याप्त होने चाहिए:
-चेरी @import . का उपयोग करके फ़ाइलें चुनें
- @import folder_name . का उपयोग करके एक संपूर्ण निर्देशिका आयात करें

साथ ही, मुझे लगता है कि वर्णानुक्रम ठीक काम करेगा। हमें बस यह सुनिश्चित करने की आवश्यकता है कि इसका दस्तावेजीकरण हो।

<strong i="5">@import</strong> dir माध्यम से निर्देशिका आयात करना व्यक्तिगत फ़ाइलों को आयात करने के साथ बहुत अस्पष्ट है। हमें निश्चित रूप से कम से कम * ग्लोब जोड़ना चाहिए।

हालांकि अभी भी यकीन नहीं हो रहा है।

यदि आपके पास किसी पृष्ठ के लिए अलग-अलग "शैलियाँ" हैं तो यह उपयोगी है। उदाहरण:
जेनेरिक/(xx sass फ़ाइलें यहाँ)
Style1/ (xx sass फाइलें यहां जो सामान्य में शैलियों को जोड़ती/अधिलेखित करती हैं)
Style2/ (xx sass फाइलें यहां जो सामान्य में शैलियों को जोड़ती/अधिलेखित करती हैं)
style1.sass (बस: @import जेनेरिक/_, स्टाइल1/_)
style2.sass (बस: @import जेनेरिक/_, स्टाइल2/_)

आपके पास सिर्फ _generic.sass क्यों नहीं हो सकता जो सामान्य निर्देशिका में सब कुछ आयात करता है?

मुझे नहीं लगता कि यह इस बारे में है कि उन्हें क्या करना चाहिए या क्या नहीं करना चाहिए। अंततः स्टाइलशीट का क्रम महत्वपूर्ण है और इसलिए मैं चाहता हूं कि उपयोगकर्ता द्वारा इसके बारे में सोचा जाए। यह सच है कि पुस्तकालयों कि केवल mixins और वैरिएबल निर्धारित के रूप में स्टाइलशीट scoped रहे हैं क्रम स्वतंत्र हैं - लेकिन मैं एक सामान्य क्षमता है कि का उपयोग गलत है हो जाएगा प्रदान करने के बारे में चिंता।

"स्कोप्ड स्टाइलशीट" परिभाषित करें?

स्टाइलशीट जो उनके अधिकांश या सभी चयनकर्ताओं को घोंसला बनाती है। जैसे body.foo

उन्हें आदेश-स्वतंत्र होने की गारंटी नहीं है। एक अन्य स्टाइलशीट कहीं और परिभाषित कर सकती है body.foo ... , या उच्च विशिष्टता के साथ कुछ और।

तब आपके पास वास्तव में कोई कार्य ढांचा नहीं है क्योंकि आपकी फ़ाइलें सही ढंग से अलग नहीं होती हैं।

लोगों के लिए अपने CSS को खराब करने के बहुत सारे तरीके हैं। हम उन्हें यह समाधान प्रदान कर सकते हैं और समझा सकते हैं कि व्यक्तिगत फ़ाइलों को आयात करने पर इसका उपयोग कब किया जाना चाहिए।

इस सुविधा को लागू न करके आप उन डेवलपर्स को दे रहे हैं जो इसे लागू करना चाहते हैं स्कोप्ड स्टाइलशीट ये दो विकल्प:
1) प्रत्येक फ़ाइल को स्वतंत्र रूप से मैन्युअल रूप से आयात करें (जो स्वयं की त्रुटियों का कारण बन सकती है क्योंकि यह आपको यह नहीं बताती है कि आपने कब कोई फ़ाइल खो दी है)
2) इन फ़ाइलों को गतिशील रूप से जोड़ने के लिए एक बिल्ड सिस्टम लागू करें (जो एक बेकार है क्योंकि एक ही चीज़ को लागू करने वाले कई लोग होंगे)

यह निश्चित रूप से ऐसा नहीं है कि स्कोप्ड स्टाइलशीट की सभी ऑर्डर-निर्भरता चिंताओं के खराब अलगाव का परिणाम है। विचार करना:

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

यह स्टाइलशीट अच्छी तरह से अलग है, लेकिन फिर भी ऑर्डर-निर्भर है।

किसी भी मामले में, यह विचार गलत है कि हम इस सुविधा का उपयोग करने वाले प्रत्येक व्यक्ति से जोखिमों को समझने की अपेक्षा कर सकते हैं। यह सुनिश्चित करने का एकमात्र तरीका है कि हर कोई समझता है कि उनकी स्टाइलशीट किस क्रम में आयात की जाएगी, इसे स्पष्ट रूप से निर्दिष्ट किया जाना है।

मोटे तौर पर स्कोप्ड स्टाइलशीट ऑर्डर अज्ञेयवादी होंगे, लेकिन यह मामला हो सकता है कि ऑर्डर तब भी मायने रखता है जब चिंताओं को सही ढंग से अलग किया जाता है।

उन आयातों को चुपचाप अनदेखा करना जो अब sass3 में कोई समस्या नहीं हैं। केवल css आयातों को चुपचाप अनदेखा कर दिया जाएगा।

मेरे पास एक एसएएस फ़ाइल है जो लगभग 60 अन्य आयात करती है। जब फ़ाइलें जोड़ी जाती हैं या हटा दी जाती हैं तो मैं इसे बदल देता हूं और जब मैं करता हूं तो मैं हमेशा ऑर्डरिंग के बारे में सोचता हूं। यह मुझे कभी भी बोझ जैसा नहीं लगा, बल्कि एक आवश्यक कदम था।

अगर मेरे आयात नहीं मिलते हैं (मैं हमेशा आयात के लिए .sass निर्दिष्ट करता हूं) तो मेरे परीक्षण विफल हो जाते हैं।

एक जोड़ा है: जितना संभव हो उतना सरल और कोई आसान नहीं।

मेरा पेट मुझे बताता है कि इससे चीजें बहुत आसान हो जाती हैं और एक डिबगिंग सत्र से सभी समय की बचत खो जाती है। मैं वोट देता हूं कि हमने इसे फिलहाल के लिए अलग रखा है। अगर कोई एसएएस प्लगइन बनाना चाहता है जो यह क्षमता प्रदान करता है, तो मुझे यह देखने में बहुत दिलचस्पी होगी कि यह उन उपयोगकर्ताओं के लिए कैसे काम करता है।

मुझे लगता है कि रिचर्ड की बात यह थी कि जब आंशिक बनाया जाता है तो कोई त्रुटि नहीं होती है लेकिन इसके लिए कोई आयात नहीं जोड़ा जाता है। मुझे लगता है कि अप्रयुक्त आंशिक और उनके लिए मुद्रण चेतावनियों की तलाश करके इसे कम किया जा सकता है।

मैं आगे जाकर इसे बंद करने जा रहा हूं।

गह, यह बेकार है ... मेरे पास मेरे रेल ऐप की संपत्तियों में पेज_स्पेसिफिक/नामक एक फ़ोल्डर है ...
इन सभी को बड़ी संपत्ति ब्लॉब में संकलित किया जाना चाहिए, और वे प्रत्येक पूरी तरह से लिपटे हुए हैं
बॉडी#पेज1 {}, बॉडी#पेज2 {}, वगैरह...

उनके आदेश पर निर्भर होने की शून्य संभावना है, और स्पष्ट रूप से यह पूरी "आप चूक जाएंगे-इसका उपयोग करेंगे! नहीं!!!!!!" बकवास अपमानजनक है।

यदि इस सुविधा के एक उपयोगकर्ता को पता चलता है कि आदेश महत्वपूर्ण है, तो वे केवल एक स्पष्ट क्रम में फ़ाइलों को आयात कर सकते हैं, या शैलियों को आदेश-निर्भर नहीं होने के लिए रिफैक्टर कर सकते हैं ... (

निश्चित रूप से हम ऑर्डर देने की इस छोटी सी समस्या को कम करने के तरीके के बारे में सोच सकते हैं। नियतात्मक आदेश एक शुरुआत है। इसे @ आयात-डीआईआर कहते हैं, और संभावित ऑर्डरिंग समस्या के दस्तावेज़ीकरण से भी मदद मिलेगी। रेल पहले से ही requ_tree प्रदान करता है, और वहां चीजें ठीक काम करने लगती हैं। एक अपवाद यह है कि फाइलें व्यक्तिगत रूप से संकलित हो जाती हैं जो मेरे मिश्रण और चर को फर्श पर गिरा देती हैं। मैं ध्यान देता हूं कि मिश्रण एक हिस्सा है जिसे स्पष्ट रूप से ऑर्डर-स्वतंत्र के रूप में बैठाया गया था, तो यह एसएएस के लिए क्यों काम नहीं कर सकता जब यह हर किसी के लिए काम करता है?

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

@chriseppstein कमाल है! (और हर किसी को पागल की तरह शेखी बघारने के लिए खेद है)