Less.js: تستخدم دالة data-uri مسار استدعاء بيانات uri ، وليس السلسلة التي تحتوي على المسار إلى الملف بتنسيق.

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

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

حاليا data-uri() وظيفة يقبل Quoted شجرة عقدة عقد سلسلة ك مسار الملف ويقرر داخليا كما URL ضد موقع ملف عقد استدعاء دالة. يمكنك زيادة تحميل الوظيفة data-uri لقبول عقدة شجرة Url تحمل عنوان URL فعليًا. بهذه الطريقة ، يجب أن يتم تطبيع عنوان URL مقابل الموقع الذي يتم استدعاء وظيفة url() CSS فيه ويجب ألا يتم تطبيعه داخليًا في وظيفة data-uri() Less.

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

// app/content/button.less
button {
  .background(url("images/btn.jpg"));
}

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

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

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

(على سبيل المثال ، بالنسبة إلى مزيج وجه الخط كمثال ، عادةً ما تكون عدة امتدادات woff ، ttf ، eot ، eot?#iefix إلخ. ). وبهذه الطريقة فإن url مستحيل أيضًا.

@ سبع مراحل كحد أقصى

ثم لا أعتقد حقًا أن هناك فترة حل مناسبة. أنت بحاجة إلى طريقة ما لتحديد السياق الذي يجب أن يحل عنوان URL النسبي على أساسه. إما أن تأخذ هذا السياق من معلومات الملف للملف الذي حدد قيمة السلسلة التي تنتقل إلى الدالة data-uri() ، أو تجعل نقطة القطع أكثر وضوحًا عبر الدالة url() و Url عقدة شجرة.

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

على سبيل المثال ، كيف تطبيع شيئًا مثل:

// mixins.less
.background(@image) {
    background-image: data-uri("../../@{image}.jpg");
}
// app/content/button.less
button {
  .background("../images/btn");
}

كيف يمكنك الجمع بين دقة عنوان url النسبية والتركيبة المدفوعة بإحلال الرمز المميز لهذين المسارين؟

أفترض أن أحد الخيارات هو الحل فقط في مقابل الملف الذي يحدد السلسلة التي يتم استبدالها برمز بديل ، عندما يكون رمز الاستبدال في رأس قيمة عنوان URL النهائي يذهب إلى url() أو data-uri() وظيفة

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

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

// mixins.less
.background(@image) {
    background-image: data-uri(extension(<strong i="21">@image</strong>, "jpg"));
}
// app/content/button.less
button {
  .background(url("./images/btn"));
}

بالنسبة لمثالك الأول ، لا يحتاج إلى أي تطبيع خاص ، يتوسع "../../@{image}.jpg" إلى "../../../images/btn.jpg" تمامًا كما هو مكتوب (ثم يصل الأمر إلى data-uri للتعامل مع المسار).
والمثال الثاني هو ... تكديس دالة لإيجاد حل بديل لدالة لحل التوافق مع الإصدارات السابقة مع ... ما هو بالضبط؟ _Wrong_ ملف مسارات عند استدعاء mixin المعرفة في ملف آخر؟

بعد كل شيء ، إذا كان من المفترض أن يعمل "كما هو متوقع" _ فقط_ مع .background(url("images/btn.jpg")); ، فكيف يختلف عن مجرد كتابة .background(data-uri("images/btn.jpg")); مباشرة بدون أي تغييرات على الإطلاق؟ :)

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

_{بعبارة أخرى ، بافتراض أن url و data-uri تم تصميمهما مبدئيًا ليكونا قابلين للتبديل (على سبيل المثال ، data-uri هو مجرد إصدار خاص من url (ويتم تجميعه في CSS url في النهاية)) ، سيكون من المؤلم وصف سبب تصرف ulr "بهذا الشكل" بالضبط (مع خيارات من هذا القبيل) بينما data-uri يتصرف "هكذا" (مع مثل هذا) ، وللحصول على سلوك معين ، ستحتاج إلى مجموعة مكونة من data-uri(url()) ، تقتصر على " data-uri داخل مزيج و url _out_ منها بـ --relative-urls: on "<- بحررر ... :)}

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

نعم أوافق.

أحاول ببطء أن أبذل مزيدًا من الجهد لبذل جهد أقل لإصدار v3 وإصلاح هذا فقط.

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

من المحتمل أن تساعد وظيفة resolve() في تمرير عناوين url التي تم حلها إلى الوظائف (ولكن إذا لم يكن المسار الكامل الذي لن يعمل وسيعمل المسار الكامل عند إصلاح ذلك ...)

آسف فقط بسرعة تدوين الأفكار.

هذه مجرد ملاحظة سريعة ، لكننا سنواجه نفس المشكلة مع الاستيراد باستخدام الاستيفاء المتغير.

استيراد باستخدام الاستيفاء المتغير.

هذا مثير للاهتمام ومقلق.
هل هي حالة استخدام مدعومة بالفعل أم صدفة سعيدة؟

rjgotten إنه مدعوم ، لكن الدعم محدود نوعًا ما. تم تعقبه في # 410

هذا يعمل:

<strong i="8">@variable</strong>: "path.less";
<strong i="9">@import</strong> "@{variable}";

لم يحدث ذلك:

.mixin(@variable) {
  <strong i="13">@import</strong> "@{variable}";
}

تحرير: تعديل لجعل الارتباط يعمل.

لست متأكدًا من أنني أريد دعم المتغير @import في mixins.
كل شيء استيراد المتغير هو سحر قليلاً ويمكنه إنشاء بعض التعليمات البرمجية غير البديهية .. لذلك أفضل عدم تشجيع ذلك.

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

لدي الآن ملف يستورد _a reference_ من مسار آخر ، ولا يزال يشكو من data-uri. على الأقل يجب أن يكون هذا خطأ؟ أعني أنه إذا قمت بالاستيراد بالرجوع إليه ، فلا ينبغي محاولة إعادة كتابة المسارات إلى نسبة إلى الملف الحالي.

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

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

بناء على ماذا بالضبط؟ ما علاقة ذلك بـ reference ؟

لدي الآن ملف يستورد مرجعًا من مسار آخر ، ولا يزال يشكو من data-uri.

يبدو عكس ما ورد أعلاه. هل يمكنك تقديم المزيد من التفاصيل؟ (على سبيل المثال ، مسارات ملفات الاستيراد والمستوردة والبيانات وما إلى ذلك).

الأنماط

.something {
    background: data-uri("some.svg");
}

فرعي / test.less

<strong i="11">@import</strong> (reference) "../style.less";
.test {
    color: green;
}

يقوم بتجميع style.less ، ولكن ليس الاختبار بدون اختبار لأنه يحاول استخدام بيانات uri بالنسبة إلى test.less.

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

أتوقع أن تتبع data-uri قواعد إعادة كتابة عنوان url في الخيارات. بالطبع .... من الصعب قول ما يعنيه ذلك في الواقع باستخدام data-uri.

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

// app/content/button.less
button {
  .background("images/btn.jpg");
}

يجب أن يبحث عن btn.jpg عند app/content/images/ . إذا لم يكن الأمر كذلك ، فهذا خطأ لأنه ليس الطريقة التي يجب أن تعمل بها الخلطات. لا أعتقد أنه "تغيير جذري" ولكن إصلاح خطأ.

ومع ذلك ... لا أعتقد أنه ستكون هناك مشكلة في حل مثل:

1. محاولة حل المشكلة المتعلقة بالمتصل.
2. محاولة حل مسألة الخلط.

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

@ ماثيو دين
بشكل عام ، يجب أن يتم حل بيانات uri بالنسبة إلى "ملف .less الاستدعاء". لذلك في حالة الخلط ، يجب أن يتم حله بالنسبة إلى المكان الذي يسمى فيه mixin ، وليس بالنسبة إلى موقع mixin. يمزج mixin في تلك العبارات ثم يحلها.

لا يمكنك أن تجعل ذلك يعمل بطريقة صحيحة بشكل عام لجميع حالات الاستخدام.

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

كان لدي القليل من التجلي حول كيفية إصلاح هذا بشفافية دون استخدام صريح لـ url() في موقع الاتصال ، والذي وصفته @ Seven -hase-max بحق بأنها فكرة سيئة (لأن شخصًا ما _ سيحاول في النهاية _ إعادة تشكيله في استدعاء mixin وكسر الأشياء):

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

يحافظ ذلك على عمل كل شيء كما هو متوقع ، باستثناء السيناريوهات ذات سلاسل الاستبدال مثل:

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

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

إذا كان القصد من مؤلف المزيج هو الحصول على مثل هذه المسارات مقابل ملف mixin ، فلا يزال بإمكانهم تنفيذ هذا العمل باستخدام ، على سبيل المثال ، "./@{image}.jpg" كنمط. هذا ينقل بشكل فعال عبء المسؤولية بعيدًا عن المتصل ، وهو ما تريده.

// _mixins.less
.sprite(@image) {
    background: data-uri("../images/sprites/@{image}.png") no-repeat;
}

// main.less
div {
   .sprite('logo');
}

انتاج:

div {
   background: url(data:image/png;base64,...) no-repeat;
}

واو ، هذا قديم جدًا .... اثنين سنتي لأن هذه المشكلة تؤثر علي أيضًا.

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

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

لم تكن القضية هنا تتعلق بالمسارات المطلقة مقابل المسارات النسبية. كان الأمر يتعلق بالنسبية مقابل موقع الاتصال مقابل موقع النسبي مقابل موقع الإعلان. مشكلة مختلفة تماما.

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

إذن ، أين عامل المسارات المطلقة في ذلك كحل؟

بافتراض أن data-uri يقبل المسارات المطلقة وأن هناك دالة أخلاقية absolute-url ، فإن الكود التالي سيعمل بغض النظر عن مكان وضع mixin.

// mixins.less
.background(@image) {
    background-image: data-uri(@image);
}

// app/content/button.less
button {
  .background(absolute-url("images/btn.jpg"));
}

@ miljan-aleksic بعبارة "مطلق" هل تقصد نسبة إلى الملف الموجود في موقع data-uri ؟ إذا كان الأمر كذلك ، فربما يكون مصطلح "مطلق" هو ​​الخطأ.

يبدو أنه غلاف وظيفي لعنوان url لجعل أي ملف نسبي لعنوان url هو أسلوب جيد. أو وسيطة إضافية لـ url ().

@ Matthew-dean ، بالمطلق أعني المسار الكامل للملف ، على سبيل المثال: /users/myuser/projects/lessproject/icon.svg .

لا أفهم نهجك لأنني لا أرى كيف يمكن لعنوان url () إنشاء مسار نسبي لملف موقع بيانات uri دون معرفة ذلك.

يبدو أنه غلاف وظيفي لعنوان url لجعل أي ملف نسبي لعنوان url هو أسلوب جيد. أو وسيطة إضافية لـ url ().

تهريج بما يكفي؛ هذا تقريبًا ما اقترحته قبل بضع سنوات. ؛-)

بالمطلق أعني المسار الكامل للملف ، على سبيل المثال: /users/myuser/projects/lessproject/icon.svg.

يبدو أنك تعني مطلقًا أن هذه الدالة absolute-url _pre-resolves_ المسار النسبي الذي تم تمريره إليها إلى مسار الإخراج الكامل ، بناءً على موقع الملف الذي تُسمى فيه الوظيفة absolute-url ، بالنسبة إلى الموقع الذي سيذهب إليه ملف CSS الناتج المترجم.

أي أنكما تعنيان نفس الشيء. كما فعلت أنا في ذلك الوقت.

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

كما هو الحال في ، ستظل إعادة كتابة عناوين URL أو مسار الجذر سارية ، ولكن استنادًا إلى موقع التعريف؟ يبدو هذا مختلفًا بعض الشيء عن المثال الأصلي لـ lukeapage ، والذي لم يكن يتحدث عن عناوين URL المتعلقة بالمخرجات ، ولكن عناوين URL أثناء التحويل البرمجي ؛ على سبيل المثال ، الموقع data-uri() .

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

ربما نحتاج إلى شيء مثل resolve() ؟ أنا لا أعرف ، فقط البصق ، ولكن url(resolve(file(), "my/path")) ؟ أعتقد أن هذا هو ما تعنيه @ miljan-aleksic بـ absolute() ، من حيث أنها ستحل إلى عنوان URL مطلق. ولكن لا يزال من المفترض أن يتطلب الأمر إدخالاً (مثل file() ، لحل ضده). بخلاف ذلك ، يمكنك القيام بشيء مثل file-resolve() لتعيين هذا المنطق في وظيفة واحدة ، ولكن وجود resolve() و file() كدالتين قد يكون مفيدًا بشكل منفصل.

الجزء الصعب حول كل هذا هو كل خيارات عنوان URL لإعادة الكتابة ، والتي يوجد منها الآن المزيد من دمج العلاقات العامة التي أضافت دعم الوحدة النمطية. (https://github.com/less/less.js/pull/3248). لذا إذا عرض عنوان URL نسبيًا للملف ، فهل لا يزال من الممكن إعادة كتابته؟ سأفترض نعم ، لكننا نحتاج إلى أن نكون واضحين.

نعم ، حل () والملف () يحددان بالضبط ما كنت أحاول شرحه. آمل أن نتمكن من رؤية هذا مطبقًا في المستقبل القريب.

@ miljan-aleksic حسنًا ، هذا منطقي إذن.

في الواقع ، file() ليس صحيحًا تمامًا ، نظرًا لأن ذلك سيعيد اسم الملف الذي أفترضه ، سيكون مثل dir() . ومن المحتمل أن يكون ثابتًا متغيرًا لكل ملف.

ماذا عن:

data-uri(resolve(<strong i="10">@DIR</strong>, "my/path"))

لذلك ، تمت إضافة شيئين: 1) وظيفة حل () لدمج المسارات ، 2) يتم إدخال ثابت @DIR (و @FILE ؟) في كل ملف أثناء التقييم. الشيء الوحيد المخادع في ذلك هو اختبار عدم تجاوز تلك الحقن المحقونة أو دمجها مع متغيرات أخرى في الجذر ، ولكن يجب أن يكون الاختبار بسيطًا إلى حد ما. أم يجب أن تكون أحرفًا صغيرة ، مثل @arguments ؟ في هذه الحالة ، أقترح @directory و @filename لتجنب التعارضات. ما هو أكثر خيار أقل ص؟

ربما نحتاج إلى شيء مثل resolve() ؟

^ بنغو. هذا بالضبط.

ما هو أكثر خيار أقل ص؟

سأختار Node.js-y الخيار: __dirname
لقد كان موجودًا منذ فترة طويلة وهو معروف جيدًا. قد يكون استخدام نفس الاسم لنفس المفهوم في Less فكرة جيدة.

سأختار Node.js-y الخيار: __dirname

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

لا تزال الشرطة السفلية غريبة بعض الشيء بالنسبة للغة. لا يصلح على الإطلاق.

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

بالتاكيد؛ إذا لم تعجبك ، فيمكنك دائمًا استخدام مشتق مثل @dirname أو @dir-name .

ومع ذلك ، بعد التفكير في هذا الأمر أكثر ، لماذا _ نحتاج_ حتى _ يتم عرض مسار الملف الحالي كمتغير؟ ألا يمكن نسجها في دالة resolve() المفاهيمية نفسها؟

ألا يمكن نسجها في وظيفة الحل المفاهيمي نفسها؟

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

وعدنا إلى اقتراحي ، فقط باسم وظيفة مختلف.

نوعا ما.

ما أحصل عليه هو أن afaik ليست هناك حاجة لتمرير عنوان URL / مسار الملف الذي يحتفظ بالمكالمة إلى وظيفة resolve() ، حيث يجب أن يكون هذا الموقع _المعروف _ للوظيفة.

يشير this داخل دالة إلى مثيل FunctionCaller ، والذي يحتوي على خاصية currentFileInfo .
تتم تهيئة هذه الخاصية إلى معلومات الملف الخاصة بعقدة AST Call المقابلة لاستدعاء الوظيفة.
بمعنى آخر

https://github.com/less/less.js/blob/4e903e8254cc20fec80fccd35794fb797949e653/lib/less/tree/call.js#L47

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

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

ومع ذلك ، بعد التفكير في هذا أكثر ، لماذا نحتاج حتى إلى كشف مسار الملف الحالي كمتغير؟ ألا يمكن نسجها في وظيفة الحل المفاهيمي نفسها؟

إذا كنا على يقين من أن لا أحد يحتاج إلى الملف الحالي أو وظيفة محلل عام ... ربما ... الشيء هو var محلي صريح يوضح أنه ليس وظيفة عامة ، وأن الوظيفة لن يتم تقييمها مثل أي وظيفة أخرى. هذا هو قلقي الحقيقي ، الدلالات. بغض النظر عن تسميته ، إذا لم يكن لديك "علامة" خاصة لـ "الملف الحالي" ، فهي ليست مثل أي وظيفة أخرى يتم حلها بنفس الطريقة بناءً على المدخلات. بعبارة أخرى ، إنها وظيفة يتم حلها وفقًا لمدخلات غير مرئية ، وهذا يهمني. ومع ذلك ، إذا كانت الوظيفة صريحة للغاية مثل current-file-resolve() ، فربما يكون هذا واضحًا بدرجة كافية. وإلا فإنك ستربك الأشخاص بسبب عدم حل مكالمة mixin specialfunction() وفقًا للملف الذي تم استدعاؤه فيه ، بدلاً من الملف الذي تم تعريف mixin فيه.

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

همم...

نعم. ثم ماذا عن وظيفة resolve-url(url, [base]) - مع base اختياري؛ التقصير في دليل الملف الذي تمت كتابة / إعلان / تعريف استدعاء الوظيفة فيه. ثم لديك وظيفة declared-dir() التي تسحب this.fileInfo وتنتقل إلى المسار ، إذا أراد المؤلفون سحب المسار بوضوح ؛ تريد أن تأخذ مسارًا من ملف مختلف ؛ أو تحتاج إلى استخدام هذا كجزء من بعض الميزات الأخرى التي لا تتعلق بدقة عنوان URL.

أي استدعاء النموذج الكامل (بدون قاعدة ضمنية) سيكون شيئًا مثل:

resolve-url("../foo", declared-dir())

... وسيكون مكافئًا لمجرد القيام به

resolve-url("../foo")

... وهو المكافئ الشغوف للكسول

url("../foo")

لا توجد حاجة إلى متغيرات يتم حقنها تلقائيًا بهذه الطريقة. أعتقد أن هذا يمكن تنفيذه فقط كمجموعة من وظائف البرنامج المساعد. والميكانيكي الأساسي الوحيد الذي نحتاجه هو طريقة لتمييز عناوين URL على أنها "تم حلها بالفعل" ، بحيث يمكن منع منطق المحلل الافتراضي من العمل على عناوين URL التي تأتي من وظيفة resolve-url .

يجب أن تكون الدلالات واضحة في توثيق الدورة. ويمكن لهذه الوثائق أن تقارن صراحةً بين url مقابل resolve-url لتوضيح التقييم / الدقة الشغوف والكسول.

_{فقط في حالة عدم نجاح فكرة "المتغيرات المحقونة" (بدون عمليات اختراق إضافية) على أي حال لأن الملفات المستوردة لها نفس النطاق.}

<strong i="7">@__dir</strong>: "whatever";
// *everywhere* it's the only <strong i="8">@__dir</strong> value = the path of "c"
<strong i="9">@import</strong> "a";
<strong i="10">@import</strong> "b";
<strong i="11">@import</strong> "c";

عند الحديث عن التنفيذ المستند إلى الوظيفة ، أعتقد (ولكن لا يمكنني التأكد من ذلك) أنه لا يزال من الممكن الحصول على مسار الملف حيث يتم استدعاء الوظيفة في مكان ما في this.context.? أو this.context.frames[?] أو هكذا.

emmmm ، لذلك ليس لدينا طريقة أفضل لحلها؟

تضمين التغريدة
emmmm ، لذلك ليس لدينا طريقة أفضل لحلها؟

التقييم الكسول يجعل من الصعب جدًا حل هذا بشكل صحيح ، أخشى.

@ سبع مراحل كحد أقصى
عند الحديث عن التنفيذ المستند إلى الوظيفة ، أعتقد (ولكن لا يمكنني التأكد من ذلك) أنه لا يزال من الممكن الحصول على مسار الملف حيث يتم استدعاء الوظيفة في مكان ما في this.context.? أو this.context.frames[?] أو هكذا.

يجب أن تكون قادرًا على العثور على العقدة Call في تسلسلها الهرمي ، نعم.