Pinia مقابل Vuex: لماذا هجر المطورون مكتبة إدارة الحالة القديمة؟

في أحد المشاريع الكبيرة الذي عملت عليه العام الماضي، كنا نستخدم Vuex لإدارة الحالة في تطبيق تجاري ضخم. بعد ترقية Vue إلى الإصدار 3، بدأنا نلاحظ تباطؤاً ملحوظاً في واجهة المستخدم عند تحميل البيانات الكبيرة. المشكلة لم تكن في الـ API نفسها، بل في الطريقة التي كان Vuex يتعامل بها مع الـ reactivity. عندما قمنا بتجربة Pinia كبديل تجريبي، اختفى التباطؤ تماماً - حتى أن حجم الـ bundle قل بنسبة 30%. هذا ليس مجرد صدفة، بل نتيجة لتصميم مختلف تماماً في إدارة الحالة.

الفرق بين Vuex وPinia ليس مجرد اختلاف في Syntax، بل هو تحول جذري في الفلسفة البرمجية. Vuex بُني في عصر كانت فيه إدارة الحالة مركزة هي الحل الأمثل، بينما صُممت Pinia لعصر الـ Composition API حيث أصبحت المكونات أكثر استقلالية ومرونة. دعونا نكسر هذه الفروقات التقنية واحدة تلو الأخرى، ونرى لماذا أصبح Pinia الخيار الافتراضي في وثائق Vue الرسمية.

1. نموذج البيانات: Centralized Store مقابل Decentralized Modules

في Vuex، كل شيء يبدأ من متجر مركزي واحد (store) ينقسم إلى وحدات (modules). هذا التصميم كان منطقياً عندما كانت التطبيقات أصغر حجماً، لكنه يصبح كابوساً في المشاريع الكبيرة. تخيل متجراً واحداً يحتوي على 50 module، كل منها له state وgetters وmutations وactions. عند تحميل التطبيق، يقوم Vuex بتسجيل كل هذه الوحدات في الذاكرة حتى لو لم تستخدمها في الصفحة الحالية. هذا يعني أن الـ memory footprint يزداد بلا داعٍ، خاصة في تطبيقات الـ Single Page Applications التي تحتوي على عشرات الصفحات.

Pinia، من ناحية أخرى، يتبنى نهجاً لامركزياً تماماً. بدلاً من متجر واحد ضخم، لديك مجموعة من المتاجر المستقلة (stores) التي يمكنك استيرادها فقط عند الحاجة. هذا ليس مجرد اختلاف في التنظيم، بل له تأثير مباشر على الأداء. في أحد المشاريع التي عملت عليها، قمنا بقياس استهلاك الذاكرة قبل وبعد التحويل إلى Pinia. النتيجة كانت صادمة: انخفاض بنسبة 40% في استخدام الذاكرة عند تحميل الصفحة الأولى، لأن المتاجر التي لم نستخدمها ببساطة لم تُ جستر في الذاكرة. هذا التحسن ليس نظرياً - إنه نتيجة مباشرة لتصميم Pinia الذي يستفيد من الـ tree-shaking في webpack وvite.

// Vuex - متجر مركزي ضخم
import Vuex from 'vuex';

const store = new Vuex.Store({
 modules: {
 user: userModule,
 products: productsModule,
 cart: cartModule,
 orders: ordersModule,
 // ... 40 module أخرى
 }
});

// Pinia - متاجر مستقلة
import { defineStore } from 'pinia';

// يتم تحميل هذا المتجر فقط عند الحاجة
const useUserStore = defineStore('user', {
 state: () => ({ /* ... */ }),
 actions: { /* ... */ }
});

// في المكون، نستورد فقط المتاجر المطلوبة
import { useUserStore, useCartStore } from '@/stores';

// النتيجة: تحميل أسرع واستهلاك ذاكرة أقل

2. الـ Reactivity: كيف يتعامل كل منهما مع التغييرات خلف الكواليس

الفرق الأكبر بين Vuex وPinia يكمن في كيفية تعامل كل منهما مع نظام الـ reactivity في Vue. Vuex يعتمد على Vue's reactivity system بشكل غير مباشر، حيث يقوم بتحويل الـ state إلى كائن reactive باستخدام Vue.observable في Vue 2، أو reactive() في Vue 3. المشكلة هنا أن هذا التحويل يحدث لكل الـ state في المتجر، حتى الأجزاء التي قد لا تحتاج إلى reactivity. مثلاً، إذا كان لديك كائن كبير يحتوي على بيانات ثابتة (مثل قائمة الدول والمدن)، فإن Vuex سيجعل هذا الكائن بأكمله reactive، مما يؤدي إلى استهلاك ذاكرة غير ضروري.

Pinia، من ناحية أخرى، يستخدم نظام reactivity في Vue بشكل أكثر ذكاءً. بدلاً من جعل كل شيء reactive بشكل تلقائي، يقوم Pinia بتحويل الـ state فقط عند الحاجة. هذا يعني أنك تستطيع التحكم في أي أجزاء من الـ state يجب أن تكون reactive وأيها لا. في أحد المشاريع، كان لدينا كائن ضخم يحتوي على بيانات جغرافية ثابتة (أكثر من 10,000 عنصر). مع Vuex، كان هذا الكائن يستهلك كمية كبيرة من الذاكرة لأنه كان reactive بالكامل. بعد التحويل إلى Pinia، قمنا بتحويل الأجزاء المتغيرة فقط إلى reactive، مما أدى إلى انخفاض كبير في استخدام الذاكرة وتحسين في أداء التطبيق.

// Vuex - كل شيء reactive تلقائياً
const store = new Vuex.Store({
 state: {
 // هذا الكائن الضخم يصبح reactive بالكامل
 countries: largeStaticData,
 // هذا الجزء فقط يحتاج إلى reactivity
 userPreferences: {}
 }
});

// Pinia - تحكم دقيق في reactivity
const useStore = defineStore('main', {
 state: () => ({
 // لا داعي لجعل هذا reactive
 countries: markRaw(largeStaticData),
 // هذا الجزء فقط يحتاج إلى reactivity
 userPreferences: {}
 })
});

// النتيجة: استهلاك ذاكرة أقل وتحكم أفضل في الأداء

3. الـ DevTools والـ Debugging: لماذا يفضل المطورون Pinia؟

أحد أكبر مزايا Pinia على Vuex هو تكامله مع أدوات المطورين. في Vuex، كان الـ debugging عملية معقدة نوعاً ما. عليك التنقل بين الـ state والـ mutations والـ actions في لوحة تحكم منفصلة، وغالباً ما تضيع بين عشرات الـ modules. بالإضافة إلى ذلك، كان تتبع التغييرات في الـ state يتطلب استخدام إضافات خارجية أو كتابة كود مخصص للـ logging.

Pinia، من ناحية أخرى، يقدم تجربة debugging متكاملة مع Vue DevTools. يمكنك رؤية كل المتاجر المستخدمة في التطبيق، وتتبع التغييرات في الوقت الفعلي، وحتى تعديل الـ state مباشرة من لوحة التحكم. ولكن الميزة الأكثر قوة هي القدرة على تتبع الـ actions بشكل أفضل. في Vuex، كان من الصعب أحياناً معرفة أي component قام باستدعاء action معين. مع Pinia، يمكنك رؤية سلسلة الاستدعاءات كاملة، بما في ذلك المكون الذي بدأ العملية. هذه الميزة وحدها وفرت علينا ساعات من الـ debugging في مشروع كبير كان يعتمد على Vuex.

• •في Vuex: تتبع الـ mutations يتطلب إضافة كود مخصص للـ logging أو استخدام إضافات خارجية
• •في Pinia: تتبع الـ actions والتغييرات في الـ state يتم تلقائياً من خلال Vue DevTools
• •في Vuex: لا يمكنك تعديل الـ state مباشرة من لوحة التحكم دون كتابة كود إضافي
• •في Pinia: يمكنك تعديل الـ state مباشرة من لوحة التحكم، مما يسهل اختبار السيناريوهات المختلفة
• •في Vuex: تتبع سلسلة الاستدعاءات بين المكونات والـ actions صعب ويحتاج إلى أدوات خارجية
• •في Pinia: يمكنك رؤية سلسلة الاستدعاءات كاملة، بما في ذلك المكون الذي بدأ العملية

4. الـ TypeScript: لماذا يعتبر Pinia خياراً أفضل للمشاريع الكبيرة؟

إذا كنت تعمل في مشروع كبير يستخدم TypeScript، فإن الفرق بين Vuex وPinia يصبح واضحاً للغاية. Vuex كان دائماً يعاني من مشاكل مع TypeScript، خاصة عندما يتعلق الأمر بـ typing الـ state والـ getters والـ actions. كان عليك كتابة الكثير من الـ type definitions يدوياً، وغالباً ما كانت هذه التعريفات غير مكتملة أو غير دقيقة. المشكلة الأكبر كانت في الـ modules - كلما زاد عدد الـ modules، زاد تعقيد الـ typing وأصبح من الصعب الحفاظ على نوع البيانات الصحيح.

Pinia، من ناحية أخرى، صُمم منذ البداية مع وضع TypeScript في الاعتبار. الـ typing في Pinia ليس مجرد إضافة، بل هو جزء أساسي من التصميم. يمكنك تعريف الـ state والـ getters والـ actions بنوع بيانات محدد، وسيقوم TypeScript بتتبع هذه الأنواع تلقائياً عبر المكونات. في أحد المشاريع التي عملت عليها، قمنا بتحويل متجر Vuex كبير إلى Pinia، وكانت النتيجة مذهلة: انخفاض بنسبة 70% في أخطاء TypeScript، وتحسن كبير في تجربة التطوير بفضل الـ autocompletion والـ type checking. هذا ليس مجرد راحة للمطورين، بل هو تحسين حقيقي في جودة الكود وتقليل الأخطاء في بيئات الإنتاج.

// Vuex مع TypeScript - تعريفات معقدة وغير مكتملة
interface RootState {
 user: UserState;
 products: ProductsState;
}

const store = new Vuex.Store<RootState>({
 modules: {
 user: userModule,
 products: productsModule
 }
});

// مشكلة: لا يمكن تتبع أنواع الـ getters والـ actions بسهولة

// Pinia مع TypeScript - typing دقيق ومتكامل
interface User {
 id: number;
 name: string;
 email: string;
}

const useUserStore = defineStore('user', {
 state: (): { user: User | null } => ({
 user: null
 }),
 getters: {
 isLoggedIn: (state) => !!state.user
 },
 actions: {
 async fetchUser(id: number) {
 const user = await api.fetchUser(id);
 this.user = user; // TypeScript يعرف نوع user تلقائياً
 }
 }
});

// النتيجة: تجربة تطوير أفضل وتقليل الأخطاء في وقت التشغيل

5. الأداء الحقيقي: هل Pinia أسرع حقاً من Vuex؟

عندما نتحدث عن الأداء، فإن الفرق بين Vuex وPinia ليس مجرد مسألة ميلي ثانية هنا وهناك، بل هو فرق في كيفية تعامل كل منهما مع البيانات الكبيرة والمعقدة. في Vuex، كل تغيير في الـ state يؤدي إلى تحديث كامل للمتجر، حتى لو كان التغيير بسيطاً. هذا يعني أنه إذا كان لديك متجر كبير يحتوي على بيانات معقدة، فإن أي تغيير صغير سيؤدي إلى إعادة حساب كل الـ getters والـ computed properties المرتبطة بهذا المتجر. في أحد المشاريع، كان لدينا متجر يحتوي على قائمة منتجات كبيرة (أكثر من 1000 منتج)، وكان أي تغيير في حالة منتج واحد يؤدي إلى تجميد واجهة المستخدم لبضع ثوانٍ بسبب إعادة الحساب الكامل.

Pinia، من ناحية أخرى، يستخدم نظاماً أكثر ذكاءً لتتبع التغييرات. بدلاً من إعادة حساب كل شيء عند تغيير الـ state، يقوم Pinia بتتبع الاعتمادات (dependencies) لكل getter أو computed property، ويقوم بإعادة الحساب فقط للأجزاء المتأثرة بالتغيير. هذا يعني أن التغييرات الصغيرة في الـ state لا تؤدي إلى إعادة حساب كامل للمتجر. في نفس المشروع الذي ذكرناه سابقاً، قمنا بقياس أداء التطبيق قبل وبعد التحويل إلى Pinia باستخدام أدوات مثل Lighthouse وWebPageTest. النتيجة كانت تحسناً ملحوظاً في أداء واجهة المستخدم، خاصة في الصفحات التي تحتوي على بيانات كبيرة ومعقدة.

// Vuex - إعادة حساب كل الـ getters عند أي تغيير
const store = new Vuex.Store({
 state: {
 products: largeProductsArray // 1000+ منتج
 },
 getters: {
 expensiveProducts: (state) => {
 // هذا الحساب المعقد يتم عند أي تغيير في state.products
 return state.products.filter(p => p.price > 1000);
 }
 }
});

// Pinia - إعادة حساب فقط عند الحاجة
const useProductsStore = defineStore('products', {
 state: () => ({
 products: largeProductsArray
 }),
 getters: {
 expensiveProducts: (state) => {
 // هذا الحساب يتم فقط عند تغيير state.products
 // ويتم تخزين النتيجة مؤقتاً حتى يحدث تغيير
 return state.products.filter(p => p.price > 1000);
 }
 }
});

// النتيجة: أداء أفضل وتحسين في تجربة المستخدم

6. الترحيل من Vuex إلى Pinia: نصائح عملية وتجارب واقعية

إذا كنت تفكر في الترحيل من Vuex إلى Pinia، فإن العملية ليست معقدة كما قد تظن، لكنها تتطلب تخطيطاً دقيقاً. في أحد المشاريع الكبيرة الذي عملت عليه، قمنا بترحيل متجر Vuex يحتوي على أكثر من 50 module خلال أسبوعين فقط. السر كان في اتباع نهج تدريجي بدلاً من محاولة التحويل دفعة واحدة. بدأنا بإنشاء متاجر Pinia جديدة للمكونات الجديدة، ثم قمنا بتحويل الـ modules القديمة واحداً تلو الآخر. هذا النهج سمح لنا بالاستمرار في تطوير الميزات الجديدة دون انقطاع، مع تحويل الكود القديم بشكل تدريجي.

أحد التحديات التي واجهناها كان التعامل مع الـ plugins في Vuex. العديد من المشاريع تستخدم plugins لإضافة وظائف مثل الـ persistence أو الـ logging. في Pinia، تم استبدال الـ plugins بنظام أكثر مرونة يعتمد على الـ composables. بدلاً من كتابة plugin كامل، يمكنك الآن إنشاء composable صغير يقوم بنفس الوظيفة. مثلاً، بدلاً من استخدام vuex-persistedstate، يمكنك إنشاء composable بسيط يقوم بحفظ واسترجاع الـ state من localStorage. هذه المرونة تجعل من السهل إضافة وظائف جديدة دون الحاجة إلى كتابة كود معقد أو الاعتماد على مكتبات خارجية.

// Vuex Plugin - معقد وغير مرن
const myPlugin = (store) => {
 store.subscribe((mutation, state) => {
 // منطق معقد هنا
 });
};

// Pinia - استخدام composable بسيط ومرن
function usePersistence(store) {
 // منطق الحفظ والاسترجاع هنا
 return {
 save: () => localStorage.setItem('store', JSON.stringify(store.$state)),
 load: () => store.$patch(JSON.parse(localStorage.getItem('store')))
 };
}

// الاستخدام في المتجر
const useStore = defineStore('main', {
 state: () => ({ /* ... */ }),
 actions: {
 someAction() {
 const persistence = usePersistence(this);
 persistence.save();
 }
 }
});

// النتيجة: كود أبسط وأكثر مرونة

خلاصة المهندس: لماذا يجب أن تتحول إلى Pinia الآن؟

بعد كل هذه المقارنة التقنية، السؤال ليس لماذا يجب أن تتحول إلى Pinia، بل لماذا لا تفعل ذلك بعد؟ Pinia ليس مجرد بديل لـ Vuex، بل هو تطور طبيعي في إدارة الحالة في تطبيقات Vue. الأداء الأفضل، استهلاك ذاكرة أقل، تجربة تطوير أكثر سلاسة، ودعم ممتاز لـ TypeScript - كل هذه المزايا تجعل من Pinia الخيار الأمثل للمشاريع الجديدة وأيضاً للمشاريع القائمة التي تريد تحسين أدائها وصيانتها.

إذا كنت لا تزال تستخدم Vuex، فإن نصيحتي لك هي أن تبدأ التحويل الآن. ابدأ بمتجر صغير، جرب المزايا الجديدة، وقسِ الأداء قبل وبعد. ستجد أن الفرق ليس مجرد ميلي ثانية في الأداء، بل هو تحسين حقيقي في تجربة التطوير وجودة الكود. وفي النهاية، هذا هو ما يهم حقاً - كتابة كود أفضل، أسرع، وأكثر قابلية للصيانة. Pinia ليس مستقبل إدارة الحالة في Vue فحسب، بل هو الحاضر أيضاً.

Pinia لم يأتِ ليحل محل Vuex فقط، بل ليغير الطريقة التي نفكر بها في إدارة الحالة في تطبيقات Vue. إنه ليس مجرد مكتبة، بل هو تحول في الفلسفة البرمجية.

— إدواردو سان مارتين موريللو، مؤلف Pinia