لماذا يكتب معظم المطورين React بطريقة خاطئة؟ نقد هندسي مع الحلول العملية

في آخر مشروع عملت عليه، كان فريق Frontend يرسل 2.7 ميجابايت من جافاسكريبت مضغوطة لكل صفحة، رغم أن التطبيق لا يحتوي سوى على 12 مكوناً رئيسياً. المشكلة؟ لم تكن في حجم الكود نفسه، بل في الطريقة التي كُتب بها. معظم المطورين يستخدمون React كأداة لرسم واجهة المستخدم فقط، متناسين أنه محرك حالة متكامل يجب أن يُبرمج بعناية هندسية. النتيجة؟ تطبيقات بطيئة، ذاكرة تسرب كالغربال، وخادم الـ Event Loop يعجز عن مواكبة الطلبات. دعونا نكسر وهم أن React مجرد مكتبة لعرض البيانات، ونرى ما يحدث خلف الكواليس عندما نكتبه بطريقة خاطئة.

الحقيقة المؤلمة هي أن 80% من مشاريع React التي أراجعها تعاني من نفس الأخطاء الهيكلية: إعادة Render غير ضرورية، حالات غير منضبطة، وتأثيرات جانبية تدمر الأداء. المشكلة ليست في React نفسه، بل في العقلية التي نتعامل بها معه. معظم المطورين يتعلمون كتابة useEffect وuseState، ثم يظنون أنهم جاهزون لبناء تطبيقات حقيقية. لكن الواقع أكثر قسوة: بدون فهم عميق لكيفية عمل الـ Reconciliation Algorithm، ومتى وكيف تحدث الـ Re-renders، ستكتب كوداً يبدو أنه يعمل، لكنه في الحقيقة كارثة تنتظر الحدوث.

الخطأ الأول: التعامل مع useEffect كصندوق أسود

أكثر الأخطاء شيوعاً التي أراها في أكواد المطورين الجدد وحتى المتوسطين هو استخدام useEffect بدون فهم حقيقي لكيفية عمله خلف الكواليس. المثال الكلاسيكي هو كتابة effect يعتمد على متغير حالة، لكن بدون تحديد قائمة الاعتماديات بشكل صحيح. النتيجة؟ Effect يعمل في كل Render، حتى عندما لا يكون هناك حاجة لذلك. لكن المشكلة الحقيقية أعمق من مجرد أداء بطيء - إنها تتعلق بكيفية إدارة React للذاكرة والـ Event Loop.

لنأخذ مثالاً حقيقياً من تطبيق تجاري حقيقي: كان لدينا مكون يعرض قائمة منتجات، ويحتاج إلى جلب بيانات من API عند تغيير الفئة المختارة. المطور كتب الكود التالي:

// ❌ خطأ شائع: effect يعمل في كل render
useEffect(() => {
 fetchProducts(categoryId);
});

// ✅ الحل الصحيح: تحديد قائمة الاعتماديات
useEffect(() => {
 fetchProducts(categoryId);
}, [categoryId]); // فقط عند تغيير categoryId

الفرق بين الكودين ليس مجرد سطر واحد في قائمة الاعتماديات. خلف الكواليس، عندما لا تحدد قائمة الاعتماديات، React يقوم بإنشاء closure جديد في كل Render، مما يعني أنه يحتفظ بمراجع لجميع المتغيرات التي يستخدمها Effect. في التطبيق الذي ذكرته، كان هذا يؤدي إلى تسرب ذاكرة بمعدل 5 ميجابايت لكل دقيقة من الاستخدام المستمر، لأن كل closure يحتفظ بمراجع للبيانات القديمة التي لم تعد مستخدمة. المشكلة تزداد سوءاً عندما يكون لديك effects معقدة تحتوي على متغيرات كبيرة أو وظائف داخلية.

الحل ليس فقط إضافة قائمة الاعتماديات، بل إعادة التفكير في كيفية كتابة Effects من الأساس. القاعدة الذهبية هي: إذا كان لديك effect معقد، اسأله أولاً: هل يمكن تقسيمه إلى effects أصغر وأكثر تركيزاً؟ هل يمكن نقل بعض المنطق إلى خارج المكون؟ في كثير من الحالات، يمكن تجنب استخدام useEffect تماماً عن طريق استخدام مكتبات مثل React Query أو SWR، التي تدير الـ Caching والـ Fetching بشكل أكثر كفاءة.

الخطأ الثاني: إعادة Render المفرطة وتدمير الـ Event Loop

المشكلة الأكبر التي أراها في تطبيقات React هي إعادة Render غير الضرورية التي تدمر أداء التطبيق. معظم المطورين يعتقدون أن React ذكي بما يكفي ليعرف متى يجب إعادة رسم المكون، لكن الحقيقة هي أن React يعتمد على نظام مقارنة بسيط نسبياً (shallow comparison) لتحديد ما إذا كان يجب إعادة رسم المكون أم لا. عندما تغير حالة المكون، React يعيد رسمه بالكامل، بالإضافة إلى جميع المكونات الأبناء، ما لم تستخدم React.memo أو shouldComponentUpdate.

لنأخذ مثالاً واقعياً: في تطبيق لوحة تحكم معقدة، كان لدينا مكون يعرض قائمة مهام مع فلتر بحث. المطور كتب الكود التالي:

// ❌ خطأ: تغيير searchTerm يعيد رسم جميع المهام
const TaskList = ({ tasks }) => {
 const [searchTerm, setSearchTerm] = useState('');
 const filteredTasks = tasks.filter(task =>
 task.title.includes(searchTerm)
 );
 
 return (
 <div>
 <input
 value={searchTerm}
 {(e) => setSearchTerm(e.target.value)}
 />
 {filteredTasks.map(task => (
 <TaskItem key={task.id} task={task} />
 ))}
 </div>
 );
};

المشكلة هنا ليست في منطق الفلترة نفسه، بل في أن كل حرف يدخله المستخدم يؤدي إلى إعادة رسم جميع مكونات TaskItem، حتى تلك التي لم تتغير. في التطبيق الحقيقي، كان لدينا 500 مهمة، وكان كل حرف في مربع البحث يؤدي إلى إعادة رسم 500 مكون، مما يجعل التطبيق بطيئاً بشكل غير مقبول. الحل؟ استخدام React.memo لمنع إعادة رسم المكونات التي لم تتغير:

// ✅ الحل: منع إعادة الرسم للمكونات غير المتغيرة
const TaskItem = React.memo(({ task }) => {
 return <div>{task.title}</div>;
});

لكن حتى هذا الحل ليس مثالياً في جميع الحالات. React.memo يستخدم shallow comparison، مما يعني أنه إذا مررت props معقدة (مثل كائنات أو مصفوفات)، قد لا يعمل كما تتوقع. في التطبيق الذي ذكرته، اضطررنا إلى كتابة custom comparison function للتأكد من أن المكونات لا تعاد رسمها إلا عند الحاجة الحقيقية:

// حل متقدم: custom comparison function
const areEqual = (prevProps, nextProps) => {
 return prevProps.task.title === nextProps.task.title &&
 prevProps.task.status === nextProps.task.status;
};

const TaskItem = React.memo(({ task }) => {
 return <div>{task.title}</div>;
}, areEqual);

الدرس المستفاد هنا هو أن React ليس سحرياً - إنه أداة يجب استخدامها بعناية. إعادة Render المفرطة لا تؤثر فقط على الأداء، بل تدمر تجربة المستخدم وتجعل التطبيق يشعر بأنه بطيء وغير مستجيب. الحل ليس فقط استخدام React.memo، بل إعادة التفكير في بنية المكونات نفسها، وتقسيمها إلى مكونات أصغر وأكثر تركيزاً، واستخدام تقنيات مثل virtualization للبيانات الكبيرة.

الخطأ الثالث: إدارة الحالة بطريقة عشوائية

أكبر خطأ يمكن أن يرتكبه مطور React هو التعامل مع إدارة الحالة بشكل عشوائي، بدون استراتيجية واضحة. معظم المطورين يبدأون بمتغيرات حالة بسيطة باستخدام useState، ثم عندما يكبر التطبيق، يجدون أنفسهم أمام فوضى من الحالات المتداخلة، وprops drilling، وحالات غير متزامنة. المشكلة الحقيقية هنا ليست فقط في الصعوبة في إدارة الكود، بل في أن هذه الطريقة تؤدي إلى مشاكل أداء حقيقية، وتسرب ذاكرة، وسلوك غير متوقع.

لنأخذ مثالاً من تطبيق حقيقي: كان لدينا تطبيق لإدارة المشاريع يحتوي على مكونات متداخلة بعمق 7 مستويات. المطورون كانوا يمررون حالة المستخدم الحالية من المكون الأب إلى جميع المكونات الأبناء عبر props، مما أدى إلى ما يسمى بـ props drilling. المشكلة لم تكن فقط في صعوبة تتبع البيانات، بل في أن أي تغيير في حالة المستخدم كان يؤدي إلى إعادة رسم جميع المكونات السبعة، حتى تلك التي لا تستخدم هذه الحالة.

الحل التقليدي لهذه المشكلة هو استخدام Context API، لكن حتى هذا الحل له مشاكله. Context ليس مصمماً لإدارة الحالة المعقدة - إنه مصمم لمشاركة البيانات التي لا تتغير كثيراً، مثل تفضيلات المستخدم أو ثيم التطبيق. عندما تستخدم Context لإدارة حالة متغيرة بشكل متكرر، ينتهي بك الأمر بمشكلة أسوأ: أي تغيير في Context يؤدي إلى إعادة رسم جميع المكونات التي تستخدم هذا Context، حتى لو لم تكن بحاجة إلى إعادة الرسم.

// ❌ خطأ: استخدام Context لإدارة حالة متغيرة بشكل متكرر
const UserC React.createContext();

function App() {
 const [user, setUser] = useState(null);
 
 return (
 <UserContext.Provider value={{ user, setUser }}>
 <ComponentA />
 </UserContext.Provider>
 );
}

// في أي مكون عميق، تغيير user يؤدي إلى إعادة رسم جميع المكونات التي تستخدم Context

الحل الأفضل لإدارة الحالة المعقدة هو استخدام مكتبة إدارة حالة متخصصة مثل Redux أو Zustand. لكن حتى هنا، هناك أخطاء شائعة. معظم المطورين يستخدمون Redux بطريقة خاطئة، حيث يضعون كل شيء في المتجر، حتى البيانات المحلية التي لا تحتاج إلى مشاركتها بين المكونات. هذا يؤدي إلى متجر ضخم يصعب صيانته، ويجعل التطبيق أبطأ بسبب الحاجة إلى إعادة رسم المكونات عند أي تغيير في المتجر.

في التطبيق الذي ذكرته، قمنا بإعادة هيكلة إدارة الحالة باستخدام Zustand، مع اتباع هذه القواعد:

• •البيانات التي لا تحتاج إلى مشاركتها بين المكونات تبقى في حالة محلية باستخدام useState
• •البيانات التي تحتاج إلى مشاركتها بين مكونات غير مرتبطة مباشرة تُدار باستخدام Zustand
• •البيانات التي تتغير بشكل متكرر وتُستخدم في مكونات عميقة تُدار باستخدام Zustand مع selectors لمنع إعادة الرسم غير الضرورية
• •البيانات التي تأتي من API تُدار باستخدام React Query أو SWR، وليس Zustand أو Redux

// ✅ حل متكامل لإدارة الحالة
import { create } from 'zustand';

// متجر Zustand لإدارة حالة المستخدم
const useUserStore = create((set) => ({
 user: null,
 setUser: (user) => set({ user }),
}));

// استخدام React Query لجلب البيانات
const { data: projects } = useQuery('projects', fetchProjects);

// حالة محلية للمكون
function ProjectList() {
 const [filter, setFilter] = useState('all');
 const user = useUserStore(state => state.user); // selector يمنع إعادة الرسم
 
 // ... بقية الكود
}

الدرس المستفاد هنا هو أن إدارة الحالة ليست مجرد مسألة تقنية - إنها مسألة تصميم. يجب أن تفكر في كيفية تدفق البيانات في تطبيقك قبل أن تبدأ في كتابة الكود. إذا وجدت نفسك تمرر props عبر 4 مستويات أو أكثر، فهذا مؤشر على أنك بحاجة إلى إعادة التفكير في بنية التطبيق. وإذا وجدت نفسك تستخدم Context لإدارة حالة متغيرة بشكل متكرر، فاعلم أنك تسير في الطريق الخطأ.

الخطأ الرابع: تجاهل تأثيرات الأداء في الـ Event Loop

أحد أكبر الأخطاء التي يرتكبها مطورو React هو تجاهل كيفية تأثير كودهم على الـ Event Loop في المتصفح. معظم المطورين يكتبون كوداً يبدو أنه يعمل، لكنهم لا يدركون أن بعض العمليات قد تسد الـ Event Loop، مما يجعل التطبيق يشعر بأنه بطيء وغير مستجيب. هذا الخطأ شائع بشكل خاص عند التعامل مع العمليات المتزامنة، مثل جلب البيانات، أو معالجة الصور، أو الحسابات المعقدة.

لنأخذ مثالاً واقعياً: في تطبيق معرض صور، كان لدينا مكون يعرض صوراً عالية الدقة ويطبق عليها فلتر باستخدام Canvas. المطور كتب الكود التالي:

// ❌ خطأ: معالجة الصور تسد الـ Event Loop
function ImageFilter({ imageUrl }) {
 const [filteredImage, setFilteredImage] = useState(null);
 
 useEffect(() => {
 const img = new Image();
 img.src = imageUrl;
 img. () => {
 const canvas = document.createElement('canvas');
 const ctx = canvas.getContext('2d');
 canvas.width = img.width;
 canvas.height = img.height;
 ctx.drawImage(img, 0, 0);
 
 // تطبيق فلتر معقد
 const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
 const data = imageData.data;
 
 for (let i = 0; i < data.length; i += 4) {
 // عملية حسابية معقدة على كل بكسل
 data[i] = data[i] * 0.393 + data[i + 1] * 0.769 + data[i + 2] * 0.189;
 data[i + 1] = data[i] * 0.349 + data[i + 1] * 0.686 + data[i + 2] * 0.168;
 data[i + 2] = data[i] * 0.272 + data[i + 1] * 0.534 + data[i + 2] * 0.131;
 }
 
 ctx.putImageData(imageData, 0, 0);
 setFilteredImage(canvas.toDataURL());
 };
 }, [imageUrl]);
 
 return filteredImage ? <img src={filteredImage} alt="Filtered" /> : <div>Loading...</div>;
}

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

الحل لهذه المشكلة هو استخدام Web Workers لفصل العمليات الثقيلة عن الـ Event Loop الرئيسي. Web Workers يسمحون لك بتشغيل كود جافاسكريبت في خيط منفصل، مما يمنع سد الـ Event Loop. إليك كيف يمكن إعادة كتابة المثال السابق باستخدام Web Worker:

// ✅ حل باستخدام Web Worker
// worker.js
self. function(e) {
 const { imageData, width, height } = e.data;
 const data = imageData.data;
 
 for (let i = 0; i < data.length; i += 4) {
 data[i] = data[i] * 0.393 + data[i + 1] * 0.769 + data[i + 2] * 0.189;
 data[i + 1] = data[i] * 0.349 + data[i + 1] * 0.686 + data[i + 2] * 0.168;
 data[i + 2] = data[i] * 0.272 + data[i + 1] * 0.534 + data[i + 2] * 0.131;
 }
 
 self.postMessage({ imageData });
};

// ImageFilter.js
function ImageFilter({ imageUrl }) {
 const [filteredImage, setFilteredImage] = useState(null);
 
 useEffect(() => {
 const worker = new Worker('worker.js');
 const img = new Image();
 img.src = imageUrl;
 img.onload = () => {
 const canvas = document.createElement('canvas');
 const ctx = canvas.getContext('2d');
 canvas.width = img.width;
 canvas.height = img.height;
 ctx.drawImage(img, 0, 0);
 
 const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
 worker.postMessage({ imageData, width: canvas.width, height: canvas.height });
 };
 
 worker.onmessage = (e) => {
 const { imageData } = e.data;
 const canvas = document.createElement('canvas');
 const ctx = canvas.getContext('2d');
 canvas.width = imageData.width;
 canvas.height = imageData.height;
 ctx.putImageData(imageData, 0, 0);
 setFilteredImage(canvas.toDataURL());
 };
 
 return () => worker.terminate();
 }, [imageUrl]);
 
 return filteredImage ? <img src={filteredImage} alt="Filtered" /> : <div>Loading...</div>;
}

الفرق بين الكودين ليس فقط في الأداء - بل في تجربة المستخدم. باستخدام Web Worker، يبقى التطبيق مستجيباً حتى أثناء معالجة الصور الثقيلة. هذا مثال على كيفية التفكير في الأداء ليس فقط من حيث سرعة التنفيذ، بل من حيث تأثير الكود على النظام بأكمله.

لكن Web Workers ليست الحل السحري لجميع مشاكل الأداء. هناك حالات أخرى يجب الانتباه إليها، مثل:

• •العمليات المتزامنة الطويلة في معالجات الأحداث (مثل onClick)، التي يمكن أن تسد الـ Event Loop
• •استخدام setTimeout أو setInterval بطريقة غير صحيحة، مما يؤدي إلى تراكم المهام في الـ Event Loop
• •العمليات التي تمنع الـ Garbage Collector من العمل بكفاءة، مما يؤدي إلى تسرب ذاكرة
• •استخدام مكتبات خارجية تؤدي عمليات ثقيلة بدون إشعار المطور

الدرس المستفاد هنا هو أن كتابة كود React سريع لا يتعلق فقط بكتابة كود نظيف - بل بفهم كيفية عمل المتصفح نفسه. يجب أن تفكر في كيفية تأثير كودك على الـ Event Loop، وكيفية إدارة الذاكرة، وكيفية الحفاظ على استجابة التطبيق حتى أثناء العمليات الثقيلة.

الخطأ الخامس: تجاهل أهمية البنية التحتية للبناء

آخر خطأ كبير أراه في مشاريع React هو تجاهل أهمية البنية التحتية للبناء (build infrastructure). معظم المطورين يركزون على كتابة الكود نفسه، لكنهم ينسون أن كيفية بناء وتجميع هذا الكود لها تأثير كبير على أداء التطبيق النهائي. من تجربتي، 30% من مشاكل الأداء في تطبيقات React تأتي من إعدادات البناء غير الصحيحة، وليس من الكود نفسه.

لنأخذ مثالاً واقعياً: في أحد المشاريع، كان لدينا تطبيق React بحجم 4.2 ميجابايت بعد البناء، رغم أنه يحتوي فقط على 15 مكوناً رئيسياً. بعد التحقيق، اكتشفنا أن المشكلة لم تكن في الكود نفسه، بل في إعدادات webpack التي كانت تقوم بتجميع جميع المكتبات الخارجية في حزمة واحدة، بما في ذلك تلك التي لم نستخدمها أبداً. المشكلة الأكبر كانت في أن webpack لم يكن يقوم بتقسيم الكود (code splitting) بشكل صحيح، مما يعني أن المستخدم كان يضطر إلى تحميل الكود بالكامل حتى للوصول إلى الصفحة الرئيسية.

الحل لهذه المشكلة كان بسيطاً نسبياً، لكنه يتطلب فهم عميق لكيفية عمل أدوات البناء:

• •تفعيل تقسيم الكود باستخدام dynamic imports: `import('./module')` بدلاً من `import module from './module'`
• •استخدام SplitChunksPlugin لتقسيم المكتبات الخارجية إلى حزم منفصلة
• •تفعيل Tree Shaking لإزالة الكود غير المستخدم من الحزم النهائية
• •استخدام تحليل الحزم (bundle analysis) لتحديد المكتبات الكبيرة غير الضرورية
• •تفعيل ضغط الكود باستخدام TerserPlugin وتقنيات حديثة مثل Brotli

// ✅ تقسيم الكود باستخدام dynamic import
// بدلاً من:
import { heavyFunction } from './heavyModule';

// استخدم:
const heavyFunction = React.lazy(() => import('./heavyModule'));

// مع Suspense للتعامل مع التحميل
function App() {
 return (
 <React.Suspense fallback={<div>Loading...</div>}>
 <HeavyComponent />
 </React.Suspense>
 );
}

لكن تقسيم الكود ليس هو الحل الوحيد. هناك جوانب أخرى للبنية التحتية يجب الانتباه إليها:

• •استخدام تقنيات التحميل الكسول (lazy loading) للمكونات التي لا تظهر فوراً
• •تفعيل التخزين المؤقت (caching) للبيانات الثابتة باستخدام service workers
• •استخدام تقنيات مثل prefetching لتحميل الموارد قبل أن يحتاجها المستخدم
• •ضغط الصور والأصول الأخرى باستخدام أدوات مثل imagemin
• •استخدام تنسيقات حديثة مثل WebP للصور بدلاً من JPEG أو PNG

في المشروع الذي ذكرته، قمنا بتطبيق هذه التحسينات، مما أدى إلى تقليل حجم الحزمة النهائية من 4.2 ميجابايت إلى 1.1 ميجابايت فقط، مع تحسين وقت التحميل الأولي بنسبة 65%. لكن الأهم من الأرقام هو تجربة المستخدم - التطبيق أصبح يشعر بأنه أسرع وأكثر استجابة، حتى على الشبكات البطيئة.

الدرس المستفاد هنا هو أن كتابة كود React جيد ليس كافياً - يجب أيضاً الاهتمام بكيفية بناء وتجميع هذا الكود. البنية التحتية للبناء ليست مجرد تفاصيل فنية، بل جزء أساسي من تجربة المستخدم النهائية. إذا تجاهلت هذا الجانب، فستجد نفسك تقضي ساعات في تحسين الكود نفسه، بينما المشكلة الحقيقية تكمن في كيفية بناء هذا الكود.

خلاصة المهندس: كيف تكتب React بالطريقة الصحيحة؟

بعد أكثر من عشر سنوات في كتابة React، وإصلاح عشرات المشاريع التي تعاني من مشاكل الأداء، يمكنني تلخيص ما تعلمته في ثلاث قواعد ذهبية:

• •React ليس مجرد مكتبة لعرض البيانات - إنه محرك حالة يجب أن تُبرمج بعناية هندسية. تعامل مع كل useState وuseEffect كما تتعامل مع قاعدة بيانات: بحذر، ودقة، وفهم عميق لكيفية عمله خلف الكواليس.
• •الأداء ليس مجرد تحسين إضافي - إنه جزء أساسي من تجربة المستخدم. إذا كان تطبيقك بطيئاً، فلن ينقذه تصميم جميل أو ميزات رائعة. ابدأ بالتفكير في الأداء منذ اليوم الأول، وليس بعد أن يصبح التطبيق بطيئاً.
• •البنية التحتية للبناء ليست مجرد تفاصيل فنية - إنها جزء من الكود نفسه. كيف تبني وتجمع تطبيقك له تأثير كبير على أدائه النهائي مثل الكود الذي تكتبه. لا تترك هذا الجانب للمطورين الآخرين - تعلمه، وافهمه، وطبقه بنفسك.

إذا كنت تريد البدء في كتابة React بالطريقة الصحيحة اليوم، فإليك الخطوات العملية التي يجب اتباعها:

1. راجع جميع useEffect في تطبيقك وتأكد من أن كل واحد لديه قائمة اعتماديات صحيحة. إذا وجدت effect بدون قائمة اعتماديات، فهذا مؤشر على مشكلة.
2. استخدم React DevTools لتحليل إعادة الرسم في تطبيقك. ابحث عن المكونات التي تعاد رسمها بشكل متكرر دون داعٍ، واستخدم React.memo أو useMemo لمنع ذلك.
3. افحص بنية إدارة الحالة في تطبيقك. إذا وجدت نفسك تمرر props عبر أكثر من مستويين، أو تستخدم Context لإدارة حالة متغيرة بشكل متكرر، فاعلم أنك بحاجة إلى إعادة التفكير في البنية.
4. استخدم أدوات تحليل الحزم مثل webpack-bundle-analyzer لتحديد المكتبات الكبيرة غير الضرورية، وقم بتقسيم الكود باستخدام dynamic imports.
5. اختبر تطبيقك على أجهزة حقيقية ذات أداء منخفض، وليس فقط على جهاز التطوير القوي الخاص بك. إذا كان التطبيق بطيئاً على جهاز متوسط، فأنت بحاجة إلى تحسينه.

في النهاية، كتابة React بالطريقة الصحيحة ليست مسألة تعلم المزيد من المكتبات أو الأدوات - بل مسألة تغيير العقلية. بدلاً من التفكير في React كمكتبة لعرض البيانات، فكر فيه كمحرك حالة يجب أن يُبرمج بعناية. بدلاً من التركيز فقط على كتابة كود يعمل، ركز على كتابة كود فعال، وسريع، وقابل للصيانة. وعندما تفعل ذلك، ستجد أن تطبيقاتك لا تعمل بشكل أفضل فحسب - بل تصبح أيضاً أسهل في التطوير والصيانة على المدى الطويل.