هیچکدوم از این کتابخونهها state رو مدیریت نمیکنن
فرانتاند
ریاکت
جاوااسکریپتخلاصهٔ کاملتر
نویسنده با یه گفتوگوی تکراری شروع میکنه: به تیم میگه این رابط کاربری برای کاری که میکنه خیلی سنگینه، و جواب میگیره «پس بدون ریاکت چطور state رو مدیریت کنیم؟» — ولی همون تیم چند تا کتابخونهٔ دیگه هم برای همین کار داره. فهرستش بلنده: MobX، Satchel، Recoil، Jotai، XState، Apollo، Redux، TanStack Store و Zustand، که تقریباً همه با همون شعار «state management» معرفی میشن.
به گفتهٔ او اکوسیستم هنوز برندهای انتخاب نکرده و دیدن چند تا از اینها تو یه صفحه عادیه — اون هم روی فریمورکی که خودش صفحهها مستندات دربارهٔ امکانات مدیریت state ـش نوشته.
به گفتهٔ او یکی از این سه حالت درسته: یا ریاکت خودش یه سیستم مدیریت state ـه و یه وابستگی تکراری قاچاقی وارد پروژه شده، یا ریاکت سیستم ناکافیایه و نباید بخش نامشخصی از این مسئله رو بهش سپرد، یا اصلاً سیستم مدیریت state نیست و بهتره تظاهر نکنیم که هست. جوابش صریحه: هیچکدوم از این ابزارها state رو مدیریت نمیکنن. شاید اون رو کپسوله کنن، شاید بهروزرسانیها رو فیلتر یا تبدیل کنن، ولی کاری که واقعاً میکنن پخشِ محلیِ اعلانِ تغییر ـه؛ از نظر بیانی معادل event bus و pub/sub هستن.
تفاوت اصلی به گفتهٔ او بُعد زمانه. کتابخونههای حول ریاکت با زمان همونطوری برخورد میکنن که ++C با کد چندنخی. سیستمی که مفهوم درونیِ زمان و ترتیب نداره میتونه از بهروزرسانیهای بیترتیب و بدون برچسب زمانی یه state مرکب بسازه، ولی نمیتونه ادعای مدیریت داشته باشه، چون مدیریت state یعنی اعمال درست تغییرها در طول زمان و حل تعارضها. نویسنده میگه سیستمهای واقعی رو میشه از روی چیزی شبیه vector clock تو دلشون تشخیص داد: متادیتای زمان و ترتیب روی هر جهش، ترتیب سراسری رو ممکن میکنه.
این نگاه یه نکتهٔ مهم دیگه هم باز میکنه: اپی که در آینده دوباره بوت میشه، از نظر مفهومی با اپی که روی یه کامپیوتر کاملاً دیگه بالا میاد فرقی نداره. یعنی مسئله همون مدیریت داده بین چند ماشین و در گسترهٔ گذشته، حالا و آیندهست، و سیستمهای صرفاً پخشکننده زیر بار پیچیدگیِ ناشی از منابع و فرکانسهای مختلفِ بهروزرسانی، با یه انتزاعِ event bus کم میارن.
به گفتهٔ نویسنده، بحث CRDT، Operational Transform و Prolly Tree هنوز تو گفتمان فرانتاند کمیابه، ولی فاصلهٔ بین فهمیدن تئوری و استفادهٔ عملی کوتاهه. سه پیشنهاد عملیاش اینان: Y.js (تلاقی CRDT و ویرایش متن، که حالا خیلی عملیتر از چند سال پیشه)، Zero (جانشین Replicache، متنباز یا میزبانیشده، که میگه امروز روی یه پروژهٔ جدید از همین شروع میکرد) و Fluid (سیستم متنباز مایکروسافت با الهام از OT). چون اینها به زمان و تعارض فکر میکنن، برای offline-first عالیان و بعضیهاشون تا local-first واقعی هم میرن.
نکات کلیدی:
- «state management» عملاً پخشِ اعلانِ تغییره، نه مدیریت — معادل event bus و pub/sub
- مدیریت واقعی یعنی اعمال تغییرها در طول زمان و حل تعارض، با ترتیب و زمانبندی
- نشونهٔ سیستم واقعی: چیزی شبیه vector clock و متادیتای ترتیب روی جهشها
- این کتابخونهها دیتابیس نیستن؛ نه کوئری دارن نه راهحل درستی برای ماندگاری محلی
- گزینههای عملی امروز: Y.js، Zero و Fluid — با آفلاینفرست و همکاری بلادرنگ بهعنوان نتیجهٔ جانبی
