يعجبني هذا. يعد تقليل حجم الحزمة وخاصية "الفئة" من التغييرات التي ستحظى بترحيب كبير.

عمل عظيم!

🙂

انتباه مؤلفي مكتبة النموذج! 🤣

رائعة!

className → فئة رائعة

ماذا عن كل الآخرين؟ يبدو غريبًا أنك ما زلت تقوم بعمل clipPath ، htmlFor ، tabIndex ، إلخ.

يعد اعتماد class إنجازًا كبيرًا في جعل المكتبة أكثر ملاءمة للمبتدئين. تهانينا.

هذا رائع. لدي فضول شديد حول كيفية الانتقال إلى class في الواقع مع الدعائم.

يبدو أن ({ class }) => <div class={class} /> سيقدم في البداية مشكلة كلمات رئيسية محجوزة؟

هذه أخبار رائعة ، شكرًاgaearon!

أحب كل هذه النقاط ، باستثناء تغيير className . يبدو متناقضًا تمامًا مع الهدف الذي تسعى إليه النقاط الأخرى (التوافق مع واجهة برمجة تطبيقات DOM). ترتبط React بخصائص DOM ، وليس سمات HTML (حتى أن هذا تم توضيحه في النقطة الأولى). تم تسمية خاصية عنصر DOM باسم className ، وليس class . فلماذا يتم تسميته class في React؟

جميل! هل لديك هدف لتقليل حجم الحزمة؟

👏

ماذا عن كل الآخرين؟ يبدو من الغريب الاستمرار في عمل ClipPath و htmlFor و tabIndex وما إلى ذلك.

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

أعتقد أن إعادة كتابة نظام الأحداث هو الجانب الأكثر إثارة للاهتمام في هذا. هناك فرصة كبيرة لتقليل حجم الحزمة وتسهيل مساهمات المجتمع.

دعنا نقوم به!

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

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

ومع ذلك ، إذا مررنا زوج مفتاح / قيمة غير معروف ، فسيتم التعامل معه كسمة منذ React 16. لذلك نحن بالفعل غير متسقين. أيضًا ، كان تعليقي حول خطأ المستخدمين في توقع قيام React بتعيين السمة value . سواء كانت React API تستخدم اسم السمة أو اسم الخاصية في واجهة برمجة التطبيقات الخاصة بها ، فهذا أمر متعامد كليًا.

لقد دافعت عن جانبك من هذه الحجة لسنوات ولكني أعتقد الآن أن هذا احتكاك لا يستحق كل هذا العناء. أنت لا تكسب أي شيء منه. مجرد السماح للأشخاص باستخدام class ليس له آثار سلبية باستثناء أنه لا يعمل مع التدمير ، وتكلفة الترحيل. يشتكي الجميع من ذلك عندما يتعلمون React. أعتقد أن القيام بما يتوقعه الناس في هذه الحالة أكثر أهمية من التحذلق. وبما أننا نغير أشياء أخرى في DOM على أي حال ، فلنجمعها معًا.

طالما أن React Fire مشتعلة بسرعة .... 👍

كل هذه التغييرات رائعة. أنا متحمس جدًا لهذا الأمر وآثاره على react-testing-library . على وجه الخصوص ، الأحداث المرتبطة بجذر التفاعل (أو ربما حتى إسقاط تفويض الحدث تمامًا لأنه قد لا يكون ضروريًا في البيئات الحديثة بعد الآن؟) ، ومن المحتمل إزالة / إعادة كتابة الأحداث الاصطناعية ، و onChange -> onInput سيحسن بشكل جدي تطبيق react-testing-library والخبرة في استخدام الأداة.

أرغب في تقديم ملاحظات حول هذا أثناء تنفيذه.

ربما حتى إسقاط تفويض الحدث تمامًا لأنه قد لا يكون ضروريًا في البيئات الحديثة بعد الآن

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

tannerlinsley ({ class: className }) => <div class={className} /> لسوء الحظ ، سيؤدي هذا إلى قتل تدوين كائن jsx 2.0 المختصر ( <div class /> ) ، لكن فليكن ...

سيكون من الرائع جدًا أن يأخذ class كائنات ومصفوفات بالمناسبة إلى جانب السلاسل.

هل لديك هدف لتقليل حجم الحزمة؟

سيكون إسقاط ثلث React DOM أمرًا رائعًا. سوف نرى. من الصعب القول مبكرًا لكننا سنبذل قصارى جهدنا.

رائع ، هذا تعداد لجميع قرارات التصميم التي أذكرها تقريبًا عندما يسألني الناس عن سلبيات React.

أحب الاتجاه الذي يسير فيه هذا.

ماذا سيكون مسار الترقية للمكتبات التي تستخدم className وتريد دعم إصدارات متعددة من React؟

gaearon ربما ليست مشكلة كبيرة ، اليوم من الجيد أن نقول "الخاصيات هي خصائص DOM وليست سمات HTML" ، الآن سيكون "باستثناء className ، هذا هو اسم HTML". أود أيضًا أن أكون قادرًا على نسخ / لصق SVG مع 10 دقائق من العبث بالسمات لتتوافق مع React

ماذا عن htmlFor ؟

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

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

أتفق معfelixfbecker
كل شيء يبدو رائعًا وسيحسن الجودة لكل من المطورين والمستخدمين ، ولكن يتغير اسم الفئة.

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

felixfbecker يمكن أن يكون class / for في JSX و className / htmlFor في إصدار JS؟

<label class="foo" for="bar">..</label>

سيكون

React.createElement('label', {className: 'foo', htmlFor: 'bar'}, '..')

خطة رائعة! جميل أن هنا! 👏👏👏

هذا رائع ، لا أطيق الانتظار للبحث في الأشياء الجديدة.

قم بتبسيط نظام الأحداث بشكل جذري (# 4751).

لا يمكن الآن رد فعل تفويض المعالج إلى عناصر مخصصة ، بدون توسيع تعريف ReactDOM. https://github.com/facebook/react/issues/9242

هذا يعني أن React لا يمكنها تعيين معالج مخصص على عنصر مخصص مثل <x-component onMyEvent={ev => {...}} />

تضمين التغريدة
هل لديك أي خطة بخصوص هذا؟

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

يمكننا الحصول عليها كلها!

إعادة كتابة تفويض الحدث تفتح الباب لإصلاح # 1254 ؛ حيث تتدهور بعض الأحداث بشكل مثالي للعقدة المرتبطة بها (وهو ما يعني بالنسبة إلى React التطبيق بأكمله).

أيضًا ، كصورة بعيدة ، هل فكرت في امتلاك مجموعة بيانات تركيبية؟ عدم القدرة على كتابة خاصيات HTML المسموح بها (بسبب data- *) يؤدي إلى عدد كبير من الأخطاء عند إعادة توجيه الخاصيات إلى عُقد DOM. يجب أن تختار مكونات React المكتوبة حاليًا بين الأنواع الدقيقة للدعامات والسماح بسمات البيانات.

أنا متحمس

ryanflorence بعيد بعض الشيء ولكن من المحزن أن لا أحد (على حد علمي) لديه فكرة إنشاء html / css / svg -> jsx transfomer من أجل تسهيل عمليات الترحيل للتفاعل مع العديد من التغييرات التافهة على خريطة HTML Attrs إلى رد فعل الدعائم. الكثير من ساعات العمل المهدرة في تنفيذ البحث والاستبدال:

من الغريب جدًا رؤية ما يلي في نفس العدد (والتعليقات):

هدفنا هو جعل React متوافقة بشكل أفضل مع طريقة عمل DOM
className → فئة
يبدو من الغريب الاستمرار في عمل ClipPath و htmlFor و tabIndex وما إلى ذلك.

عندما تكون كل هذه النظائر المباشرة لواجهات برمجة تطبيقات DOM

وهذه الحجة لا تمر بحشد:

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

لطالما كانت React مجرد طبقة رفيعة جدًا أعلى JS. لذلك كان كل شيء آخر إلى جانب أقواس زاوية JSX هو JS _ و_ له نظير مباشر في واجهات برمجة تطبيقات DOM للأشياء المرتبطة مباشرة بـ DOM: className ، clipPath ، htmlFor ، tabIndex إلخ إلخ.

مع قرار تقديم class تتوقف React عن كونها طبقة رقيقة ( class كلمة محجوزة في JS) وتبتعد عن الهدف المعلن المتمثل في أن تكون أكثر توافقًا مع واجهات برمجة تطبيقات DOM.

من المزعج بشكل خاص أنك تريد "الترحيل من onChange إلى onInput" لأنه لا يتوافق مع DOM _ و_ يصبح غير متوافق مع DOM من خلال ترحيل className -> class .

بالإضافة إلى ذلك ، هذا يفتح علبة كاملة من الديدان ، حيث سيطلب الناس (ويطالبون بالفعل) بتغييرات لأجزاء أخرى. فقط في التعليقات: لماذا نستخدم dataset بدلاً من data-* ؟ ربما لأن data-* غير صالح JS (يشبه إلى حد كبير class ) ولأنه متوافق مع واجهات برمجة تطبيقات DOM ؟ لماذا لا نقوم بتغيير htmlFor ؟ لأن for كلمة محجوزة و htmlFor موجودة في واجهات برمجة تطبيقات DOM؟ إلخ إلخ.

ومع ذلك ، إذا مررنا زوج مفتاح / قيمة غير معروف ، فسيتم التعامل معه كسمة منذ React 16. لذلك نحن بالفعل غير متسقين.

gaearon وهو أيضًا سبب كون React هي المكتبة الوحيدة التي حصلت على نتائج سيئة في اختبار التشغيل المتداخل CustomElements Everywhere: https://custom-elements-everywhere.com/
وهناك العديد من المشكلات التي تطلب تغييرها: https://github.com/facebook/react/issues/11347 ، https://github.com/facebook/react/issues/7249 ، https://github.com/facebook / رد فعل / قضايا / 9230

قد لا تكون هذه مشكلة ، ولكن هل تشابه React Fire مع React Fiber سيكون مربكًا لغير الناطقين باللغة الإنجليزية؟ غالبًا ما اعتقدت أن محطة Newark Penn Station ومحطة New York Penn Station على نفس خط القطار هنا في مدينة نيويورك كانت مزحة قاسية بشكل خاص على السياح.

إذا كان هذا مصدر قلق حقيقي ، فيمكنك تسميته React Flame ولا يزال يحتفظ بالنار 🔥 emoji.

إعادة كتابة تفويض الحدث تفتح الباب لإصلاح # 1254 ؛ حيث تتدهور بعض الأحداث بشكل مثالي للعقدة المرتبطة بها (وهو ما يعني بالنسبة إلى React التطبيق بأكمله).

إن إصلاح # 1254 بشكل ما هو بالتأكيد شيء أرغب في رؤيته.

أيضًا ، كصورة بعيدة ، هل فكرت في امتلاك مجموعة بيانات تركيبية؟

لا أريد الالتزام بشيء كهذا الآن لأن هناك سطحًا أكبر. واجهة أكثر ثراءً لـ DOM ( ariaSet ، dataSet ، classList ) تبدو منطقية ولكن ليس من الواضح كم نريد استثمار ذلك في React DOM ، مقابل مكتبة ذات مستوى أعلى يمنحك واجهة برمجة تطبيقات DOM أكثر ثراءً. نظرًا لأن هذه التغييرات أكثر تجميلية ولكن لها مساحة سطح عالية ، فإنني سأمتنع عنها.

رد فعل النيران 🔥

ryanflorence بعيد بعض الشيء ولكن من المحزن أن لا أحد (على حد علمي) لديه فكرة إنشاء html / css / svg -> jsx transfomer من أجل تسهيل عمليات الترحيل للتفاعل مع العديد من التغييرات التافهة على خريطة HTML Attrs إلى رد فعل الدعائم. الكثير من ساعات العمل المهدرة في تنفيذ البحث والاستبدال:

تضمين التغريدة
https://transform.now.sh/html-to-jsx/

متحمس جدًا للتغييرات الجديدة ، أنتم البشر من Facebook تصنعون التاريخ بهذه الهجرة. هل سيتم ترحيل مكونات 50 كيلو بايت إلى React Fire؟
يجب أن تكون مجموعات الاختبار الخاصة بك ضيقة جدًا <3

هل التشابه بين React Fire و React Fiber سيكون مربكًا لغير الناطقين باللغة الإنجليزية؟

ربما للأشخاص ضعاف السمع أيضًا (أو أولئك الذين يعانون من ظروف أخرى تؤثر على تمييز الكلمات)

شكرًا لمشاركة gaearon ، هذا مذهل!

أرغب في رؤية إصدار JSX 2.0 يحل مشكلة المساحة البيضاء والخطوط الجديدة التي تحدث عندما نقوم بتجميع الكود الخاص بنا باستخدام Babel و Typescript.

تم فتح مشكلات مختلفة وحاولت المساهمة ولكن تم إخباري لأن فريق React يحتاج إلى مراجعة كل شيء حول JSX.

تتعلق هذه المشكلة بـ dom على أي حال ، لأن الطريقة التي نترجم بها jsx إلى js لا تسمح بما يقوله w3c.

هذه هي المشكلة https://github.com/facebook/jsx/issues/19

تعليقي في النهاية.

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

هل يمكن لشخص ما أن يوضح كيف يؤثر ذلك على المتعاملين الحاليين؟

توقف عن عكس قيم الإدخال في سمة القيمة

هل سيظل React يتحكم في المدخلات باستخدام تحديثات دقيقة event.target.value في المعالجات ، أم أن هذا لا يؤثر إلا على قيم القراءة من المراجع وعقد DOM؟

nickmccurdy يؤثر على ما تراه في أدوات تطوير المتصفح

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

لطيف - جيد! أنا في انتظار رؤية قائمة كاملة بالتغييرات في React 17.
أعتقد أنه سيكون حقبة جديدة من ReactJS. 🔥⚛️

@ تومديل هم: الغزل والألياف والنسيج ؛ ربما يمكن استخدام مصطلح آخر متعلق بالملابس؟ 😆

ومع ذلك ، إذا مررنا زوج مفتاح / قيمة غير معروف ، فسيتم التعامل معه كسمة منذ React 16. لذلك نحن بالفعل غير متسقين.

gaearon وهو أيضًا سبب كون React هي المكتبة الوحيدة التي حصلت على نتائج سيئة في اختبار التشغيل المتداخل CustomElements Everywhere: https://custom-elements-everywhere.com/

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

هل التشابه بين React Fire و React Fiber سيكون مربكًا لغير الناطقين باللغة الإنجليزية؟

كلاهما اسمان داخليان ولا يحملان أي أهمية بمجرد اكتمال المشاريع. يُعد React Fire مجرد محاولة لجعل React DOM أفضل - وبحلول الوقت الذي يصبح فيه جاهزًا للإنتاج ، سيكون مجرد React DOM.

هل سيظل React يتحكم في المدخلات من خلال تحديثات event.target.value الدقيقة في المعالجات ، أم أن هذا يؤثر فقط على قيم القراءة من المراجع وعقد DOM؟

نعم ، لأن event.target.value خاصية . نحن نتحدث عن إيقاف تحديث السمات . وهو ما لا تقوم به أي مكتبات شعبية أخرى (AFAIK) والذي يسبب مشاكل لا حصر لها. لا ينبغي أن يؤثر على شفرتك إلا إذا كنت تعتمد على محددات CSS على القيمة (والتي ربما تكون سيئة على أي حال).

لطيف - جيد! أنا في انتظار رؤية قائمة كاملة بالتغييرات في React 17.

لاحظ أننا لا نلتزم بأن نكون جاهزين بحلول 17. قد يكون 18 أو 19. 😅

من الجيد أن ترى تطورًا ثابتًا في مكتبة جيدة مثل React. 🎉 class سيجعل قابلية الاستخدام أفضل بكثير ، الأمر يستحق كل هذا العناء

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

العناصر المخصصة والعادية هي مسارات رمز منفصلة تمامًا

هذا في حد ذاته يبدو وكأنه شيء يجب إصلاحه أيضًا. هل هناك سبب لعدم معاملة جميع العناصر بالطريقة نفسها؟ هذا هو الهدف من مواصفات HTML و DOM.

justinfagnani كما تمت مناقشته سابقًا ، كان سبب عدم قيامنا بذلك في ذلك الوقت هو عدم وجود اتفاقية حول كيفية تحديد ما إذا كان يجب تعيين خاصية أو سمة - وكان هناك خطر أنه باستخدام شيك ، فإننا نجازف بجعله من المستحيل على منصة الويب إضافة خصائص جديدة إلى النموذج الأولي. أعتقد الآن أن هناك نوعًا من الإجماع في طلبات التعليقات (RFCs) والعلاقات العامة ( PRs ) الذي عمل @ robdodson عليه ، ويمكننا على الأرجح الحصول عليه من هناك.

👍 🔥 🔥 🔥

يجب أن تسمح لنا React Fire أيضًا بتطبيق بعض تحسينات الأداء الذكية التي تمتلكها Inferno - ولكن لم نتمكن من تطبيقها بسبب التغييرات العاصفة. أوقات مثيرة :)

LGTM

فيما يتعلق بإعادة تسمية className -> class المقترحة: أحب خاصية classes التي تأخذ مصفوفة من السلاسل. سيوفر لي ذلك عناء الكثير من التلاعب بالسلسلة (أو استخدام أسماء الفئات) في مكوناتي .

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

gaearon هل لديك خطط للتوافق مع الإصدارات السابقة؟ ربما تتبع نفس مسار React Fiber ، مع إضافة تحذيرات حول التغييرات وإعطاء الوقت لتحديث قواعد البيانات الكبيرة دون فقدان التحديثات الجديدة.

https://www.youtube.com/watch؟v=F1U0qvtQnE8

بخصوص class و className .

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

يجب أن تشعر واجهة برمجة التطبيقات الخاصة بالمكون بأنها اصطلاحية

هناك حجة شائعة مفادها أن React "يطابق JavaScript" وبالتالي يُفضل className . أعتقد أن هذا التأكيد أسيء فهمه بمهارة لذا أود التركيز عليه قليلاً.

في React ، أولاً وقبل كل شيء ، نهتم بأن استخدام مكون React يجب أن يكون مثل JavaScript اصطلاحي . هذا يعني أنني إذا استخدمت مكونًا افتراضيًا <Table> ، فأنا أتوقع أن تكون دعائمه عبارة عن حالة camelCase:

<Table
  rowHeight={10}
  headerBorderInset={5}
  renderRow={this.renderRow}
/>

لا أتوقع رؤية أسماء خاصة مثل row_height أو row-height في واجهة برمجة التطبيقات العامة للمكون . تعتبر دعائم المكوّن كائنًا (نوعًا ما مثل "حقيبة خيارات") ، ونتوقع عمومًا أن تكون هذه الخيارات camelCase . قد لا يكون هذا دائمًا اصطلاحيًا في DOM ، لكن DOM ليس متسقًا جدًا في العديد من الأماكن. تتماشى React مع نظام JavaScript البيئي الذي يستخدم بأغلبية ساحقة camelCase .

لكن ماذا عن DOM؟ هذا هو المكان الذي يصبح فيه الشائك.

خصائص DOM ليست مجرد "سمات في JS"

في DOM ، لدينا سمات وخصائص. السمات هي الأشياء التي تراها عادةً في HTML. الخصائص هي الأشياء التي عادة ما تقوم بتعيينها من JS. ولكن الأهم من ذلك ، أن واجهات برمجة تطبيقات DOM موجودة لتعيين الخصائص ولإعداد السمات - وهي لا تقوم دائمًا بتعيين نفس الشيء.

node.value = 10; // setting a property
node.setAttribute('value', '10'); // setting an attribute

في كثير من الحالات لا يهم. في بعض الحالات يحدث ذلك. لكن ربما ليس بالطريقة التي قد يفكر بها المرء من استخدام React (التي لها تجريد واحد فوق كليهما).

رد الفعل ليس مجرد تعيين الخصائص

هناك اعتقاد خاطئ شائع أنه نظرًا لأن React تستخدم حاليًا اصطلاح camelCase لمعظم عناصر DOM ، فهذا يعني أن React تُعيِّن خصائص DOM. هذا خطأ.

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

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

مع ذلك ، دعنا نستخدم أسماء الخصائص فقط؟

حسنًا ، الخصائص والسمات هي تفاصيل تنفيذ. ولكن لماذا لا نكتفي بالتوحيد القياسي على استخدام أسماء خصائص DOM لأن تلك الأسماء مصممة خصيصًا لـ "JavaScript"؟ أليست هذه هي الطريقة التي صُممت بها React API اليوم؟

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

<div
  tabIndex={1}
  data-id="123"
  aria-live="polite"
  nopin="nopin"
  itemType="http://schema.org/Movie"
  onClick={function() { alert('hi') }}
/>

ومن المفارقات ، أن الخاصية الوحيدة المذكورة أعلاه التي تحتوي على خاصية DOM فعلية بنفس الاسم المطابق لها ( tabIndex إذا لم تكن متأكدًا) يتم تعيينها بالفعل بواسطة React كسمة!

لذا من خلال هذه النقطة ربما ترى أنها ليست واضحة ولا متسقة. في بعض الحالات ، لا توجد الخصائص (مثل السمات المخصصة وغير القياسية) ، وفي بعض الحالات يمكن أن توفر React واجهة برمجة تطبيقات أكثر ثراءً ( data- مقابل dataSet ) لكنها ليست كذلك حاليًا.

في بعض الحالات ، يختار React الانحراف عن قصد ( onClick في React مقابل onclick DOM property) لأنه أكثر منطقية لمكونات React المخصصة. هذا لأن مكونات React غالبًا ما تعرض معالجات أحداث أكثر تعقيدًا مثل onItemClick . سيكون غير متسق للغاية إذا كتبت <Button onclick> لكن <Table onItemClick> . و <Table onitemclick> ليس camelCase ، وهو ما أردنا تجنبه في واجهة برمجة التطبيقات المكونة.

أعلاه ، أوضحت أن React بالفعل غير متسق بشأن "استخدام اسم خاصية DOM دائمًا" ، وأن React لا تستخدم بالفعل الخصائص داخليًا (لذلك لا تصف هذه القاعدة الأساسية الميكانيكا الفعلية أيضًا) ، وهذا في كثير من لا توجد خصائص DOM للحالات ، لذا علينا الالتزام بالسماح باسم السمة.

إذا لم تكن أسماء الخصائص ، فلنكن متسقين ونستخدم أسماء السمات؟

فلماذا لا تستخدم أسماء السمات فقط ؟ قد يكون هذا معقولاً. لكننا الآن نلتفت إلى الاعتبار الأول الذي طرحناه. يجب أن يبدو استخدام مكون React وكأنه JavaScript اصطلاحي . ولكن غالبًا ما تقوم المكونات بإعادة توجيه بعض الدعائم على الأقل إلى عنصر DOM الأساسي.

<Button
  borderColor='red'
  tabIndex={1}
 />

 // renders...

 <button
   tabIndex={1}
/>

سيكون أمرًا محرجًا بالنسبة إلى Button المخصص لقبول الدعائم ذات الأحرف الكبيرة غير المتسقة:

<Button
  borderColor='red'
  tabindex={1}
 />

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

أعتقد أن هذا هو السبب الأساسي الذي يجعله مرغوبًا في الدعائم مثل tabIndex ، cellSpacing ، ومعظم الدعائم الأخرى ذات الصلة بـ DOM لاتباع اصطلاح حالة الجمل. ذلك لأنهم ينتهي بهم الأمر غالبًا في واجهات برمجة التطبيقات المكونة.

نريد أن نجعل من السهل على المكونات المخصصة مثل Button التفافها وإعادة توجيهها بدون "ترجمتها" إلى اسم السمة عند النقطة التي تتدفق فيها إلى DOM ، وبدون إدخال عناصر non-camelCase في مكون مخصص API.

يفسر هذا أيضًا سبب اعتبار العناصر مثل data-* و aria-* والسمات المخصصة استثناءات معقولة (على الرغم من أنه يمكننا إنشاء واجهات برمجة تطبيقات أكثر ثراءً لها). نادرًا ما يتم تمريرها إلى المكونات المخصصة. عادةً ما تكون مقترنة جدًا بـ DOM لتكون مفيدة في المكونات المخصصة - وبدلاً من ذلك ، تصبح تفاصيل تنفيذية لشيء مثل <Modal> أو <Button> مع واجهة برمجة تطبيقات camelCase أكثر ثراءً.

لا تتطابق خصائص React بالفعل مع خصائص DOM

إذا لم تنجح اتفاقية "اسم خاصية DOM" ، فنحن بحاجة إلى شيء آخر. ما هذا؟ هل يمكن أن يكون "إصدار حالة الجمل لاسم السمة"؟ يبدو أن هذا يتم التحقق منه دائمًا تقريبًا.

إذا كان هذا يبدو جذريًا للغاية ، ففكر في أننا نقوم بذلك بالفعل. نحن ندعم ما يسمى srcSet . لكن اسم خاصية DOM الخاص بها هو srcset . لدينا autoCapitalize لكن خاصية DOM تسمى autocapitalize . لدينا autoFocus لكن خاصية DOM هي autofocus .

نحن بالفعل ننحرف عن أسماء خصائص DOM عندما لا تتطابق مع اصطلاح JavaScript camelCase. وهو ما يقودنا إلى class .

أخيرًا: className مقابل class

جزء من التبرير الأصلي لجعله className يرجع إلى أن React كان يُعيِّن خصائص DOM ، و className هو اسم خاصية DOM.

ومع ذلك ، كما أوضحت أعلاه ، لم تعد React تستخدم الخصائص باستثناء ثلاث أو أربع حالات خاصة. والأهم من ذلك ، أن React لا تستخدم حتى أسماء خصائص DOM باستمرار - بل إنها تستخدم أسماء تبدو طبيعية عند استخدامها من JavaScript ، بغض النظر عن عدم اتساق التسمية الداخلية في أي من سمات DOM وأسماء الخصائص. وذلك لأن React تهتم كثيرًا بالاحتفاظ بأسماء الدعامات للمكونات المخصصة "JavaScripty". بهذا المعنى ، فإن tabindex ليس "JavaScripty" - لكن كلاهما class و className كذلك.

حجة أخرى ضد class في وقت مبكر هي أن الكود مثل هذا لم يكن صالحًا ES3 (مناسب لـ IE8):

// Not valid in ES3
// Valid in ES5
var props = { class: 'foo' };

لكن معظمهم لا يكتبون ES3 بعد الآن. إما أنك تستخدم سلسلة أدوات مثل Babel أو من المحتمل أنك تستهدف IE9 + - لا تدعم React حتى IE8 الآن.

لذا فإن الإزعاج الوحيد المتبقي مع class هو أنه لا يمكنك كتابة هذا:

// Not valid at all :-(
const class = props.class;
const { class } = props;

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

// Valid
const {class: cls} = foo;
const cls = props.class;

أليس هذا الكثير من الجهد.

عادةً ما يمرر الأشخاص class إلى الأسفل كثيرًا أكثر من قراءته لأن العديد من المكونات تحتوي على أكثر من <div> أو عناصر مضيفة أخرى. لذلك ينتهي بك الأمر بكتابة <div className> أكثر بكثير من الرغبة في إتلاف class . وبالتالي فإن التغيير إلى class سيوفر المزيد من الكتابة على لوحة المفاتيح أكثر مما قد يقدمه.

هناك نقطة أخرى مهمة هنا.

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

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

// Valid in ES2018

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

وإذا لم تكن بحاجة إلى تعديله ، فبإمكانك فقط إعادة توجيه {...rest} بدون قراءة class منه. لذلك قد يساعد تقييد التدمير في تشجيع تصميم أفضل للمكونات.

لماذا ليس كلاهما؟

أخيرًا ، ألا يمكننا دعم كل من class و className ؟ بطريقة ما ، فعلنا ذلك بالفعل ، لكن React تصرخ عليك بتحذير. هناك سبب لهذا.

إذا دعمنا كليهما بدون تحذيرات ، فسينقسم المجتمع حول أيهما يستخدم. كل مكون في npm يقبل خاصية فئة يجب أن يتذكره لإعادة توجيه كليهما. إذا لم يتم تشغيل مكون واحد في المنتصف وقام بتنفيذ دعامة واحدة فقط ، فسيتم فقد الفصل - أو قد ينتهي بك الأمر بـ class و className في الجزء السفلي "عدم الموافقة" مع كل منهما أخرى ، مع عدم وجود وسيلة لـ React لحل هذا الصراع. لذلك نعتقد أن هذا سيكون أسوأ من الوضع الراهن ، ونريد تجنب ذلك.

ملخص

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

ما اعتدنا أن نراه على أنه سلبيات (غير متوافق مع خصائص DOM) هو موضع نقاش لأننا لم نقم بتعيين خصائص DOM بعد الآن ، ولا حتى نسعى جاهدين لتكون متسقة معها. بدلاً من ذلك ، نحن نهدف إلى أن يكون لدينا واجهة برمجة تطبيقات تستند إلى السمات ولكن من نوع camelCase على الجانب المستهلك من مكونات React - والتي نحن بالفعل متسقة معها تقريبًا. ومن الواضح أن class="Button" أكثر ملاءمة من className="Button" . في الواقع ، إذا تم تصميم DOM API اليوم ، فمن المحتمل أن تتيح لك تعيين خاصية .class على وجه التحديد لأن القيود المفروضة على استخدام class في مهمة مثل هذه قد تم رفعها في ES5 - منذ ما يقرب من عشر سنوات.

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

ملاحظة: قد يكون هذا منطقيًا بالنسبة لأسماء خصائص React الأخرى التي لا تطابق أسماء سمات camelCased.

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

هل لديك خطط للتوافق مع الإصدارات السابقة؟ ربما تتبع نفس مسار React Fiber ، مضيفًا تحذيرات حول التغييرات وإعطاء الوقت لتحديث قواعد البيانات الكبيرة.

كما لاحظت:

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

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

re: className -> class ، أنا رائع مع أي قرار ، يمكنني بالتأكيد رؤية استثناء لتغيير الفئة للمستخدمين الجدد ، وميزة جانبية لأسطر أقصر من التعليمات البرمجية. على الرغم من أنهم سيظلون بحاجة إلى التعرف على أسماء حالات الجمال الأخرى.

لذا فإن الإزعاج الوحيد المتبقي في الفصل هو أنه لا يمكنك كتابة هذا:

const { class } = props;

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

const class = props.class;

أليس هذا الكثير من الجهد.

شيئين (ربما صغيرين):

1. أليس const class = props.class JavaScript غير صالح؟ لم أكن أعتقد أنه كان كذلك ، وفي اختبار سريع لم يعجب Chrome. أيضًا ، تشير هذه المقالة إلى أنها غير صالحة.

2. يمكن أن أرى هذا التغيير (مرة أخرى ، من المحتمل أن يكون صغيرًا) منطقة إحباط للأشخاص الذين يكتبون مكونات مثل هذا: nvm (انظر التحديث أدناه)

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    className={someClassName}
    {...rest}/>
);

بعد هذا التغيير ، يجب أن يكون هذا شيئًا مثل ...

const { oneProp, twoProp, ...rest }  = this.props;

// do stuff with oneProp, twoProp, this.props.className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    {...rest}
    class={someClassName}/>
);

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

التحديث :

لا يهم،

const { class: className } = this.props;

عمل الحيلة.

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

لحسن الحظ ، يمكن تخفيف هذا بسهولة إذا كان المرء يستخدم نهج CSS-in-JS ، مثل Aesthetic. شكرا على الكتابة الرائعة!

نصيحة عشوائية بخصوص أسماء السمات ، لقد وجدت المشروع الممتاز ، svg2jsx رائع لتحويل SVGs الكبيرة لاستخدامها في React!

jamesplease آسف ، ذهني فارغ - أنت على حق. تم تحريره.

jamesplease أنت على حق. يأتي هذا أيضًا بشكل متكرر مع العمل مع JSON ، للقيمة الافتراضية ، أمر مزعج للغاية!

const { default: defaultVal } = property

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

سيكون className -> class تغييرًا هائلاً للنظام البيئي ، وستصبح العديد من المكونات غير الصالحة غير متوافقة ، ولن يكون هناك ما يمكنك فعله إذا لم تتمكن من تصحيحها. ربما لديك غلاف مثل StrictMode يعطل هذا التغيير للمكونات الأعمق في الشجرة لتوفير مسار ترحيل تدريجي؟

يمكنني أن أرى هذا التغيير (مرة أخرى ، من المحتمل أن يكون صغيرًا) مجال الإحباط للأشخاص الذين يكتبون مكونات مثل هذا:

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
 <div className={someClassName} {...rest}/>
);

فقط لا تدمرها.

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div
    {...rest}
    class={'something ' + rest.class}
  />
);

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

ما إذا كانت React تستخدم الخصائص أو السمات داخليًا هي تفاصيل تنفيذية

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

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

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

className -> ستكون الفئة تغييرًا كبيرًا للنظام البيئي ، وستصبح العديد من المكونات غير الصالحة غير متوافقة ، ولن يكون هناك شيء يمكنك القيام به إذا لم تتمكن من تصحيحها. ربما لديك بعض الغلاف مثل StrictMode الذي يعطل هذا التغيير للمكونات الأعمق في الشجرة لتوفير مسار ترحيل تدريجي؟

أوافق - وما زلنا نزن الإيجابيات والسلبيات. لم يتم الانتهاء من أي شيء.

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

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

بغض النظر عن قرارك ، هناك حجة أخرى ضد class وهي إمكانية البحث. كم عدد الإيجابيات الخاطئة التي ستمنحك البحث عن طريق class عندما تريد العثور على المكونات التي تستخدم فئات CSS في كود ES6 الذي يستخدم مكونات فئة JS؟ نعم ، يمكنك البحث عن class={ ، ولكن ماذا عن إتلاف العناصر في JSX التي تم إنشاؤها ككائن في JS؟ (أنا ضد الاستخدام المكثف لتدمير الدعائم لكنها لا تزال مستخدمة) بالطبع ، نحن بحاجة إلى أدوات بحث تعتمد على AST أكثر إدراكًا للسياق في محرري الكود ، لكن في الوقت الحالي لدينا فقط نصوص و regexp. بالطبع قد تساعد أنظمة الكتابة في تتبع مرور الكائنات ، لكن عددًا كبيرًا من السكان لم يعتمدها.

شيء ما حول استخدام كلمة محجوزة لا يناسبني ، حتى لو لم يسبب أي مشاكل الآن ؛ هل يمكننا أن نقول على وجه اليقين أن rest.class (على سبيل المثال) لن يكون مهمًا للغة في x من السنوات؟

GeordieP إذا كان يعمل اليوم فإنه لا يمكن كسر غدا. هذا هو المبدأ الأساسي لكيفية تطور JavaScript ، وسبب العديد من خصائصها المميزة.

gaearon عادل بما فيه الكفاية ، إذن. إذا كان فوزًا كبيرًا بما فيه الكفاية ، فأنا أقول إنطلق لتحقيقه.

sompylasar عادةً ما أبحث عن className= أو className: ، يبدو أن كلاهما سيعمل مع class أيضًا.

من فضلك تخلص من className ، ولله الحمد ، htmlFor . أنا لست مطور DOM ، وعادة ما يكون هناك شيء خاطئ للغاية إذا كان علي الوصول إلى طرق DOM الأصلية. التحدي الأكبر الذي أواجهه في إعداد الأشخاص لـ React هو التجريد الذي يصنعه JSX على DOM وسمات HTML البديلة الغريبة. يتم نقل كل شيء ، ولا داعي للقلق بشأن الكلمات المحجوزة في هذه المرحلة. IMO.

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

هل يستحق إنقاذ متعلمي React المبتدئين من اسم غير بديهي بعض الشيء أن يضطر كل شخص إلى تحديث مشروعاته وسلوكه؟

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

أيضًا ، ألا يستمر الخلط بين المبتدئين بسبب الكم الهائل من المواد (مثل المدونات / المستودعات / إلخ) التي تستخدم className حاليًا؟

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

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

بعيد قليلاً ولكن من المحزن أنه لم يكن لدى أي شخص (على حد علمي) فكرة إنشاء html / css / svg -> jsx transfomer من أجل تسهيل عمليات الترحيل للتفاعل مع العديد من التغييرات التافهة لتعيين أتباع HTML إلى رد الفعل الدعائم.

jxub - لقد أنشأت محول HTML إلى JSX كجزء من طريقة الهاكاثون في عام 2014: https://magic.reactjs.net/htmltojsx.htm. لست متأكدًا مما إذا كان يتعامل مع SVG جيدًا. كان مشروع hackathon هو إنشاء نص برمجي من شأنه "ajaxify" موقع HTML عادي باستخدام React (https://github.com/reactjs/react-magic) وجزء من ذلك يتطلب مني إنشاء طريقة لإنشاء مكون React من جزء كبير من HTML ، لذلك قمت بإصدار HTML إلى جزء JSX كصفحة مستقلة منفصلة.

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

gaearon - ما هي بعض الأمثلة على مكتبات واجهة المستخدم الحديثة التي لا تتعامل مع اختلافات المتصفح؟ بالنسبة لي ، هذا أحد الأسباب الرئيسية لاستخدام المكتبة.

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

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

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

سيكون من الرائع أن يكون دعم مستمعي الأحداث السلبية ضمن نطاق React Fire ، وهي ميزة مهمة على الهاتف المحمول.

6436

شكرًا لك على عملك الشاق في هذا الأمر ، ولكن يُرجى إعادة النظر في className -> class .

كنا جميعًا مبتدئين في React ولم يمنعنا className من تعلم React وحبها.

أتذكر عندما أستخدم vue مع jsx ، كان لديهم بالفعل class وليس className ، لا أوافق على ما إذا كان سيتم تغيير className إلى class ، لأن React رائدة في Virtual DOM ، وتمثل دومًا ذاتيًا.

قم بإرفاق الأحداث في جذر React بدلاً من المستند

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

وهو ما يأخذني إلى ملاحظة أخرى ، هل يمكننا فعل شيء react-dom/test-utils ؟ أنا مهتم بشكل خاص بالإزالة المحتملة لـ Simulate نظرًا لجميع المشكلات المرتبطة بها والتي نعرفها جميعًا ، وبالطبع قم بإجراء التغييرات اللازمة في react-dom نفسها بحيث لا تكون هناك حاجة إليها حقًا أي أكثر من ذلك. هل يمكن أن يكون ذلك في النطاق؟

/ cc @ kentcdodds

أنا أحب الاتجاه وعرض الصورة الكبيرة التي تتخذها React Fire. حتى الآن تبدو هذه تغييرات كبيرة للعمل عليها.

أحب معظم التغييرات التي تم الإعلان عنها ، لكني أشك في تغيير className .

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

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

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

رائعة

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

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

من حيث أقف ، إذا كنت تتخذ قرارًا حيث يكون جزء من التبرير "وتكتب شيئًا مثل ... ... ليس هذا _هذا_ مجهودًا أكبر بكثير." ، يجب أن يكون لهذا القرار _صاعد _ كبير ، و التغيير className -> class لا يُقارن بكل شيء آخر تم الإعلان عنه.

سيكون هذا تقدمًا كبيرًا في 🔥 React Fire

حول class v / s className ، أعتقد أننا يجب أن نذكر أنفسنا بأن JSX ≠ رد فعل.

نظرًا لأن JSX عبارة عن _DSL_ تم تصميمها لتبدو مثل HTML ، فمن الأفضل الاحتفاظ بها بالقرب من HTML قدر الإمكان. تم منحه اسم className في واجهة برمجة تطبيقات DOM ، لكن معظمهم يستخدمون JSX ربما لأنهم لا يريدون التعامل مع DOM API مباشرة.

إذا كان من المنطقي أن تتطابق واجهة برمجة تطبيقات React مع واجهة برمجة تطبيقات DOM بشكل وثيق ، فآمل أن يكون من الجيد / الممكن إجراء التعيين في الترجمة الشفوية:
<img src="avatar.png" class="profile" /> → React.createElement("img", { src: "avatar.png", className: "profile" }) .

سيكون من المفيد جدًا جعل بناء جملة JSX مجموعة شاملة من HTML.

ليضيف إلى ما قاله @ mhenr18 .

الوضع الحالي للأشياء:

• رد الفعل غير متسق
• API هو camelCase

الحالة المقترحة للأشياء:

• رد الفعل غير متسق
• API هو camelCase
• className -> class

الفوائد المرجوة:

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

السلبيات الفعلية:

• النظام البيئي بأكمله الذي يعتمد على className يتوقف عن العمل (جهد ترقية ضخم)
• تصبح المجموعة الهائلة من الكتب والبرامج التعليمية والأمثلة والرموز والمشاركات والمقالات غير صالحة إلى حد ما
• JS الصالحة الوحيدة المتبقية هي الكتابة الإضافية : const {class: cls} = props . تصبح كل حالة استخدام أخرى محتملة في JS العادية غير صالحة
• تظل واجهة برمجة تطبيقات React غير متسقة ، وتكسر المزيد من الافتراضات (لماذا htmlFor وليس for إلخ.)

إذا كنت مدير منتج ، فسيكون رد فعلي الفوري على التغيير: ماذا؟

gaearon ربما تكون قد فكرت في هذا بالفعل ، يرجى وضع علامة على العلاقات العامة مع "React Fire" أو كلمة رئيسية مشابهة.

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

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

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

من فضلك فكر في الأمر ، هل حقا يستحق ذلك؟

لقد كنت أستخدم babel-plugin-react-html-attrs لسنوات وكان يخدمني جيدًا ، ولا أعتقد أن إعادة تسمية className إلى class فكرة جيدة. يتم تحقيقه بشكل أفضل من خلال مكون إضافي مثل المكون الإضافي الذي ذكرته.

ألم يكن هناك مكون Babel الإضافي للتعامل مع الوضع " class v className " / " for v htmlFor "؟

آمل أن يكون من الممكن دعم سمات html كما هي مع الحفاظ على التوافق مع قرارات التسمية التي تم اتخاذها بالفعل.

حقيقة وجود ملحقات babel بالفعل لإجراء التحويل ، ربما تكون دليلًا على أنه يجب أن يكون من الممكن دعمها في مترجم JSX الأساسي نفسه. لكن جعلها مواصفات رسمية سيجعل الأمور أسهل بكثير ويمكن الاعتماد عليها للجميع.

لست على دراية بأجزاء React الداخلية ، لذا لا يمكنني التحدث كثيرًا عن الجدوى الحقيقية. فقط للتعبير عن كيف أعتقد أنه "يجب أن يكون" من حيث سهولة الاستخدام.

الرجاء إعادة النظر في className مقابل class . كما قيل أعلاه ، المكسب غير موجود تقريبًا ولكن هناك جوانب سلبية حقيقية.

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

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

أوه بالمناسبة ، إمكانية البحث ... تخيل أنك تبحث عن google لـ "React class" ، ستحصل على إشارات مختلطة: مكونات فئة React ، سمة فئة React. إذا كنت تبحث عن "React className" في google ، فستحصل على وثائق قديمة (الأشخاص المذكورون أعلاه يحصلون على القدر الهائل من أعمال الترقية من خلال هذا التغيير إلى جانب ترقيات الكود).

هل الهدف من هذا المشروع توليد المزيد من العمل للمجتمع والمزيد من الضوضاء والإشارات المختلطة للإنترنت؟ لا اتمنى.

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

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

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

sompylasar عادةً ما أبحث عن className = أو className: ، يبدو أن كلاهما سيعمل مع الفصل أيضًا.

أيضًا ، نتمنى لك التوفيق أثناء القيام بذلك مباشرة على جيثب = /

لقد قرأت كل التعليقات هنا. لا مانع من التغييرات ، لكن لست متأكدًا من class . السبب الرئيسي هو أنه لن يعمل مع خطط JSX 2.0. حول تدوين الاختصار (كما لدينا الآن في الكائنات).
كل شيء آخر يبدو أنه تحسينات لطيفة للغاية.
في انتظار القرار النهائي :) شكرا على جهودكم الرائعة يا رفاق!

ذكرت في أحد تعليقاتك "إذا كان يعمل اليوم ، فينبغي أن يعمل غدًا". ضع هذا في الاعتبار قبل أن أسأل ؛).

أحتفظ بمكتبة UI تسمى RMWC https://jamesmfriedman.github.io/rmwc/ والتي تستهدف جميع إصدارات React مرة أخرى إلى 15.4. لقد تمكنت من الحفاظ على سطح API موحد ، ولكن تغيير اسم الفئة إلى فئة ، والتغيير إلى onInput ، وإصلاح نظام الأحداث سيجعل هذا شبه مستحيل للاستمرار.

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

إذا لم يكن الأمر كذلك ، فأنا أتوقع أن تصبح الشفرة الغريبة الخاصة بي أكثر غرابة. 👀

إذا كان يجب تغيير className إلى class ، يرجى أيضًا تغيير htmlFor إلى for .
منذ class و for غير صالح في الأصل عندما نتلف props .

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

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

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

ملاحظة: كل شيء آخر يبدو رائعًا ، لا سيما مواد الأحداث

في انتظار التحديثات الجديدة

gaearon هل يجدر النظر في أن المثال الخاص بك:

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div class={'something ' + rest.class} {...rest}/>
);

يحتوي على خطأ ولن يعمل بالشكل الذي تتوقعه؟ قد لا يكون الأمر مباشرًا مثل "فقط لا تدمرها".

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

ومع ذلك ، فإن التحديثات مجانية وأنا أحب الهدايا المجانية.

هل أنا الوحيد الذي لم يكن مهتمًا بكون الفصل className؟

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

سيكون من الرائع أن يكون دعم مستمعي الأحداث السلبية ضمن نطاق React Fire ، وهي ميزة مهمة على الهاتف المحمول. # 6436

أنا موافق. إنه بالتأكيد في نطاق هذا العمل.

يا gaearon - أولا وقبل كل شيء شكرا.

هل فكرت في إجراء استطلاع من أجل جمع معلومات حول كيفية استخدام الأشخاص لردود فعلهم وما هي واجهات برمجة التطبيقات المستخدمة وما هو المربك؟

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

لقد وجدت أنه مفيد في المشاريع التي شاركت فيها شخصيًا (Node ، Bluebird ، إلخ).

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

هل فكرت في إجراء استطلاع من أجل جمع معلومات حول كيفية استخدام الأشخاص للتفاعل> وما هي واجهات برمجة التطبيقات المستخدمة وما هو المربك؟

أعتقد أن رد الفعل الأصلي لديه حذر .io لم أدرك أن رد الفعل لا يفعل ذلك

أحتفظ بمكتبة UI تسمى RMWC https://jamesmfriedman.github.io/rmwc/ والتي تستهدف جميع إصدارات React مرة أخرى إلى 15.4. لقد تمكنت من الحفاظ على سطح API موحد ، ولكن تغيير اسم الفئة إلى فئة ، والتغيير إلى onInput ، وإصلاح نظام الأحداث سيجعل هذا شبه مستحيل للاستمرار.

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

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

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

jamesmfriedman يجب أن يكون من الممكن (وليس معقدًا جدًا) التحديث (تلقائيًا) باستخدام كودمود) إلى واجهة برمجة التطبيقات الجديدة ثم (كجزء من عملية الإنشاء) التحويل (مرة أخرى باستخدام كودمود) إلى واجهة برمجة التطبيقات القديمة. ثم اشحن كلا الحزمتين واطلبهما ديناميكيًا بناءً على إصدار React.

هذا بعض العمل ولكن يمكن إجراؤه مرة واحدة (كمكوِّن إضافي webpack أو برنامج نصي لتثبيت npm على سبيل المثال؟) ولا ينبغي أن يكون صعبًا. أفترض أنه نوع الشيء الذي سيتم إصداره مرة واحدة واستخدامه في جميع المكتبات.

مثل طبقة توافق وقت الترجمة المخصصة للمكتبات.

أنا أؤيد إسقاط htmlFor لـ.

هل تعتقد أن إصدار الجسر الذي يدعم كلا من className والفئة سيكون فكرة جيدة؟ سيسمح للمطورين باستخدام رمز React الأقدم من جهة خارجية بينما يمكن أن يواجه رمز الطرف الأول الحالي الخاص بهم في المستقبل. بمجرد تحديث الطرف الثالث ، يكون الأمر سهلاً مثل إسقاط حزمة الجسر للحصول على React DOM مُحسَّن بالكامل.

تظل واجهة برمجة تطبيقات React غير متسقة ، وتكسر المزيد من الافتراضات (لماذا htmlFor not for وما إلى ذلك)

أعتقد أنك فاتتك الجملة الأخيرة عندما قلت for يجب أن يتغير أيضًا. ثم أعتقد أننا سنكون متسقين تمامًا مع "أسماء السمات ذات الغلاف الجمل" باستثناء سمة واحدة أو اثنتين من سمات SVG النادرة. الذي يمكننا تغييره أيضًا.

ألم يكن هناك ملحق Babel للتعامل مع الوضع "class v className" / "لـ v htmlFor"؟

أرى عددًا قليلاً من الإشارات إلى هذا لذا أود توضيح ذلك. لا يعد المكون الإضافي Babel مكانًا رائعًا لإجراء هذا التحويل لأنه لا يعمل في حالات مثل

const props = {
   class: "foo"
}
<div {...props} />

كما أنه ليس من المنطقي أن تمرر class لكنك تحصل على className في الدعائم الخاصة بالمكون. أو ، إذا كان المكون الإضافي يستهدف عناصر النظام الأساسي فقط ، فسيكون من الغريب أن يؤدي استبدال button بـ Button تغيير ما يتم تجميعه في الخاصية class .

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

حقيقة ممتعة: هذه هي الطريقة التي عملت بها نسخة قديمة جدًا من مترجم JSX. تمت إزالة هذا السلوك بسبب مدى إرباكه.

تغييرات رهيبة. . .

مدهش! شكرًا لجميع المساهمين على العمل لتحقيق هذه التحديثات المثيرة.
لم يكن لدي أي فكرة أن className > class كان فضيحة كبيرة. أنا شخصياً اعتدت على ذلك.

حجم الحزمة المنخفض وترقية نظام الأحداث يبدو واعدًا حقًا. أذكى سوبر!

أنا أتطلع حقًا إلى فصل polyfills لنظام الحدث كحزم منفصلة.
ولكن سواء كان className> class جذريًا جدًا ، كما تعلم ، فإن React لها تأثير واسع جدًا.
هل سيؤدي هذا إلى عدم توقع العديد من الأنظمة؟

سيكون إسقاط ثلث React DOM أمرًا رائعًا.

سيكون من الرائع استخدام React في تطوير تطبيقات الويب.

سيكون من الجيد أيضًا أن تتفاعل مساحة الاسم مع دعائم معينة مثل key و ref . على سبيل المثال

<Foo @key="foo" @ref={callback} prop="hi" />

تمت مناقشة هذا هنا - https://github.com/facebook/jsx/issues/66

elado على الرغم من أنه قد يكون شيئًا نريد القيام به في المستقبل ، أعتقد أنه خارج النطاق لأنه يؤثر على واجهة برمجة تطبيقات غير خاصة بـ DOM.

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

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

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

بخلاف ذلك ، فإنني أقدر حقًا الجهد المبذول في بناء React وصيانتها وترقيتها ، وشغف المهندسين وراءها :)

هذه {... التحديثات} المستقبلية هي 🔥

className -> class : لا أعتقد أنه موقف نادر عندما يتم تحديد سمة الفئة خارج JSX / تعريف الكائن. في مثل هذه الحالات ، سيتعين علينا استخدام تسمية مختلفة لنفس الشيء ، مما ينتج عنه عدم تناسق ، ويزيد من تعقيد الكود والحمل المعرفي.
لن يزيل التغيير المقترح عدم تطابق اسم السمة / الخاصية من قواعدنا البرمجية - سيكون موجودًا في مكان ما بسبب قيود البنية أو عند العمل مع DOM الأصلي. لقد كان أمرًا جيدًا أن يكون لدينا حل بديل "قياسي" (وراسخ جيدًا في هذه المرحلة) لمشكلة التسمية هذه.
حاليًا يمكن استخدام className باستمرار في كل مكان ، مع الإشارة دائمًا إلى نفس الشيء - حتى عند العمل مع DOM الأصلي. في الواقع ، قد يكون رد الفعل هو المكان الوحيد حرفيًا ، حيث سنضطر إلى استخدام class للإشارة إلى سمة الفئة.
بدا أن className غير ضروري تمامًا ومربكًا بعض الشيء منذ البداية ، ولكن تبين أنه عملي جدًا في وقت لاحق ومن السهل نسبيًا التعود عليه.

أود أيضًا التخلص من العنصر الإضافي { __html } مقابل dangerouslySetInnerHTML لأنه يبدو غير ضروري حقًا ، ولكن قد لا يستحق المشاكل المتعلقة بالترحيل (وربما لا علاقة له بهذه المشكلة تمامًا).

في حين أن التغييرات الأخرى تولد الكثير من المشاعر ، إلا أنها أكثر إثارة للاهتمام وأهمية ، لذا شكرًا لفريق fb على هذا الجهد.

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

من الناحية المثالية ، أود أن أكون في السيناريو التالي:

• مكتبة Downstream React تعيد كتابة التعليمات البرمجية على إصدار جديد ، مما يؤدي إلى إدخال خطأ لحالة الاستخدام الخاصة بي
• يضيف React ميزة جديدة رائعة / تقليل الحزمة
• تظل نسخة المكتبة القديمة قابلة للاستخدام على React الجديدة
• Yay يمكنني استخدام ميزة جديدة مباشرة بعد إطلاق React وانتظر فقط المكتبة لإصلاح الخطأ

من الناحية العملية ، فإن الأمر أشبه بما يلي:

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

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

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

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

(أيضًا شيء IE11 محزن لأنك تقوم بإيقاف متصفح ليس EOL - الإصدار الأخير منذ 52 يومًا. أعتقد أن فريق React سيجد أن هذا يدفع العمل إلى فريق Facebook وجميع فرق المكتبات الخارجية والداخلية للتخفيف من حدته في حين أن).

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

أود أيضًا أن أتخلص من الكائن الإضافي {__html} لخطيرةSetInnerHTML لأنه يبدو غير ضروري حقًا

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

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

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

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

كما أن شيء IE11 محزن لأنك تقوم بإيقاف متصفح ليس EOL - الإصدار الأخير منذ 52 يومًا.

لا أحد يقوم بإهمال IE 11. الإصدار الحالي لـ React يتطلب في الواقع polyfill لبعض الميزات في IE 11 ، لذلك من المحتمل أن يكون للتغييرات المقترحة نفس التأثير على تطوير IE 11. https://reactjs.org/docs/javascript-environment-requirements.html

أود أيضًا أن أتخلص من الكائن الإضافي {__html} لخطيرةSetInnerHTML لأنه يبدو غير ضروري حقًا

urugator - لما يستحق الأمر ، داخليًا في Facebook ، يتمثل الاستخدام الأكثر شيوعًا لـ __html في إدراج HTML الذي يعرضه الخادم في شجرة مكون React. بالنسبة لحالة الاستخدام هذه ، نقوم بإنشاء كائنات __html من جانب الخادم ، ولدينا قواعد منسقة تمنع القيام بذلك من جانب العميل. من جانب الخادم ، لدينا طرق تسلسل XHP إلى كائنات بخصائص __html . هذا يضمن أننا لا نقدم أي ثغرات أمنية في أي مكان ، لأن XHP يشبه إلى حد بعيد JSX (كان في الواقع مصدر الإلهام الرئيسي لـ JSX) ولديه أيضًا حماية XSS.

بشكل أساسي ، تشير كائنات __html إلى سلسلة من HTML نعلم أنه تم تعقيمها في مكان ما ومن الآمن إدراجها مباشرة في DOM. يصعب التعامل مع السلسلة الأولية - كيف يمكنك معرفة ما إذا كان قد تم تطهيرها أم لا ، أم لا إذا قام شخص ما بطريق الخطأ بإرجاع بعض مدخلات المستخدم الأولية (وبالتالي أدخل فتحة XSS)؟

لذا ، نعم ، من الصعب استخدامه عمدًا ، لأنه لا ينبغي أن يكون هناك العديد من حالات الاستخدام في معظم التطبيقات ، ويجب احتواء حالات الاستخدام بشكل معقول. بشكل عام ، لا يجب عليك إنشاء كائن __html مباشرة في مكون React الخاص بك ، بل يجب أن يكون لديك بعض الوظائف التي تقوم بإعادته (انظر كيف تستخدم المستندات الدالة createMarkup : https: // responsejs. org / docs / dom-element.html # seriouslysetinnerhtml)

ما يقلقني هو أن الأشخاص في Facebook يقللون من شأن القصور الذاتي والألم وتغييرات واجهة برمجة التطبيقات التي تكسر التجزؤ التي يمكن أن تسببها للنظام البيئي والمجتمع.

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

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

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

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

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

في حال كنت فضوليًا ، فلا يزال لدينا رمز مثل

React.PropTypes = require('prop-types')
React.createClass = require('create-react-class')

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

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

(أيضًا شيء IE11 محزن لأنك تقوم بإيقاف متصفح ليس EOL - الإصدار الأخير منذ 52 يومًا. أعتقد أن فريق React سيجد أن هذا يدفع العمل إلى فريق Facebook وجميع فرق المكتبات الخارجية والداخلية للتخفيف من حدته في حين أن).

لا أفهم ما تشير إليه. لم أقل في أي مكان تم "إهماله" في IE11.

تقول رسالتي فقط أننا قد نحتاج إلى المزيد من polyfills أكثر من الآن لمتصفحات مثل IE11. تتطلب React بالفعل بعض polyfill في IE11. أنا لا أقول أننا نريد كسرها - لا يزال لديها العديد من المستخدمين - لكنك ستحتاج إلى تضمين المزيد من polyfills إذا كنت تريد أن تعمل. هذا يبدو عادلاً تمامًا بالنسبة لي.

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

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

لا أفهم سبب سلبية الناس تجاه هذا الأمر. فقط لا تقم بالترقية حتى تقوم تبعياتك بذلك؟

هل مشكلة الكلمة الرئيسية لـ class مقابل className و for مقابل htmlFor ليست شيئًا يمكن لمجمع jsx التعامل معه لتجاوز الكلمات المحجوزة؟

سأشعر بالقلق فقط إذا كانت التغييرات كبيرة بما يكفي بحيث تعطي نتائج البحث إجابات قديمة ... مثل ألم الزاوية 2+ الذي تم تقديمه عند البحث في googling لـ "angular -angularjs -angular1.x" وما إلى ذلك

بخلاف ذلك أرحب بكل التغييرات !!!

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

أنت قلت

"قد نحتاج إلى إسقاط التوافق مع بعض المتصفحات القديمة"

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

بخصوص العملية. أليس هذا النوع من "المشكلات" هو ما تم تصميم عملية RFC من أجلها؟

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

كنت أتحدث عن IE10 وما قبله. لقد أشرت على وجه التحديد إلى أننا نريد الاستمرار في دعم IE11 - أعتقد أنه يمثل حوالي 3٪ من حركة المرور لدينا ، وهو أكثر بكثير من نسبة 1٪ التي نعتبرها قديمة جدًا.

بخصوص العملية. أليس هذا النوع من "المشكلات" هو ما تم تصميم عملية RFC من أجلها؟

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

حسنا، شكرا لهذا التوضيح!

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

من المعقول أن نتخلص من الأحداث الاصطناعية تمامًا.

كيف يمكن أن يعمل ذلك مع إشارة event.currentTarget إلى العنصر الذي يتصل به مستمع الحدث ، والذي يعني دائمًا في الحالة الأصلية document - أو جذر React بمجرد تبديل React إلى ذلك؟

رد الفعل ليس مجرد تعيين الخصائص

(...)

نقطتي هنا هي أن ما إذا كانت React تستخدم الخصائص أو السمات داخليًا هي تفاصيل تنفيذية

لماذا يعتبر هذا أحد تفاصيل التنفيذ في حين أنه يمكن أن يؤثر على ما يحدث في DOM؟ ما لم يشير ذلك فقط إلى الخصائص التي تنعكس بطريقة ما في السمات (والعودة) مثل class / className .

أشعر بالارتباك حول معاملة class / className مرتبط بحقيقة أن استخدام React خاصية أو سمة يعتبر أحد تفاصيل التنفيذ. لدي خلفية Angular وعندما بدأت في استخدام React ، كانت أكبر مشكلة بالنسبة لي - في Angular ، يكون الفصل بين السمات والخصائص ومعالجات الأحداث واضحًا مباشرة من بناء الجملة وكنت في حيرة من أمري ما إذا كانت العناصر الموجودة في عناصر DOM قد تم تعيينها بواسطة React كـ الخصائص أو السمات.

كيف سيعمل ذلك مع event.currentTarget للإشارة إلى العنصر الذي يرتبط به مستمع الحدث ، والذي يعني دائمًا المستند في الحالة الأصلية - أو جذر React بمجرد تبديل React إلى ذلك؟

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

لماذا يعتبر هذا أحد تفاصيل التنفيذ في حين أنه يمكن أن يؤثر على ما يحدث في DOM؟ ما لم يشير ذلك فقط إلى الخصائص التي تنعكس بطريقة ما في السمات (والعودة) مثل class / className.

بالنسبة لغالبيتهم ، لا يوجد فرق ملحوظ من منظور المستخدم أيهما يستخدم. أعتقد أن معظمهم ينعكس (على الرغم من أنني ربما أكون مخطئًا).

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

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

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

@ Daniel15
بدون السياسات المذكورة (التي لا أعتقد أنها مذكورة في أي مكان آخر) ، فإن غلاف الكائن الإضافي لا يجعله أكثر أمانًا بأي شكل من الأشكال.
أعتقد أن المستخدم قد تم تحذيره بما فيه الكفاية بشأن الاستخدام الخطير عبر dangerouslySetInnerHTML . هذه هي النقطة التي أجبر فيها المستخدم si على التحقق من المستندات ، والنظر في الآثار واتخاذ القرار.
إن الحاجة إلى لف السلسلة (التي قد تكون غير مصححة) في كائن / وظيفة أيا كان ، لن تجعله يعيد النظر في القيمة المغلفة أو تطهيرها.
إذا كان يعمل بهذه الطريقة ، فربما لا يكون { __html } معقدًا بدرجة كافية و [{ _html: { __html }] سيجعل الأمر أكثر أمانًا - كم مرة علينا أن نعلن أن شيئًا ما خطير حتى نجعله آمنًا ؟

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

لا يتعلق الأمر فقط بجعل الأمر أكثر تعقيدًا ، بل يتعلق بمنع استخدام البيانات غير المعقمة عن طريق الخطأ.

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

أحب الطريقة التي يعتقد بها الجميع أن التغييرات القادمة أو التي جاءت إلى React في الإصدارات الأخيرة كانت "معطلة". من الواضح أن هؤلاء الأشخاص لم يختبروا Angular 2> 3> 4 مرات.

أنا أحب التغييرات. أنا شخصياً لا أمانع className $ ويمكن أن يصبح تدمير class أمرًا شاقًا. لكني أرغب في رؤية ما ستخرجون به يا رفاق.

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

أنا أحب رد الفعل

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

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

gaearon Throwing في 2c لكن هذين السلبيين يبدوان أكبر أو أكبر من السلبي الحالي (تكلفة صغيرة لمرة واحدة لفئة التعلم => className مقابل تجنب التدمير دائمًا + تكلفة الترحيل على مستوى النظام البيئي).

رد فعل: القلب:

صدى natew أعلاه:

gaearon Throwing في 2c لكن هذين السلبيين يبدوان أكبر أو أكبر من السلبي الحالي (تكلفة صغيرة لمرة واحدة لفئة التعلم => className مقابل تجنب التدمير دائمًا + تكلفة الترحيل على مستوى النظام البيئي).

على أي حال ، ما هو الدافع وراء التغيير من className إلى class ؟
بقدر ما أستطيع استخلاص تعليقك يتلخص في حجتين ، (يرجى تصحيح لي إذا كنت مخطئا):

أقرب من الناحية المفاهيمية إلى ما يتوقعه معظم الناس

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

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

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

أقل كتابة

Bruh ، إنها أربعة أحرف 8 ^). علاوة على ذلك ، حتى لو قمنا بتدمير class بشكل أقل كثيرًا مما نستخدمه حاليًا className ، فإن الأمر أكثر بكثير عندما نفعل ذلك. لذا سأكتب 4 أحرف أقل 12 مرة ولكني أضفت 50 حرفًا إضافيًا في كل مرة ألغيت فيها class ؟ هذا مجرد سخيف.

هل هناك سبب مقنع آخر فاتني لهذا التغيير؟
هل الدافع نوع من القلق بشأن التوافق مع سمات / خصائص DOM؟
هذا يبدو وكأنه حجة أكاديمية للغاية بالنسبة لي. معظم الناس ليسوا على دراية بتفاصيل التنفيذ هذه ولا أعتقد أنهم بحاجة إلى ذلك.

هل إذا تم إصداره اليوم فإن React سيسمح بـ class بدلاً من التغيير إلى className؟
أعتقد أن هذا غير ذي صلة.
لم تكن React مفتوحة المصدر اليوم ، وإذا كانت مفتوحة المصدر بعد عام من المستقبل ، فقد يتم اتخاذ مجموعة مختلفة من القرارات في ذلك الوقت.
في بعض الأحيان يكون من الأفضل التمسك بالقوام بدلاً من محاولة تسوية كل التجاعيد.

وإذا كانت React تستخدم الصنف من البداية ، فقد اعتدنا على تدمير الفئة وإعادة تعيينها إلى className ولكن كل من جاء بعلاقات عامة لتغيير الفئة _to_ className فسيتم الترحيب به كمنقذ.

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

أدعو الله أن تغير رأيك.

أنا سعيد جدًا بإمكانية ترقية التفاعل باستمرار ، بصفتي مطورًا لاستخدام رد الفعل ، لا أريد أن أرى تجاوزه بواسطة vue. لكن عملية className-> class يجب أن تكون مؤلمة.

أنا لست ضد إعادة تسمية className -> class من أجل النسخ واللصق ولكن لا يوجد دافع واضح لذلك حتى الآن. className موجود في DOM بينما هناك أسماء خاصة محجوزة تظهر من العدم مثل htmlFor . أشعر أنه يجب إعطاء الأولوية لتلك الأشياء عندما يتعلق الأمر بإعادة التسمية وربما يكون ذلك أقل انتشارًا للتغيير الذي يمكن أن يكون بمثابة اختبار أيضًا.

sonhanguyen htmlFor هو الاسم الرسمي لواجهة برمجة تطبيقات الويب أيضًا: https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelElement/htmlFor

@ allan2coder بدلاً من لفها في مصفوفة ، لفها بـ <React.Fragment> أو <> .

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

أود أن ألفت الانتباه إلى patch-package وهي حزمة تجعل من السهل تصحيح تبعياتك (على سبيل المثال لجعلها تتوقف عن استخدام React APIs غير المدعومة). من المسلم به أن هذا مفيد لكود التطبيق أكثر من كود المكتبة ، لكنني أعتقد أنه ينبغي أن يساعد في معالجة بعض مخاوف philipwhiuk .

أنا أتطلع إلى.

• قم بالترحيل من onChange إلى onInput ولا تعبئته للمكونات غير الخاضعة للرقابة.

بالنسبة للكلمات الواردة أعلاه ، أشعر بالفضول هل سيتم استخدام حدث onChange بالقرب من الحدث الأصلي أم لن يتم استخدامه في المستقبل؟

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

بناءً على الصياغة ، فهم لا يخططون للحفاظ على السلوك الحالي لـ onChange. لن يكون له معنى كبير. رد الفعل مثل libs الحديثة الأخرى لن تكون طبقة توافق للمتصفح ، ولا ينبغي أن تكون كذلك.

يحاكي onChange الحالي الإدخال + بعض الحالات الأخرى. ليس من المنطقي على الإطلاق اعتبار حدث التغيير موجودًا بالفعل في DOM وليس له نفس الدلالات: https://developer.mozilla.org/en-US/docs/Web/Events/change

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

بعيد قليلاً ولكن من المحزن أنه لم يكن لدى أي شخص (على حد علمي) فكرة إنشاء html / css / svg -> jsx transfomer من أجل تسهيل عمليات الترحيل للتفاعل مع العديد من التغييرات التافهة لتعيين أتباع HTML إلى رد الفعل الدعائم. الكثير من ساعات العمل المهدرة في تنفيذ البحث والاستبدال:

لا أعرف عن برامج التحرير الأخرى ، لكن IntelliJ IDEA (و WebStorm ، PhpStorm وما إلى ذلك) يقوم بهذا التحول ، عندما تقوم بلصق كود HTML في JS.

بعيد قليلاً ولكن من المحزن أنه لم يكن لدى أي شخص (على حد علمي) فكرة إنشاء html / css / svg -> jsx transfomer من أجل تسهيل عمليات الترحيل للتفاعل مع العديد من التغييرات التافهة لتعيين أتباع HTML إلى رد الفعل الدعائم. الكثير من ساعات العمل المهدرة في تنفيذ البحث والاستبدال:

إنه موجود بالفعل ولكنه قديم جدًا وغير صحيح تمامًا: https://magic.reactjs.net/htmltojsx.htm

يجب أن نحيي هذا الجهد. إذا كنت تريد المساعدة ، فيرجى القيام بما يلي: https://github.com/reactjs/reactjs.org/issues/484. حتى الآن لم يعرض أحد المساعدة والمتابعة.

إنه موجود بالفعل ولكنه قديم جدًا وغير صحيح تمامًا: https://magic.reactjs.net/htmltojsx.htm

لقد استخدمت هذا مرات عديدة من قبل - من الشائع جدًا استخدامه عند الاستعانة بمصادر خارجية لمكونات معينة لأشخاص يعرفون HTML / CSS ولكن ليس جافا سكريبت.

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

مشكلة في هذا الأسلوب هو أنه في اتجاه واحد فقط (ترحيل _ to_ رد فقط). هذه المشكلة ليست خاصة بالنسبة إلى React.

آمل أن تجعل الأمور أسهل بكثير ...

مشكلة في هذا النهج هو أنه في اتجاه واحد فقط (الهجرة فقط للرد). هذه المشكلة ليست خاصة بالنسبة إلى React.

لماذا ا؟ يجب أن يكون الأمر أسهل في الاتجاه المعاكس - فقط قم بتشغيل ReactDOMServer.renderToString .

ينتظر بصبر الإفراج

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

لماذا ا؟ يجب أن يكون الأمر أسهل في الاتجاه المعاكس - ما عليك سوى تشغيل ReactDOMServer.renderToString.

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

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

المشكلة هي أنني الآن يجب أن أحافظ على كل ترميز / نمط / تخطيط أغير نفسي في React.

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

أشياء مثل رد فعل - sketchapp هي طريقة لطيفة ممكنة لحل المشكلة ولكني آمل أن يكون هناك نهج أكثر عمومية يتيح لي القيام بذلك أثناء استخدام html / css العادي. على سبيل المثال - من خلال بعض أشكال البيانات الوصفية والاحتفاظ بمعرفات التفاعل على العناصر.

لقد فهمت تمامًا أن هذا ليس في نطاق نواة ReactDOM ولكنها بالتأكيد في مجالها وهي مشكلة مثيرة للاهتمام.

هذه ليست أولوية عالية - أردت في الغالب فقط شرح سبب فائدة htmltojsx لبعضنا حتى خارج سياق الترحيل :)

أريد الأشخاص الذين يكتبون html / css ولا يعرفون JavaScript جيدًا بما يكفي للعمل على كود JS ليكونوا قادرين على العمل على ترميز / نمط / تخطيط المكونات.

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

آسف إذا كان هذا خارج الموضوع للغاية ، لكنني أعتقد أن HTML / CSS فقط لا يكفي في الوقت الحاضر.

( gaearon لا تتردد في إخفاء هذا إذا أصبح صاخبًا لأنه رد حول تعليق OT الطفيف بالفعل أعلاه)

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

حسنًا ، سيتطلب ذلك ما يلي:

• اعمل فقط مع المقاولين الذين هم على دراية بمكدس React الحالي. من الصعب جدًا العثور على أشخاص يتعلمون المكونات المصممة
• قم بتثبيت Node (npm) والمكدس الخاص بك (React و webpack وما إلى ذلك) وكل شيء آخر مطلوب لتشغيله على كل كمبيوتر مستخدم لواجهة المستخدم وتحديثه باستمرار.
• علمهم بعض البرمجة الأساسية وجافا سكريبت ، وتعلم كيفية العمل مع devtools ، وأخطاء وحدة التحكم وما إلى ذلك.
• علمهم React ، ما هو تركيبها ، أشياء مثل className ، ماذا يعني key إلخ.
• لا تعمل إلا مع المقاولين والمستقلين الذين يرغبون في العمل بهذه الطريقة بدلاً من إنتاج HTML / CSS. هذا عادة ما يجعل الأشياء أكثر تكلفة.

الآن ، كما هو مذكور أعلاه ، فإن الأشياء مثل رد الفعل- skeptchapp هي طريقة مفيدة لجعل هذا أكثر سهولة ويسهل على مستخدمي واجهة المستخدم - لكنه لا يزال يتطلب منهم تعلم الكثير.

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

هذا خارج عن الموضوع تمامًا :-) دعنا نواصل هذه المناقشة على Twitter أو في أي مكان آخر.

"السلوك الذي ترى أنه يتم استخدام الأداة من أجله هو سلوك تشجعه الأداة"
~ غاري برنهاردت

الطريقة التي يتم بها استخدام React ، في معظمها ليس جزءًا من واجهة برمجة تطبيقات React ، ينتج عنها عدد كبير من المزالق التي تؤدي إلى مناقشات مثل هذه حيث يشعر الجميع بالارتباك والإحباط. هل استخدام كلمة رئيسية محجوزة مثل class سيء بسبب جافا سكريبت أو html أو التفاعل نفسه؟

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

<div {...this.props} />

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

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

<Child {...props} />

const Child = (props) => <div {...props} />

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

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

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

gaearon وقت طويل! :) (ملاحظة. آسف ل tl ؛ dr قدما)

على أي حال ، أردت فقط إلقاء نظرة ثاقبة على ما تعلمته من مغامراتي الخاصة. لقد صنعت مشتق React "الحد الأدنى" الخاص بي والذي أستخدمه الآن لتطبيقات الأداء / الميزات الهامة. لقد كانت في البداية مجرد تجربة جانبية ممتعة ولكني كنت أرى تحسينات في الأداء تتجاوز + 300٪ في حالات العالم الحقيقي للعرض الأولي / التحديث / الحذف بما في ذلك العديد من المزايا الأخرى. هذا بدون استخدام معالج الأحداث المجمع أيضًا.

يأتي جزء كبير من IIRC ببساطة من مكتبتي الخاصة متجاوزًا جميع منطق React-props وببساطة تغذية السمات مباشرة إلى setAttribute ، والأنماط مباشرة إلى style.setProperty ، والمستمعين مباشرة إلى addEventListener ، وما إلى ذلك. لذا فإن واجهة عنصر DOM الأساسي تبدو مثل هذه `{السمات: {} ، النمط: {} ، المستمعون: {} ، اسم الفئة:" "، ...} ، إنها مطولة أكثر ولكن الواجهة الآن صغيرة وسهلة التنفيذ و سريع للغاية. ربما يكون هذا متطرفًا جدًا بالنسبة لك ، لكنه خدمني جيدًا.

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

أتخيل أن معظم ذلك ليس مفيدًا لك حقًا ، ولكن ربما يوجد شيء مثير للاهتمام هناك. على أي حال ، فإن مأخذي الرئيسي مع HTML + React هو أن مكونات مستخدم React لا تعرض أي واجهة للتخطيط / تحديد المواقع (وربما إلى حد ما أيضًا الأحداث) دون اللجوء إلى CSS. لوضعها ببساطة ، إذا قمت بإنشاء ButtonComponent ثم استخدمته ، بشكل افتراضي لا يمكن وضعها أو دمجها في تخطيط بدون ؛ تنفيذ منطق خاص الغرض بداخله ، ولفه في عنصر وهمي يمكن وضعه أو عن طريق كشف خاصية النمط التي يتم دمجها في الأنماط المستخدمة لعنصر جذر ButtonComponent. لا شيء من هذا مثالي ، ودمج الأنماط كما هو أمر خطير لأنه من السهل وضع أنماط لا يجب عليك القيام بها. بشكل أساسي ، تكمن المشكلة في أنه عند حدود المكونات ، يجب أن تكون مجموعة فرعية من الخصائص المتاحة عامة (تحديد المواقع / التخطيط) وبعضها داخلي (التصميم المرئي).

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

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

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

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

قبل أن أنسى أيضًا ، قد تكون مهتمًا بوظيفتي objectKeyValueReconcile ، والتي تم تحسينها على وجه التحديد لتكون سريعة للغاية لمقارنة الدعائم prev / next لسيناريوهات تشبه React. إنها مسؤولة عن مكاسب كبيرة في الأداء في العالم الحقيقي بالنسبة لي.

https://github.com/syranide/surgical/blob/master/packages/surgical/private/objectKeyValueReconcile.js

imho سأسقط فكرة "الفصل". سوف تموت JSX في النهاية.

ما هي أفكار إضافة دعم لأحداث DOM / window غير القائمة على العناصر إلى React DOM؟ مع الإزالة المحتملة للأحداث الاصطناعية ، أظن أنه لا يزال هناك شكل من أشكال جمع / تحديث / تجميع الأحداث. أحداث الضغط على المفاتيح وتغيير الحجم والتمرير عبر النافذة هي سيناريوهات شائعة تتبادر إلى الذهن ، ولكن من المحتمل أن تتمكن من دعم معظم / كل القائمة في https://developer.mozilla.org/en-US/docs/Web/Events تكون مفيدة وراء نفس التجريد.

يحدث هذا أيضًا ليتم مناقشته في أقدم إصدار مفتوح رقم 285 😄.

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

التأثير العملي لـ className -> class سيكون:

({ className }) => <div className={className} />

سيصبح

({ ...rest }) => <div class={rest.class} />

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

@ kans

أو هذا:

props => <div class={props.class} />

هذا من التعقيد مماثل للوظيفة الأصلية.

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

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

IMO خارج رمز نظام التصميم ، فإن تطوير React الاصطلاحي حقًا لن يستخدم عادةً className أو class كثيرًا على أي حال. عندما أحتاج إلى استخدام فئات لـ css ، يتم عزلها في الغالب إلى عدد قليل من مكونات واجهة المستخدم الصغيرة. إلى حد كبير أي شيء مستخدم في طبقة التطبيق هو مستوى أعلى (مثل ، على سبيل المثال ، <Columns verticalAlign="center"> أو <BodyText /> ).

لذا أعتقد أنني أتساءل عما إذا كانت إعادة التسمية من className إلى class تجعل الأمر أسهل بالنسبة للأشخاص الذين يستخدمون الدعامة على أي حال (من السهل الدخول في تطوير React ، لتبديل السياقات ، حتى لا تغضب ، وما إلى ذلك) ، فلماذا لا نعيد تسميتها فقط؟

تقليل حجم الحزمة من فضلك.

نظرًا لأن هذا تحديث كبير ومتكسر ، فربما يمكننا إصلاح تسمية دورة حياة React أيضًا!

على سبيل المثال ، shouldComponentUpdate => shouldUpdate ، إلخ. هذه التسمية أبعد من أن تكون سخيفة.

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

نظرًا لأن هذا تحديث كبير ومتكسر ، فربما يمكننا إصلاح تسمية دورة حياة React أيضًا!

أي shouldComponentUpdate => shouldUpdate ، إلخ. هذه التسمية أبعد من أن تكون سخيفة.

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

تعد طرق دورة الحياة جزءًا من قلب رد الفعل ، وهذه المشكلة تتعلق فقط بردود دوم.

تضمين التغريدة
عذرًا ، حقًا!

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

أحب أن أرى هذه التغييرات.
آمل أن يتم تنفيذها مع وضع العناصر المخصصة في الاعتبار.

أتساءل عما إذا كان الأمر يستحق نقل بعض المناقشات إلى سلاسل منفصلة في المنتدى (https://discuss.reactjs.org)؟ نظرًا لأن مشكلات GitHub ليست متسلسلة مثل مشاركات المنتدى ، فإنه يجعل من الصعب مناقشة عدة أشياء مختلفة في نفس المشكلة.

يبدو تغيير className -> class مثيرًا للاهتمام بالنسبة لي 😺

شاهد ، 2019 مشاريع React

const {
  class: className, // YouKnowIamRight PepeHands
  someFancyProp,
  ...restProps
} = props

أرى هذا قادمًا بالتأكيد.

أحب تمامًا أن أكون قادرًا على نسخ لصق HTML وعدم الاضطرار إلى تغيير className ولكن في نفس الوقت أرى المشكلات التي يمكن أن تجلبها الكلمة الرئيسية المحجوزة class .

في هذه المرحلة ، أفضل التمسك بـ className ما لم يكن لديك قلق هندسي قوي حيال ذلك (وليس التفضيل الشخصي)

لكن هذا مجرد رأي عملي.

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

إن تمرير className إلى مكوّن React (ليس فقط عنصر DOM) يعني أنك إما تصنع كتل بناء صغيرة جدًا دون تقديم أي أفكار تجريدية جديدة أو أن هذا المكوّن يفضح بعض تفاصيل تنفيذه. في الحالة الأولى (على سبيل المثال <Button /> component) قد ترغب في اتباع مثالgaearon وإعادة توجيه "بقية" الخاصيات إلى عنصر DOM أيضًا. في الحالة الثانية ، ربما يجبرك الاحتكاك الإضافي على تجنب فعل الشيء والتوصل إلى حل أفضل.

من تجربتي المتواضعة ، اضطررت إلى نسخ لصق HTML إلى JSX (واستبدال class بـ className ) مرات أكثر مما أتذكره عند إنشاء مكون يتلقى className .

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

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

@ j-f1

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

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

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

كثير منكم (نعم ، أنت تفعل) يفكك تقريبًا كل قيمة من props و state بدلاً من استخدام تدوين النقطة لأسباب غير تجنب كتابة بعض النصوص الإضافية.

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

إذا كنت أكثر واقعية قليلاً ، فستتحدث عن الآثار التقنية بدلاً من تفضيلاتك الشخصية ، لكني لا أرى أي شخص يقول أي شيء عن الآثار التقنية لـ className .

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

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

لكن مرة أخرى ، رأيي العملي.

عند الحديث عن polyfills ، لا أعتقد أن رد الفعل يجب أن يحاول اكتشاف ما إذا كان المستخدم قد حدد polyfills "جيدة".
(على سبيل المثال ، hasBadMapPolyfill في الكود)
لا ينبغي تحميل React المسؤولية عن جميع الأخطاء العشوائية التي يمكن أن يرتكبها المرء في مشروع برمجي.

AlexGalays تعتمد React على استخدام تطبيق Map مع دلالات صحيحة. إذا كان المستخدمون يستخدمون polyfill غير متوافق ، فقد يتعطل تطبيقهم بطرق غير متوقعة ومربكة ، لذلك من المفيد التحذير مسبقًا في هذه الحالة.

يتم ذلك فقط في تطوير البناء أيضًا ، لذلك ليس هناك أي نفقات إضافية لهذا في الإنتاج.

أنا أحب React Fire وستستمر في العمل على هذا لأنه يبدو خطوة أكثر إثارة للاهتمام لتحديث ReactDOM.

هل سيكون من الممكن لرد فعل إطلاق النار لعدم إعادة معالجات الأحداث؟

class Compo exntends Compoent {
 onClick() {
   ...
 }
  render() {
   <button onClick={this.onClick} >click me </button>
  }
}

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

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

هل سيكون من الممكن لرد فعل إطلاق النار لعدم إعادة معالجات الأحداث؟

يمكنك ربط الطريقة بالفئة مرة واحدة باستخدام الارتباطات التلقائية لوظيفة السهم أو ربط الوظيفة في المُنشئ الخاص بك. إذا كانت هناك معلمات فريدة تريد ربطها بالحدث ، فيمكنك البحث في حفظ معالجات الأحداث أو إرفاق سمات DOM بالعقد نفسها والوصول إليها من خلال event.currentTarget .

class Compo extends Compoent {
 onClick = () => {
   ...
 }
 render() {
   <button onClick={this.onClick}>click me</button>
 }
}

فائدة أخرى لتبسيط نظام الأحداث (هل يمكننا العودة إلى أحداث DOM الأولية دون أي تجميع مثل جميع الأطر؟ :)) وهي أنه من السهل الكتابة بشكل ثابت أيضًا.

تبدو وكأنها خطة رائعة! سيكون من الجيد حقًا الحصول على دعم IE 11 (حتى لو كان ذلك يعني شحن polyfills الخاصة بنا وهو أمر جيد تمامًا). بصفتك شخصًا يعمل مع عملاء الحكومة ، فإن الوقت الذي سيتوقفون فيه عن استخدام IE 11 هو أمر مجهول تمامًا :(

MatthewHerbst نفس القارب ، يستخدم عملاؤنا IE 11 ولدينا عدد كافٍ من الزيارات 😢

أردت فقط أن تتناغم لأقول أن هذا كله مثير للغاية. الشيء الوحيد الذي قرأته والذي يقلقني هو:

من الممكن ألا نحاول التخفيف من بعض الاختلافات الموجودة في المتصفح

أحب الآن معرفة أن نظام الأحداث في React "سيعمل فقط" على أي متصفح يدعمه React. أخشى أن يعني هذا التغيير أنه سيقع على عاتق التطبيق مسؤولية حساب المشكلات عبر المستعرضات. من المحتمل أن يؤدي هذا إلى ظهور الكثير من الأخطاء التي يصعب تتبعها. ... على الأقل بالنسبة لتطبيقاتي. :)

على أي حال ، شكرا كالعادة على المكتبة العظيمة.

لقد ذكرت kentcdodds تكامل JSX 2.0 كفكرة محتملة كنت أقرأها من خلال الإستراتيجية ولم أر أي شيء يبدو مرتبطًا بذلك. كنت أتساءل عما إذا كان ذلك في الهواء أم شيء سيتم تأجيله في المستقبل؟

دع IE يموت! لا تدعم المتصفحات القديمة تمامًا. لا يوجد سبب ، حتى بالنسبة للشركات المقيدة ، لعدم التبديل إلى متصفح محدث. سترى أن IE11 في إحصائياتك حتى تتوقف أنت والويب عن دعمه.

hbroer البرامج القديمة؟

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

• "لا أعرف كيفية التحديث" - ليست مشكلتنا ، ولكن يمكننا وضع رسائل "تثبيت متصفح جديد" بقائمة من المتصفحات وربما مع نص المساعدة ورقم هاتف Microsoft Hotline ^^
• "ليس لديهم خيار" - صحيح ، ولكن يتعين على المنظمة تحديث بيئتها. إذا لم تنجح أدواتهم ، سيفعلون.

أكره كتابة التعليمات البرمجية للماضي ولا يمكنني استخدام ميزة التكنولوجيا الجديدة ، لأن 90٪ من المبرمجين لا يزالون يدعمون المتصفحات السيئة للمستهلكين الـ 15٪ الأدنى الذين يعيشون في القرن الماضي. ^^ لا تريد الحصول على هذا "أوه ما هو مع هذا المهووسين بـ Internet Explorer 6 ، علينا دعم 15٪" مرة أخرى خلال السنوات العشر القادمة.

راجع مقارنة M $ s لإحضار Edge لنظامي التشغيل Windows 7 و 8 مع التبديل إلى webkit.

hbroer كل شيء هو مشكلتنا إذا كان يؤثر على المستخدمين. تحلى ببعض التعاطف مع البشر الآخرين.

(بشكل منفصل ، M$ عبارة عن مرجع حدث جميل ومؤرخ جدًا في أواخر التسعينيات وقد ترغب في إزالته ؛ يسعدني إزالة هذا جانباً إذا قمت بذلك)

أرى ، هنا العديد من M $ fanboiz. : تهتم شركة DI حقًا بالبشر ، ولكن ليس بالمنظمات التي تمنع تقدم التكنولوجيا ، أو المبرمجين الذين يقصدون دعم هذا الهراء القديم على مدار سنوات. ليس لدي مشكلة مع حزمة إضافية مما يجعل مكتبة "حماقة قديمة متوافقة". ولكن يجب ترميز المكتبة في عام 2019 مع مراعاة> = 2019 التكنولوجيا ، وليس <= 2013 tech. إنه لأمر سيء أن تضطر إلى دعم ذلك (دعنا نفعل ذلك بطريقة أخرى قليلاً) رحلات السفاري و حماقة الحافة (القديمة).

ميكروب

يعد متصفحhbroer في الواقع ، و Safari القديم ، مشكلة أكثر من أي متصفح Microsoft. لا يتعلق الأمر بكونك "فانبوي" ولكن أن تكون محترفًا ، واستخدام مصطلح "مليون دولار" ليس كذلك.

ولا ، ليس "سيئًا" بأي شكل من الأشكال لدعم التكنولوجيا القديمة ، إنه الشيء الأخلاقي والأخلاقي الذي يجب القيام به. الأمر السيئ هو مواقع الويب التي "تعمل بشكل أفضل في X" ، سواء كانت Netscape Navigator أو IE 6 أو أحدث إصدار من Chrome.

أرى ، هنا العديد من M $ fanboiz.

hbroer أرى هنا شخصًا يعاني من هجمات hominem الإعلانية الشاملة.

ولكن يجب ترميز المكتبة في عام 2019 مع مراعاة> = 2019 التكنولوجيا ، وليس <= 2013 tech.

لا ، لا ينبغي.

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

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

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

ملاحظة: أرى شخصًا لا يستطيع قراءة السخرية ولا يهتم بالابتسامات ^ ^

hbroer أنت تُظهر أن IE11 هو الحاضر ، لذلك من المتوقع أن نقوم بالترميز لذلك.

و مرة اخرى. انظر القيمة الافتراضية على https://browserl.ist.

ملاحظة: أرى شخصًا لا يستطيع قراءة السخرية ولا يهتم بالابتسامات ^ ^

نعم لا. هذا تكتيك شائع يستخدمه المتصيدون والمتنمرون في الملعب. "ماذا ؟! لم أهينك! كانت مجرد مزحة!".

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

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

الآن في عام 2019 ، سأستخدم شبكة css للمشاريع الجديدة (التي لديها دعم تجريبي فقط على IE11) ، وسوف تنتقل إلى ES6 ولا أريد تسليم polyfills لهذا المتصفح القديم. يتلقى مستخدمو IE11 رسالة ببساطة: قم بتحديث متصفحك أو استخدام بديل.

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

إنني أراقب كل متصفح لم يعد قديمًا. أنا أؤيد Edge ، التي لديها عدد أقل من المستخدمين من هذا IE11 ، بسبب Windows 7 (الذي يدعم نهايات يناير 2020) ، ويستخدم الأشخاص المعاصرون المتصفحات الحديثة. ^ ^

لا أحد يمنعك من استخدام polyfills وشيء مثل حزمة التوافق. ولكن يجب أن يكون الجزء الأساسي محدثًا وألا يظل متخلفًا جدًا فقط بسبب قطعة واحدة من متصفح التكنولوجيا القديم M $.

ما أفتقده في العديد من أطر عمل جافا سكريبت هو LTS. هذا ما يمكننا التحدث عنه. إذا قمت بإنشاء صفحة حديثة بميزات من الحاضر ، فمن الجيد استخدام إطار تقني حديث. وإذا كنت تقوم بإنشاء تطبيق ويب لأشياء b2b والذي يحتاج إلى أقصى قدر من الاستقرار والتوافق ، فيمكنك استخدام إصدار LTS. أو استخدم الضربة القاضية. ثم يمكنك دعم عدد قليل من الأشخاص 100 طن الذين لا يزالون يستخدمون Windows XP غير محدث مع IE6 ^ ^

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

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

يبدو أن التقدم في React Fire نفسه لم يتأثر ، لذا لا يوجد شيء يمكن كسبه حقًا من هذا النقاش. دعنا ننتقل من فضلك ونعود إلى الموضوع الرئيسي.

هل ستكون هذه فرصة جيدة لحل # 6410؟ يبدو أن تأثير التغييرات المقترحة على onChange / onInput يبدو مشابهًا في التأثير.

تحديث من 5 يونيو 2019

لقد مر وقت طويل. إليك تحديث صغير عن مكان وجودنا.

بدأنا العمل على Fire في ديسمبر. هناك بعض الأعمال قيد التقدم في https://github.com/facebook/react/pull/14382 ومواضيع أخرى. ومع ذلك ، عندما بدأنا في إزالة أجزاء من نظام الأحداث التي اعتقدنا أنها غير ضرورية أو قديمة ، اكتشفنا العديد من حالات الحافة حيث كانت مفيدة للغاية وتمنع الأخطاء - حتى في المتصفحات الحديثة. ما زلنا نرغب في تقليص حجم الانتفاخ القديم ولكن ليس من الواضح أن الاقتراب من أحداث DOM الأولية هو أفضل اتجاه عمليًا. إن تقليل كود المكتبة فقط لإعادة إضافته عدة مرات في كود التطبيق ليس أفضل مقايضة. وليس من الممكن دائمًا إصلاحه على مستوى التطبيق.

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

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

نتيجة لهذا التحقيق ، أوقفنا مؤقتًا العمل على العناصر الأخرى التي تشكل جزءًا من React Fire ، وقررنا التركيز فقط على نظام الأحداث أولاً. أصبح هذا المشروع معروفًا باسم React Flare (https://github.com/facebook/react/issues/15257). إنه يمثل تحديًا كافيًا بحد ذاته ويؤثر على العناصر الأخرى في هذه القائمة ، لذلك نحن نركز عليه أولاً بشكل منفصل.

الهدف من React Flare هو تسهيل إنشاء واجهات مستخدم تبدو رائعة على سطح المكتب والجوال ، باستخدام الماوس واللمس ، ويمكن الوصول إليها. يتضمن واجهات برمجة تطبيقات تعريفية لإدارة التفاعلات مثل Press و Hover و Focus. على عكس نظام حدث React الحالي ، لا يضخم تصميم Flare الحزمة للأحداث التي لا تستخدمها - ويجب أن يسمح بتقليل مقدار التعليمات البرمجية في مكتبات واجهة المستخدم التي تتعامل مع أحداث الماوس واللمس.

لا تزال React Flare عبارة عن تجربة ، لكننا واثقون تمامًا من اتجاهها العام ، ونخطط لإتاحتها رسميًا في نهاية المطاف في مصدر مفتوح. (في الوقت الحالي ، لا يعمل إلا إذا قمت بالبناء يدويًا من سيد ، ولا توجد ضمانات semver لأننا نعمل بنشاط على ذلك.) مثل Fire ، فإن "Flare" هو مجرد اسم رمزي - بحلول الوقت الذي نشحنه فيه ، سيكون التسمية الصحيحة والتوثيق وما إلى ذلك. ربما react/events أو شيء من هذا القبيل. نود أن نقدم أحداثًا مماثلة في React Native أيضًا في النهاية.

بعد أن ننتهي من التنفيذ الأولي لـ React Flare ، سنعود إلى قائمة React Fire ونعيد تقييم جميع النقاط الأخرى باستخدام ما تعلمناه منها. لا يزال من المحتمل أنه إذا استحوذ Flare على مجموعة "أكثر ثراءً" من الأحداث ، فيمكننا تبسيط معالجة الحدث "الأساسي" في React DOM وإزالة مجموعة من polyfills. شكرا للجميع على المناقشة حتى الآن ، وآمل أن يكون هذا مفيدا.

عمل عظيم! لذلك لا يزال نظام الأحداث ضروريًا لتحقيق التوازن بين أحداث الماوس واللمس ، ولكنه سيكون خفيف الوزن ومستقلًا عن React.

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

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

هل سيعزز نظام أحداث الماوس واللمس PointerEvent ؟ لم أشاهد أي إشارة إلى معيار الويب هذا في التحديث السابق ، لذلك أردت فقط لفت انتباهكم إليه.

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

وهنا رابط مباشر لتوافق المتصفح الحالي .

jonathantneal نعم ، يستخدم النظام الجديد بشكل كبير أحداث المؤشر - مع احتياطات لأحداث الماوس / اللمس عندما لا يكون هناك دعم لأحداث المؤشر.

أشعر بالقلق من عدم معالجة https://github.com/facebook/react/issues/11347 في هذه المشكلة. رد فعل يفشل https://custom-elements-everywhere.com.

يرجى مراعاة جذر الظل عند إعادة تصميم نظام الحدث - فمجرد إرفاقه بجذر React لن يحل معظم المشكلات اليوم ، فقط إرفاقه بالعنصر (https://github.com/facebook/react/issues/9242، https: // github.com/facebook/react/issues/15759 ، https://github.com/facebook/react/issues/13713 ، https://github.com/facebook/react/issues/11827)

في هذا التحديث: https://github.com/facebook/react/issues/13525#issuecomment -499196939 يذكر Gaearon :

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

كنت أشعر بالفضول لمعرفة ما إذا كانت قائمة حالات الحافة هذه موثقة في أي مكان؟

gaearon الآن بعد أن خرج Flare (SCNR) ، هل هناك خطة محدثة (بخصوص تحديث 5 يونيو 2019 ) كيف يمكن المتابعة؟

ومثل trusktr @ ، أود أيضًا أن أحصل على # 11347 مخاطبة هنا.

يمكن تقسيم polyfills إلى حزمة أخرى خاصة تلك التي لا تتعلق بالمتصفحات دائمة الخضرة.

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

اسمحوا لي أن أقدم تحديثًا لكل:

• توقف عن عكس قيم الإدخال في السمة value (https://github.com/facebook/react/issues/11896). تمت إضافة هذا في الأصل في React 15.2.0 عبر https://github.com/facebook/react/pull/6406. تم طلبه بشكل شائع لأن النموذج المفاهيمي للناس لـ DOM هو أن value الذي يشاهدونه في مفتش DOM يجب أن يتطابق مع السمة value JSX. لكن هذه ليست الطريقة التي يعمل بها DOM. عندما تكتب في حقل ، لا يقوم المستعرض بتحديث السمة value . لا ينبغي أن تفعل React ذلك أيضًا. اتضح أن هذا التغيير ، على الرغم من أنه ربما يكون مفيدًا لبعض التعليمات البرمجية التي تعتمد على محددات CSS ، تسبب في سلسلة من الأخطاء - بعضها لا يزال غير مثبت حتى يومنا هذا. بعض تداعيات هذا التغيير تشمل: https://github.com/facebook/react/issues/7179 ، https://github.com/facebook/react/issues/8395 ، https://github.com/facebook / رد / قضايا / 7328 ، https://github.com/facebook/react/issues/7233 ، https://github.com/facebook/react/issues/11881 ، https://github.com/facebook/react / قضايا / 7253 ، https://github.com/facebook/react/pull/9584 ، https://github.com/facebook/react/pull/9806 ، https://github.com/facebook/react/pull / 9714 ، https://github.com/facebook/react/pull/11534 ، https://github.com/facebook/react/pull/11746 ، https://github.com/facebook/react/pull/12925 . في هذه المرحلة ، من الواضح أنه لا يستحق الاستمرار في محاربة المتصفح ، ويجب أن نعود إليه. الجزء الإيجابي من هذه الرحلة هو أنه بفضل العمل الدؤوب من مساهمينا في DOM ( nhunzaker و aweary و jquense و @ philipp-spiess) لدينا الآن تركيبات اختبار DOM مفصلة ستساعدنا في تجنب الانحدارات.

ما زلنا نرغب في القيام بذلك ، لكننا قررنا "حجز" React 17 للحصول على أقل قدر ممكن من التغييرات الفاصلة بحيث يمكن التركيز على العنصر التالي في هذه القائمة. لذا فإن هذا التغيير سينتظر حتى React 18.

• قم بإرفاق الأحداث في جذر React بدلاً من المستند (https://github.com/facebook/react/issues/2043). يصبح إرفاق معالجات الأحداث بالمستند مشكلة عند تضمين تطبيقات React في أنظمة أكبر. كان محرر Atom من أولى الحالات التي اصطدمت بهذا. يطور أي موقع ويب كبير أيضًا حالات حافة معقدة للغاية تتعلق بـ stopPropagation يتفاعل مع كود non-React أو عبر جذور React (https://github.com/facebook/react/issues/8693، https: // github .com / facebook / رد فعل / سحب / 8117 ، https://github.com/facebook/react/issues/12518). سنرغب أيضًا في إرفاق الأحداث بشغف بكل جذر حتى نتمكن من إجراء فحوصات وقت تشغيل أقل أثناء التحديثات.

نحن نقوم بذلك في React 17. اتضح أن هذا جزء كبير من العمل ولكن لحسن الحظ انتهى الأمر.

• قم بالترحيل من onChange إلى onInput ولا تعبئته للمكونات غير الخاضعة للرقابة (https://github.com/facebook/react/issues/9657). راجع المشكلة المرتبطة للحصول على خطة مفصلة. لقد كان محيرًا أن React تستخدم اسم حدث مختلف لما يُعرف بحدث input في DOM. بينما نتجنب عمومًا إجراء تغييرات كبيرة مثل هذه دون فائدة كبيرة ، في هذه الحالة نريد أيضًا تغيير السلوك لإزالة بعض التعقيد الضروري فقط لحالات الحافة مثل تغيير المدخلات الخاضعة للرقابة. لذلك من المنطقي إجراء هذين التغييرين معًا ، واستخدام ذلك كفرصة لجعل onInput و onChange يعملان بالضبط بالطريقة التي تعمل بها أحداث DOM للمكونات غير الخاضعة للرقابة.

من المحتمل أن نعود إلى هذا ولكن من غير الواضح كم يستحق القيام به هنا. لذلك لا يزال هذا يحدد لاحقًا.

• تبسيط نظام الأحداث بشكل جذري (https://github.com/facebook/react/issues/4751). بالكاد تغير نظام الأحداث الحالي منذ تنفيذه الأولي في 2013. ويُعاد استخدامه عبر React DOM و React Native ، لذا فهو مجرد تجريدي بلا داعٍ. العديد من polyfills التي توفرها غير ضرورية للمتصفحات الحديثة ، وبعضها يخلق مشاكل أكثر مما يحلها. كما أنها تمثل جزءًا كبيرًا من حجم حزمة React DOM. ليس لدينا خطة محددة للغاية هنا ، ولكن من المحتمل أن نتخلى عن نظام الأحداث تمامًا ، ثم نرى مدى الحد الأدنى الذي يمكننا تحقيقه إذا تمسكنا بما يقدمه لنا DOM. من المعقول أن نتخلص من الأحداث الاصطناعية تمامًا. يجب أن نتوقف عن إحداث فقاعات مثل الأحداث الإعلامية التي لا تحدث فقاعات في DOM وليس لها سبب وجيه لتحدث فقاعات. نريد الاحتفاظ ببعض الإمكانات الخاصة بـ React مثل التدفق عبر البوابات ، لكننا سنحاول القيام بذلك عبر وسائل أبسط (مثل إعادة إرسال الحدث). من المحتمل أن تكون الأحداث السلبية جزءًا من هذا.

لقد جربنا هذا في أوائل عام 2019 ، ولم ينجح نظام الحد الأدنى من الأحداث حقًا بشكل جيد في اختبارنا الداخلي. كان هناك قدر كبير من التطبيع عبر المستعرضات التي يقوم بها React والتي لا تزال مفيدة للأشخاص الذين لديهم متصفحات أقدم ، أو في مناطق أكثر تخصصًا مثل محرري إدخال النص المنسق باستخدام contentEditable . ومع ذلك ، كجزء من عملنا على ربط الأحداث بالجذور ، أزلنا الكثير من الأفكار المجردة من نظام الأحداث حتى يسهل فهمها وتحسينها في المستقبل. كجزء من React 17 ، نقوم بإزالة "تجمع الأحداث" الذي تسبب في الكثير من الالتباس ، كما أننا لم نعد نقوم بنشر فقاعات للحدث onScroll . من المحتمل أن نتبع ذلك بإيقاف فقاعات الأحداث الإعلامية في React 18 ، مما يجعل سلوك React أقرب إلى سلوك المتصفح. لقد وفرنا بعض وحدات البايت مع نظام الأحداث الجديد ، ولكن تم أخذها من خلال الميزات الجديدة التي نعمل عليها ، لذلك لن يؤدي ذلك إلى تقليل حجم الحزمة بشكل عام.

• className → class (https://github.com/facebook/react/issues/4331 ، راجع أيضًا https://github.com/facebook/react/issues/13525#issuecomment- 417818906 أدناه). تم اقتراح هذا مرات لا تحصى. نحن نسمح بالفعل بتمرير class لأسفل إلى عقدة DOM في React 16. الارتباك الذي يحدثه هذا لا يستحق قيود البنية التي تحاول الحماية منها. لن نقوم بهذا التغيير من تلقاء نفسه ، ولكن مع كل شيء آخر فوقه أمر منطقي. لاحظ أنه لا يمكننا السماح بكليهما بدون تحذيرات فقط لأن هذا يجعل من الصعب جدًا على نظام مكون من مكونات التعامل معه. سيحتاج كل مكون إلى تعلم كيفية التعامل مع كليهما بشكل صحيح ، وهناك خطر تعارضهما. نظرًا لأن العديد من المكونات تعالج className (على سبيل المثال من خلال إلحاقها) ، فهي عرضة للخطأ للغاية.

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

مرحبًا ، إنها مقالة رائعة!
أردت فقط معرفة ما إذا كانت هناك أي خطة قيد التنفيذ لتقليل حجم منتج React-DOM؟ بالنسبة لتطبيقات الأجهزة المحمولة ، لا يزال يمثل عبئًا حيث سيقوم المتصفح بتحليل أكثر من 100 كيلوبايت من React-DOM JS ثم وحدات أخرى. ثم JS الخاصة بالتطبيق.
بالنسبة للصفحات الغنية بالمحتوى ، فإنه يتسبب في زيادة الحظر وزيادة TTI.

أي فكرة متى يمكننا رؤية مثل هذه التغييرات؟

@ morevolk-latei في قياساتك ، ما مقدار الوقت المستغرق في تحليل 100 كيلوبايت من ReactDOM؟