React Canaries: التمكين التدريجي لإطلاق الميزات الجديدة خارج Meta
في الثالث من مايو، 2023، كتبه دان أبراموف، صوفي ألبرت، ريك هانلون، سيباستيان ماركباج، و أندرو كلارك.
نحن نرغب في توفير خيار لمجتمع React يتيح لهم اعتماد ميزات جديدة بشكل فردي بمجرد اقتراب تصميمها من النهائي، قبل أن يتم إصدارها في إصدار مستقر، على غرار كيفية استخدام Meta إصدارات حديثة من React داخليًا. نحن نعتزم إطلاق قناة جديدة يتم دعمها بشكل رسمي قناة الكناري (Canary release channel). وتتيح هذه القناة لأنظمة الإعداد المنتقاة مثل الأطر (frameworks) الانفصال عن جدول إصدارات React واعتماد ميزات React الفردية.
إطناب
- نحن نقدم قناة إصدارات Canary بشكل رسمي لـ React. وبما أنها مدعومة بشكل رسمي، فإذا تم اكتشاف أي انحرافات، سنعالجها بنفس السرعة التي نعامل بها الأخطاء في الإصدارات الثابتة.
- تتيح لك القنوات الكناري بدء استخدام ميزات React الجديدة بشكل فردي قبل أن تصبح متاحة في الإصدارات الثابتة بناءً على نمط الإصدار المنطقي semver (Semantic Versioning).
- على عكس القناة التجريبية (Experimental)، تتضمن قنوات الكناري الخاصة بـ React فقط الميزات التي نعتقد بموضوعية أنها جاهزة للتبني. ونشجع الأطر (frameworks) على النظر في تجميع إصدارات React الكناري ذات الإصدار المثبت.
- سنعلن عن التغييرات الكبيرة والميزات الجديدة على مدونتنا عندما تصبح متاحة في إصدارات الكناري.
- كما هو الحال دائمًا، يستمر React في اتباع نظام إصدارات semver لكل إصدار ثابت.
كيفية تطوير ميزات React عادةً
عادةً ما تمر كل ميزات React بنفس المراحل:
- نقوم بتطوير نسخة أولية ونضيف لها بادئة “experimental_” أو “unstable_“. تكون الميزة متاحة فقط في قناة الإصدار “experimental”. في هذه المرحلة، من المتوقع أن تتغير الميزة بشكل كبير.
- نجد فريقًا في Meta مستعدًا للمساعدة في اختبار هذه الميزة وتقديم ملاحظات عليها. يؤدي ذلك إلى جولة من التغييرات. مع تزايد استقرار الميزة، نعمل مع مزيد من الفرق في Meta لتجربتها.
- في نهاية المطاف، نشعر بالثقة في التصميم. نقوم بإزالة البادئة من اسم واجهة البرمجة التطبيقية ونجعل الميزة متاحة في الفرع الرئيسي “main” افتراضيًا، الذي يستخدمه معظم منتجات Meta. في هذه النقطة، يمكن لأي فريق في Meta استخدام هذه الميزة.
- بينما نكتسب الثقة في الاتجاه، نقوم أيضًا بنشر RFC (Request for Comments) للميزة الجديدة. في هذه النقطة، نعلم أن التصميم يعمل لمجموعة واسعة من الحالات، ولكن قد نقوم ببعض التعديلات الأخيرة.
- عندما نكون على مقربة من إصدار مفتوح المصدر، نقوم بكتابة وثائق للميزة وأخيرًا نقوم بإصدار الميزة في إصدار ثابت من React.
هذا النهج يعمل جيدًا لمعظم الميزات التي أصدرناها حتى الآن. ومع ذلك، قد يكون هناك فجوة كبيرة بين متى تكون الميزة جاهزة للاستخدام بشكل عام (الخطوة 3) ومتى يتم إصدارها في المصدر المفتوح (الخطوة 5).
نود أن نقدم لمجتمع React خيارًا لاتباع نفس النهج الذي تتبعه Meta واعتماد الميزات الجديدة الفردية في وقت مبكر (عند توفرها) دون الحاجة لانتظار دورة الإصدار التالية لـ React.
كالعادة، ستصل جميع ميزات React في نهاية المطاف إلى إصدار ثابت.
هل يمكننا فقط إصدار المزيد من الإصدارات الفرعية؟
عمومًا، نعم نستخدم الإصدارات الفرعية لإدخال الميزات الجديدة.
ومع ذلك، ليس هذا ممكنًا دائمًا. في بعض الأحيان، تكون الميزات الجديدة مترابطة بشكل وثيق مع ميزات جديدة أخرى لم يتم الانتهاء من تنفيذها بشكل كامل وما زلنا نعمل عليها بنشاط. لا يمكننا أن نقوم بإصدارها على حدة لأن تنفيذاتها مترابطة مع بعضها البعض. كما أننا لا يمكننا تسميتها بإصدارات منفصلة لأنها تؤثر على نفس الحزم (على سبيل المثال، react و react-dom). ونحتاج إلى الاستمرار في القدرة على تعديل الأجزاء التي لم تكتمل بعد دون إصدارات كبيرة متتالية، وهذا ما يتطلبه Semantic Versioning (semver).
في Meta، قمنا بحل هذه المشكلة من خلال بناء React من فرع “main”، وتحديثه يدويًا إلى نقطة ارتكاز محددة كل أسبوع. وهذا هو أيضًا النهج الذي تتبعه إصدارات React Native منذ العديد من السنوات الماضية. يتم تثبيت كل إصدار “مستقر” من React Native على نقطة ارتكاز محددة من فرع “main” في مستودع React. يتيح هذا لـ React Native أن يتضمن إصلاحات الأخطاء المهمة ويعتمد ميزات React الجديدة تدريجيًا على مستوى الإطار دون أن يرتبط بجدول إصدارات React العام.
نحن نرغب في توفير هذه العملية لإطارات أخرى وتهيئات مختارة. على سبيل المثال، يتيح ذلك لإطار يعتمد على React أن يتضمن تغييرًا جذريًا متعلقًا بـ React “قبل” أن يتم تضمين هذا التغيير الجذري في إصدار مستقر لـ React. وهذا مفيد بشكل خاص لأن بعض التغييرات الجذرية تؤثر فقط على تكامل الإطار. بالتالي، يمكن للإطار أن يصدر تلك التغييرات ضمن إصدار ثانوي خاص به دون أن يخرق مبدأ Semantic Versioning (semver).
إطلاق الإصدارات في قناة Canaries سيتيح لنا الحصول على حلقة ردود فعل أوثق وضمان أن الميزات الجديدة تحصل على اختبار شامل في المجتمع. وهذا النهج أقرب إلى كيفية تعامل TC39، لجنة معايير JavaScript، مع التغييرات في مراحلها المرقمة. قد تكون الميزات الجديدة في React متاحة في الإطارات التي تعتمد على React قبل أن تصبح متاحة في إصدار مستقر لـ React، تمامًا كما يتم إضافة ميزات JavaScript الجديدة في المتصفحات قبل أن يتم التصديق عليها رسميًا كجزء من المواصفة.
لماذا لا نستخدم الإصدارات التجريبية بدلاً من ذلك؟
رغم أنه نظريًا يمكنك استخدام الإصدارات التجريبية، إلا أننا نوصي بعدم استخدامها في الإنتاج لأن واجهات التطبيق البرمجية التجريبية قد تتعرض لتغييرات جذرية كبيرة أثناء استقرارها (أو يمكن إزالتها تمامًا). على الرغم من أن القنوات التجريبية قد تحتوي أيضًا على أخطاء (كما هو الحال في أي إصدار آخر)، إلا أننا نعتزم في المستقبل الإعلان عن أي تغييرات جذرية كبيرة في القنوات التجريبية عبر مدونتنا. تعتبر القنوات التجريبية هي الأقرب إلى الكود الذي يتم تشغيله داخليًا في Meta، لذا يمكنك بشكل عام توقع أن تكون النسخ التجريبية نسبيًا مستقرة. ومع ذلك، يتعين عليك تثبيت الإصدار وفحص سجل التزامات GitHub يدويًا عند التحديث بين الإصدارات المثبتة.
نتوقع أن معظم الأشخاص الذين يستخدمون React خارج بيئة تمت تجميعها مسبقًا (مثل إطار عمل) يفضلون الاستمرار في استخدام الإصدارات الثابتة. ومع ذلك، إذا كنت تقوم ببناء إطار عمل، قد ترغب في النظر في تضمين نسخة Canary من React مرتبطة بالتزام معين، وتحديثها وفقًا لخطة العمل الخاصة بك. الفائدة من ذلك هي أنه يتيح لك إطلاق ميزات React المكتملة وإصلاحات الأخطاء بشكل فردي في وقتٍ سابق لمستخدميك ووفقًا لجدول الإصدارات الخاص بك، بشكلٍ مشابه لما قامت به React Native خلال السنوات القليلة الماضية. العاقبة هي أنه ستتحمل مسؤولية إضافية لاستعراض التزامات React التي تم استخراجها وإبلاغ مستخدميك بالتغييرات التي تم تضمينها في إصداراتك.
إن كنت مؤلف إطار عمل وتريد تجربة هذا النهج، يرجى التواصل معنا.
الإعلان عن التغييرات الجذرية والميزات الجديدة مبكرًا
تُمثِّل إصدارات Canary أفضل توقع لدينا بشأن ما سيتم ضمه في الإصدار المستقر التالي لـ React في أي وقت محدد.
تقليديًا، كنا نعلن فقط عن التغييرات الجذرية في “نهاية” دورة الإصدار (عند إصدار إصدار رئيسي). والآن أن إصدارات Canary أصبحت طريقة مدعومة رسميًا للاستفادة من React، نعتزم التحول إلى الإعلان عن التغييرات الجذرية والميزات الجديدة الكبيرة “عند حدوثها” في الإصدارات Canary. على سبيل المثال، إذا دمجنا تغييرًا جذريًا سيتم تنفيذه في إصدار Canary، سنكتب مقالًا عنه في مدونة React، بما في ذلك رموز التحويل وتعليمات الهجرة إذا لزم الأمر. بعد ذلك، إذا كنت كمطور إطار عمل تقوم بإصدار إصدار رئيسي يُحدّث النسخة المثبتة من React Canary لتضمّن هذا التغيير، يمكنك ربط مقالة المدونة الخاصة بنا في ملاحظات الإصدار الخاصة بك. وأخيرًا، عندما يكون الإصدار الرئيسي المستقر لـ React جاهزًا، سنربط تلك المقالات المنشورة بالفعل، والتي نأمل أن تساعد فريقنا على التقدم بشكلٍ أسرع.
نخطط لتوثيق واجهات البرمجة كما تتوفر في الإصدارات Canary - حتى لو لم تكن هذه الواجهات متاحة بعد خارجها. سنقوم بوضع علامة خاصة على الصفحات المقابلة لتلك الواجهات البرمجية التي تكون متاحة فقط في الإصدارات Canary. وذلك سيشمل واجهات برمجة التطبيقات مثل use وبعض الواجهات الأخرى مثل cache و createServerContext التي سنقوم بإرسال مقترحات RFC لها.
يجب تثبيت القنوات التجريبية
إذا قررت اعتماد سير العمل Canary لتطبيقك أو إطار عملك، تأكد دائمًا من تثبيت الإصدار الدقيق من Canary الذي تستخدمه. نظرًا لأن القنوات التجريبية هي إصدارات مسبقة، قد تحتوي على تغييرات جذرية.
مثال: React Server Components
كما أعلنا في مارس، تم الانتهاء من توثيقات React Server Components، ولا نتوقع تغييرات جذرية كبيرة تتعلق بعقد واجهة برمجة التطبيقات الخاصة بهم. ومع ذلك، لا يمكننا إصدار دعم لـ React Server Components في إصدار مستقر من React بعد لأننا لا نزال نعمل على عدة ميزات متشابكة فقط للإطار (مثل تحميل الأصول) ونتوقع المزيد من التغييرات الجذرية هناك.
هذا يعني أن مكونات React Server Components جاهزة للاعتماد من قِبَل الإطارات. ومع ذلك، حتى صدور الإصدار الرئيسي التالي من React، الطريقة الوحيدة لإطار لاعتماد تلك المكونات هي شحن إصدار Canary محدد من React. (لتجنب تضمين نسختين من React، يحتاج الإطارات التي ترغب في القيام بذلك إلى تحديد استخدام إصدار معين من Canary لـ react و react-dom وشرح ذلك لمستخدميها. كمثال، هذا ما يفعله Next.js App Router.)
اختبار المكتبات ضد الإصدارات الثابتة والقنوات التجريبية
لا يُتوقع من مؤلفي المكتبات أن يقوموا باختبار كل إصدار “Canary” بشكل فردي، حيث أن ذلك سيكون صعبًا للغاية. ومع ذلك، تمامًا كما فعلنا عندما قدمنا قنوات الإصدار المختلفة لـ React قبل ثلاث سنوات، نشجع المكتبات على إجراء الاختبارات لكلٍ من أحدث إصدار “Stable” وأحدث إصدار “Canary”. إذا لاحظت تغييرًا في السلوك لم يتم الإعلان عنه، يُرجى تقديم تقرير عن الخطأ في مستودع React حتى نتمكن من المساعدة في تشخيصه. نتوقع أنه مع انتشار هذه الممارسة على نطاق واسع، ستنخفض كمية الجهد المطلوبة لترقية المكتبات إلى إصدارات رئيسية جديدة من React، حيث ستتم اكتشاف التراجعات العرضية بمجرد حدوثها.
تعمل الإصدارات الثابتة كما كانت
لم نقم بإدخال أي تغييرات على إصدارات React الثابتة.