أصدرت Jotai، مكتبة إدارة الحالة الذرية لـ React التي أنشأتها Daishi Kato، Jotai v2.20.0، وهو تحديث يركز على الأداء يعيد صياغة وحدات بناء المتجر الداخلي للمكتبة ويمهد الطريق لإصدار Jotai v3 المستقبلي.
يركز Jotai v2.20.0 على موضوع واحد: تحسين الأداء في السيناريوهات عالية الإنتاجية. يُنسب الإصدار إلى المساهم الأساسي ديفيد ماسكاسكي ويحقق مجموعة صغيرة من التغييرات الداخلية، بما في ذلك تجنب getInternalBuildingBlock الدالة (#3293)، تضييق نوع Rev3 لـ onMount خطافات (#3311)، وخطافات كسولة ensureAtomState لحالة الذرة الجديدة (#3313).
التغيير له تاريخ طويل. كما أوضح كاتو في رسالته الإخبارية “اقرأ الكود”، فإن فكرة العناصر الأساسية وصلت لأول مرة إلى الإصدار 2.12.0 منذ أكثر من عام، مما أدى إلى الكشف عن بعض الأجزاء الداخلية حتى تتمكن مكتبات النظام البيئي مثل jotai-effect و jotai-scope يمكن أن تمتد جوهر جوتاي. بدلاً من السماح بتوسيع المتجر بعد الإنشاء، وهو ما كان يخشى أن يؤدي إلى عدم تطابق القدرات مع مرور الوقت، اختار كاتو قبول التخصيص في لحظة إنشاء المتجر. لقد كتب أن واجهة برمجة التطبيقات (API) أصبحت مرنة وآمنة، أو يصعب إساءة استخدامها، عند الإصدار 2.15.0 تقريبًا.
وجاءت هذه المرونة بتكلفة. أبلغ شخص ما عن تراجع في الأداء، وكان السبب الرئيسي هو استخدام WeakMap، والتي تم تقديمها لجعل وحدات البناء أكثر مرونة (#3280). يقوم الإصلاح بتبديل نهج WeakMap لتمرير كل شيء كمعلمات بدلاً من ذلك. وصف كاتو الحل بأنه “ليس نظيفًا للغاية، ولكنه يتناسب مع نموذجي العقلي”، ووصف الإصدار بأنه الخطوة الأخيرة قبل أن يبدأ في التفكير بجدية في Jotai v3.
بالنسبة لمعظم المطورين، لا يتم المساس بواجهة برمجة التطبيقات اليومية. يبدو إنشاء متجر واستخدامه تمامًا كما كان من قبل.
تنطبق علامة القطع على كتل البناء الداخلية التي يستخدمها مؤلفو المكتبة، وليس على رمز التطبيق النموذجي. ويكون التأثير مرئيًا في اتجاه مجرى النهر، حيث أضاف الإصدار 0.14.0 من jotai-devtools دعمًا لـ INTERNAL_buildStoreRev3 وأسقطت الإصدارات الأقدم لتظل متوافقة. يجب على الفرق التي لا تزال تستخدم Jotai v1 الرجوع إلى دليل الترحيل الرسمي v2، وتلك التي تعتمد عليه atomFamily يجب ملاحظة أنه تم إهماله قبل الإصدار 3 لصالح jotai-family طَرد. لقد تم بالفعل شحن تصحيحين للمتابعة، v2.20.1 وv2.20.2، لمعالجة المزيد من حالات الحافة.
لقد تم تجاهل رد فعل المجتمع المباشر على إصدار النقاط، وذلك تماشيًا مع طبيعته السرية، على الرغم من أن الأفكار الجارية لفترة أطول لمناقشة الإصدار الثالث تستمر في جذب المساهمين. في هذا الموضوع، أوضح كاتو خطة الإصدار 3 التي تتضمن بشكل صريح إعادة تصميم بنية مصفوفة كتل البناء، والأجزاء الداخلية التي يمسها هذا الإصدار، إلى جانب إسقاط إصدارات CommonJS، وإسقاط دعم React أقل من 18، وإزالة setSelf خيار.
وقد أثارت هذه المقترحات التعليقات، حيث ركز أحد المساهمين على إسقاط CJS:
فيما يتعلق بإسقاط CJS – لا أعتقد أن هذا ينبغي أن يكون سؤالاً. 99,9999% من مستخدمي Jotai يستخدمون نوعًا ما من أدوات التجميع، وكلها تدعم ESM بشكل جيد. أما الـ 0.0001% المتبقية فهم مستخدمون يستخدمون وحدات ESM خالصة، وفي هذه الحالة… حسنًا… إنهم يستخدمون وحدات ESM:D
يسلط رد Kato الضوء على أن مستخدمي العرض من جانب الخادم ما زالوا بحاجة إلى أخذهم في الاعتبار. قوبلت الاقتراحات الرامية إلى تخفيف اقتران Jotai مع React ومحاكم الأطر الأخرى بموقف React-first الصارم.
في المشهد الأوسع، يظل Jotai هو الخيار الذري الرائد بينما يجلس خلف Zustand الخاص بـ Kato في التنزيلات الأولية. تؤطر المقارنة الخاصة بالمشروع Jotai كذرات من أسفل إلى أعلى تشبه Recoil، في حين تقدم Zustand متجرًا واحدًا من أعلى إلى أسفل أقرب إلى Redux، ويستهدف Valtio القائم على وكيل Kato نموذجًا عقليًا مختلفًا مرة أخرى.
Jotai مفتوح المصدر بموجب ترخيص MIT ويمكن تثبيته من npm.
