مفهوم State Management وبدائل Redux

مقدمة

كل تطبيق React يعتمد على state. زر يفتح modal، مستخدم مسجل دخول، نتائج بحث، بيانات منتج، theme، لغة، أو form كبير. المشكلة تبدأ عندما نضع كل هذه الأنواع في مكان واحد ونتعامل معها بنفس الطريقة.

Redux حل قوي، لكنه ليس دائما الحل المناسب. في كثير من الحالات، تكون المشكلة ليست "نحتاج Redux"، بل "نحتاج نفهم أين يجب أن تعيش هذه الحالة".

ما معنى State؟

الـ state هي أي معلومة تؤثر على شكل الواجهة أو سلوكها. إذا تغيرت هذه المعلومة، قد تحتاج الواجهة إلى إعادة تصيير.

أمثلة:

• هل القائمة الجانبية مفتوحة؟
• من هو المستخدم الحالي؟
• ما الصفحة الحالية في جدول البيانات؟
• هل الطلب قيد التحميل؟
• ما المنتجات القادمة من API؟

لكن هذه الأمثلة ليست من نفس النوع، ولذلك لا يجب إدارتها بنفس الأداة دائما.

أنواع الـ State في React

أول نوع هو local state. هذه حالة تخص مكونا أو جزءا صغيرا من الصفحة.

أمثلة:

• فتح وإغلاق dropdown.
• قيمة input مؤقتة.
• tab نشط.
• hover أو selected item داخل component.

هذا النوع غالبا يكفيه useState أو useReducer.

النوع الثاني هو shared client state. هذه حالة يحتاجها أكثر من مكان في التطبيق.

أمثلة:

• بيانات المستخدم الحالي.
• theme.
• اللغة الحالية.
• محتوى cart في متجر إلكتروني.

هنا قد تحتاج Context أو Zustand أو Redux حسب حجم التعقيد.

النوع الثالث هو server state. هذه بيانات مصدرها السيرفر وليست ملكا حقيقيا للواجهة.

أمثلة:

• قائمة المقالات.
• تفاصيل منتج.
• نتائج البحث.
• بيانات dashboard.

هذا النوع يحتاج تفكيرا مختلفا لأنه يرتبط بالـ caching، إعادة الجلب، التزامن، وحالات loading/error.

متى يكفي useState؟

استخدم useState عندما تكون الحالة بسيطة وقريبة من مكان استخدامها.

const [isOpen, setIsOpen] = useState(false);

لا يوجد داع لنقل state إلى global store إذا كان مكون واحد فقط يحتاجها. كلما أبقيت state قريبة من مكان استخدامها، أصبح الكود أسهل في الفهم.

متى تستخدم useReducer؟

useReducer مفيد عندما تكون تحديثات state متعددة أو مرتبطة ببعضها.

function reducer(state, action) {
  switch (action.type) {
    case "open":
      return { ...state, isOpen: true };
    case "close":
      return { ...state, isOpen: false };
    default:
      return state;
  }
}

استخدمه عندما يصبح setState المتكرر غير واضح، خصوصا في Forms أو مكونات لها حالات كثيرة.

متى تستخدم Context؟

Context مناسب لتمرير بيانات عامة لا تتغير كثيرا، مثل theme أو language أو user session.

لكن استخدام Context كبديل مباشر لـ Redux في كل شيء قد يسبب مشاكل أداء وتعقيد. إذا تغيرت قيمة Context كثيرا، قد تعيد تصيير أجزاء كبيرة من التطبيق.

قاعدة عملية: Context جيد للبيانات العامة المستقرة نسبيا، وليس لكل update سريع ومتكرر.

أين يأتي Redux؟

Redux ممتاز عندما يكون لديك state معقدة، transitions واضحة، واحتياج قوي للتتبع والتنظيم. مثلا:

• تطبيق dashboard كبير.
• cart مع قواعد كثيرة.
• workflow متعدد الخطوات.
• تطبيق يحتاج debugging قوي باستخدام Redux DevTools.

قوة Redux في أنه يجعل التحديثات صريحة ومتوقعة. لكن هذه القوة تأتي مع تكلفة: boilerplate أكثر، تنظيم أكثر، ومفاهيم يجب على الفريق فهمها.

مع Redux Toolkit أصبحت التجربة أسهل كثيرا، لذلك إذا احتجت Redux فعلا، استخدم Redux Toolkit وليس Redux التقليدي.

Zustand كبديل بسيط

Zustand مكتبة خفيفة لإدارة global state بدون تعقيد كبير.

import { create } from "zustand";

export const useUserStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user }),
  logout: () => set({ user: null }),
}));

ثم تستخدمها داخل component:

const user = useUserStore((state) => state.user);

Zustand مناسب عندما تريد global state بسيطة وواضحة بدون boilerplate كثير.

TanStack Query للـ Server State

من أكبر الأخطاء وضع بيانات API داخل Redux لمجرد أنها مشتركة. بيانات السيرفر لها احتياجات خاصة:

• caching.
• refetch.
• stale data.
• pagination.
• retries.
• optimistic updates.

TanStack Query مصمم لهذه المشاكل.

const { data, isLoading, error } = useQuery({
  queryKey: ["articles"],
  queryFn: fetchArticles,
});

بدل أن تكتب loading/error/cache logic بنفسك، تحصل عليها بطريقة منظمة.

كيف تختار؟

ابدأ بالسؤال: ما نوع هذه الحالة؟

إذا كانت محلية، استخدم useState.

إذا كانت محلية لكن تحديثاتها معقدة، استخدم useReducer.

إذا كانت عامة وبسيطة، استخدم Context.

إذا كانت عامة وتحتاج store خفيف، استخدم Zustand.

إذا كانت قادمة من API، فكر في TanStack Query.

إذا كان التطبيق كبيرا ويحتاج قواعد state واضحة وأدوات debugging قوية، استخدم Redux Toolkit.

خطأ شائع: اختيار المكتبة قبل فهم المشكلة

أحيانا يبدأ المشروع بسؤال: "هل نستخدم Redux أم Zustand؟" بينما السؤال الأفضل: "ما البيانات التي سنشاركها؟ وكم مرة تتغير؟ ومن يملكها؟"

الأداة يجب أن تأتي بعد فهم المشكلة، وليس قبلها.

الخلاصة العملية

إدارة الحالة الجيدة لا تعني وضع كل شيء في global store. القاعدة الأفضل هي أن تبقي state قريبة من مكان استخدامها، ثم ترفعها فقط عندما يظهر سبب واضح.

Redux ما زال قويا ومفيدا، لكنه ليس الخيار الافتراضي لكل مشروع React. افهم نوع الحالة أولا، ثم اختر الأداة التي تحل المشكلة بأقل تعقيد ممكن.