Less.js: كيفية التعامل مع الرياضيات المختلطة

بصراحة ، لم أكن أبدًا من المعجبين بالقدرة على مزج الوحدات في Less. لا معنى له من منظور رياضي ، وكما أشرت ، يعتمد الأمر كله على أمر التقييم .... وهو أمر لا معنى له أيضًا.

ومع ذلك ، عندما نظرت إلى الكود strictUnits ، لم يكن ذلك أيضًا منطقيًا بالنسبة لي. هذا أيضًا لا يبدو أنه يفعل ما اعتقدت أنه سيفعله.

حسنًا ، هذا غريب ، لكنني لا أميل إلى رؤيته ثابتة. أنا أكثر ميلًا لرؤية الرياضيات المختلطة تختفي. لكن هذا أنا فقط. مثل نتيجة 1px * 1px يجب أن تكون 1px^2 (ليست مفيدة ، لكنها صحيحة). ويجب أن تكون نتيجة 1px / 1px 1 . يعتبر Sass شديد التعقيد فيما يتعلق ببعض أنواع الرياضيات ، لكنه يستخدم مبادئ الرياضيات الأساسية للقيام بأشياء مثل تبديل وحدات وحدات المزج. فمثلا.

<strong i="13">@value</strong> / 1px * 1rem
الرياضيات هنا هي 10px / 1px . يجب أن ينتج هذا 1 (ليس بأقل ، فقط من حيث المبدأ ، وسيقوم في Sass). 1 * 1rem = 1rem . لا توجد إهانة لأليكسيس في أصول هذه الميزة ، ولكن اختيار الوحدة الأولى من التعبير هو أمر غريب نوعاً ما ، ويصعب تقييمه ، ويمكن أن يؤدي إلى هذه الحالات ذات الأخطاء الفائقة.

فقط 0.02 دولار.

أعتقد أن ما يجب أن يحدث هو أنه ، مثل التغييرات في الرياضيات ، هناك تغيير في الوحدات المختلطة بحيث يكون هناك خيار ثالث بين الاثنين:

1. strictUnits: false - حاول القيام بوحدات الرياضيات والإكراه
2. strictUnits: ? - على سبيل المثال 1px / 1px // output 1 ، 100vh - 10px // output 100vh - 10px سبيل المثال مع الوحدات المختلطة ، اترك التعبير كما هو والإخراج - مفيد للتعبيرات الفرعية المخصصة لـ vars والمستخدمة في calc () - الافتراضي في المستقبل؟
3. strictUnits: true - حدث خطأ (لا أرى فائدة ذلك.)

القضية لا تتعلق بالآراء الشخصية للوحدات / التعامل مع الحساب. يتعلق الأمر بعدم اتباع المترجم لوثائقه الخاصة. (للبقية انظر على سبيل المثال https://github.com/less/less.js/issues/1366#issuecomment-342361948).

القضية لا تتعلق بالآراء الشخصية للوحدات / التعامل مع الحساب. يتعلق الأمر بعدم اتباع المترجم لوثائقه الخاصة

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

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

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

وحدات صارمة:؟ - على سبيل المثال 1px / 1px // output 1 ، 100vh - 10px // output 100vh - 10px

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

لاحظ أنه لجعلها عامة حقًا (على عكس ترميز هذه القيم / أنماط العمليات / الأمثلة البسيطة) ستحتاج إلى التعامل بشكل صحيح مع جميع التكافؤات الحسابية المعتادة وبالتالي تقديم وحدات "وهمية" مثل px² و مماثل. على سبيل المثال ، بالنسبة إلى a: 1px; b: 2px; c: 4px; فإن النتيجة المتوقعة لـ a*b/c (من الواضح أن قبول (a*b)/c = a*(b/c) ) ستكون .5px مما يعني أن نتيجة a*b يجب أن تكون 2px² (داخليًا على الأقل).

هناك مخاوف أخرى تتعلق بالتنفيذ (من الواضح أنه قد يبدو من الغريب أيضًا حساب أشياء مثل 1/1hz = 1s وما إلى ذلك ولكن رسميًا ...) العد بالسنت: لقد قلت CSS Units هو مجرد دب كبير جدًا لإثارة الأمر بدون سبب (" فقط لأن شيئًا مثل 1px/1px = 1 يبدو بديهيًا").

rictUnits: صحيح - طرح خطأ (لا أرى كيف يكون هذا مفيدًا.)

بشكل أساسي ، إذا كان المرء لا يحب انتشار الوحدة و / أو الوحدات المختلطة ، فقد يقدم أسلوب تشفير أكثر صرامة لا يسمح بمثل هذا الحساب (وبالتالي فإن strictUnits: true هو في الأساس خيار لفرض أسلوب الترميز هذا).