تغییرات زیرپوستی و تمرکز بر عملکرد
دایشی کاتو، توسعهدهنده کتابخانه مدیریت استیت اتمی جوتای (Jotai) برای ریاکت، نسخه 2.20.0 را در دسترس قرار داده است. این آپدیت با هدف ارتقای سرعت و کارایی در سناریوهای با بازدهی بالا (high-throughput) عرضه شده و موتور داخلی استور را برای آغاز فاز توسعه نسخه 3 بازطراحی میکند.
نسخه 2.20.0 روی یک محور مشخص استوار است: ارتقای سرعت و کارایی در فشارهای پردازشی بالا. دیوید ماسکاسکی (David Maskasky)، مشارکتکننده اصلی این پروژه، نقش پررنگی در رهاسازی این نسخه داشته است. تغییرات این نسخه شامل حذف تابع getInternalBuildingBlock، محدودسازی نوع Rev3 برای هوکهای onMount و استفاده از هوکهای تنبل (lazy) در ensureAtomState برای استیتهای اتمی جدید است.
ریشههای تغییر و حل مشکل WeakMap
تغییرات اعمالشده ریشه در تاریخچه توسعه کتابخانه دارند. کاتو در خبرنامه Read the Code خود اشاره میکند که ایده بلوکهای سازنده (building blocks) بیش از یک سال پیش و با نسخه 2.12.0 وارد توسعه شد تا بخشهایی از کدهای داخلی را در اختیار کتابخانههای اکوسیستم نظیر jotai-effect و jotai-scope قرار دهد. او به جای اجازه به گسترش استور پس از ایجاد - که نگران بروز ناهماهنگی قابلیتها در طول زمان بود - سفارشیسازی را در لحظه ساخت استور پذیرفت. این API در نسخه 2.15.0 به سطحی از انعطاف و امنیت رسید که سوءاستفاده از آن را دشوار کرد.
این انعطافپذیری البته هزینهای در بر داشت. با گزارش افت عملکرد (performance regression) از سوی کاربران، مشخص شد عامل اصلی این مشکل استفاده از ساختار WeakMap است. این ساختار داده پیشتر برای افزایش انعطافپذیری بلوکهای سازنده معرفی شده بود. راهحل ارائهشده، کنار گذاشتن WeakMap و پاس دادن تمام دادهها به عنوان پارامتر بود. کاتو این راهحل را گرچه «چیزی فوقالعاده تمیز نیست، اما با مدل ذهنی من همخوانی دارد» توصیف میکند و آن را آخرین گام پیش از فکر جدی به Jotai v3 میداند.
تاثیرات روی توسعهدهندگان و ابزارهای جانبی
برای اکثر توسعهدهندگان، رابط کاربری روزمره تغییری نکرده است. ایجاد و استفاده از استور دقیقاً مشابه گذشته است. برچسب breaking change در این نسخه صرفاً به بلوکهای داخلی محدود میشود که توسعهدهندگان کتابخانهها به آنها وابستهاند. اثر این تغییرات در پاییندست خود را نشان داد؛ ابزار jotai-devtools در نسخه 0.14.0 خود از INTERNAL_buildStoreRev3 پشتیبانی کرده و سازگاری با نسخههای قدیمیتر را برای حفظ هماهنگی قطع کرد.
تیمهایی که هنوز روی Jotai v1 هستند باید راهنمای مهاجرت رسمی به v2 را بررسی کنند. کاربرانی که به atomFamily تکیه دارند باید توجه کنند که این ویژگی پیش از v3 منسوخ شده و جای خود را به پکیج jotai-family داده است. دو پچ رفع اشکال با عنوانهای 2.20.1 و 2.20.2 نیز بلافاصله برای پوشش موارد لبهای (edge cases) عرضه شدند.
آینده نسخه 3 و کنار گذاشتن CommonJS
با توجه به ماهیت زیرپوستی این آپدیت، واکنش مستقیم جامعه کاربری محدود بوده است، اما بحثهای پیرامون معماری نسخه 3 همچنان مشارکتکنندگان را جذب میکند. کاتو در این میان نقشه راهی برای v3 ارائه داده که بازطراحی ساختار آرایه بلوکهای سازنده، کنار گذاشتن بیلدهای CommonJS، توقف پشتیبانی از ریاکت زیر نسخه 18 و حذف گزینه setSelf را شامل میشود.
یکی از مشارکتکنندگان درباره حذف CJS گفت: «کاربران Jotai در حد 99.9999 درصد از ابزارهای باندلر استفاده میکنند که همگی به خوبی از ESM پشتیبانی میکنند. 0.0001 درصد باقیمانده هم کاربران ESM خالص هستند، پس اصلاً نباید سوال باشد.» کاتو در پاسخ تاکید کرد که کاربران رندر سمت سرور (SSR) همچنان نیازمند توجه هستند. پیشنهاداتی برای کاهش وابستگی Jotai به ریاکت و حمایت از فریمورکهای دیگر با موضع قاطع و حفظ اولویت ریاکت روبرو شد.
جایگاه Jotai در میان رقبا
در چشمانداز وسیعتر، Jotai همچنان گزینه پیشرو مدیریت استیت اتمی است، اگرچه در آمار دانلود خام پس از Zustand قرار دارد که آن نیز از ساختههای کاتو است. مقایسههای رسمی پروژه نشان میدهد Jotai بر پایه اتمهای پایینبهبالا (bottom-up) و شبیه به Recoil بنا شده، در حالی که Zustand یک استور بالابهپایین (top-down) نزدیک به Redux ارائه میدهد. با نزدیک شدن به انتشار نسخه 3، توسعهدهندگان میتوانند انتظار یک معماری لاغرتر، وابستگی کمتر به ساختارهای قدیمی و تمرکز خالصتر بر اکوسیستم ESM را داشته باشند. Jotai متنباز و تحت لایسنس MIT است و امکان نصب آن از طریق npm فراهم است.
