Redux ليس الأداة الخاطئة. إنه مجرد أداة ثقيلة جداً في كثير من الأحيان.
في العديد من تطبيقات React الحديثة، فإن أكبر احتياجات الحالة العالمية ليست هي سير العمل المعتمد على الأحداث. بل هي أشياء مثل:
- حالة النوافذ المنبثقة
- حالة الشريط الجانبي
- الفلاتر النشطة
- تفضيلات المستخدم
لهذا النوع من الحالة، غالبًا ما يشعر Zustand بأنه أكثر نظافة لأنه يقدم لك متجرًا خارجيًا صغيرًا دون طقوس المكونات، والإجراءات، ومزودات الحالة في كل مكان.
هيكل Zustand النمطي
import { create } from "zustand";
type UiStore = {
isSidebarOpen: boolean;
toggleSidebar: () => void;
};
export const useUiStore = create<UiStore>((set) => ({
isSidebarOpen: false,
toggleSidebar: () =>
set((state) => ({ isSidebarOpen: !state.isSidebarOpen })),
}));
يمكن للمستهلكين الاشتراك فقط في الجزء الذي يحتاجونه:
const isSidebarOpen = useUiStore((state) => state.isSidebarOpen);
هذا عادة ما يكون كافيًا لكثير من واجهة منتجات التطبيقات.
الانقسام المعماري الحقيقي
تواجه الفرق مشاكل عندما تخزن الكثير من حالة الخادم في نفس المتجر العالمي. عادة ما يتم التعامل مع نتائج API المخزنة وسلوك إعادة التحميل والتحديثات المتفائلة وإبطال التحديث والمزامنة الخلفية بشكل أفضل بواسطة أدوات حالة الخادم مثل React Query.
هذا يعني أن الانقسام الحديث غالبًا ما يبدو مثل:
- Zustand لحالة واجهة المستخدم
- React Query لحالة الخادم
هذا أكثر فائدة من محاولة اختيار متجر واحد لامتلاك كل شيء.
التنازلات
لا يزال Redux منطقيًا عندما:
- تحتاج انتقالات الحالة إلى هيكل صارم
- يريد الفريق نمذجة حالات قائمة على الأحداث بشكل صريح
- تكون الأدوات حول المكونات وmiddleware قيمة
Zustand هو المنطقي عندما تكون البساطة والاشتراكات الانتقائية هي المكاسب الأكبر.
مزيد من القراءة