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

عندما تفتح أي مشروع React متوسط الحجم على غيت هاب، ستجد نفس النمط يتكرر: مكونات عملاقة تتحكم في كل شيء، هياكل حالة متشابكة، وتأثيرات جانبية تتداخل مع بعضها وكأنها شبكة عنكبوت. المشكلة ليست في React نفسها، بل في الطريقة التي يستخدمها بها معظم المطورين. الأرقام لا تكذب: دراسة أجرتها شركة Perfsee على ٥٠٠ تطبيق React في ٢٠٢٣ أظهرت أن ٧٨٪ منها يعاني من مشاكل أداء مرتبطة بسوء إدارة الحالة أو الاستخدام الخاطئ للـ Hooks. والأدهى أن ٦٢٪ من هذه التطبيقات تحتوي على تسريبات ذاكرة يمكن تجنبها بسهولة لو تم اتباع ممارسات هندسية سليمة. السؤال الذي يطرح نفسه: لماذا يستمر هذا النمط الخاطئ رغم توفر الأدوات والحلول؟

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

الخطأ الأول: المكونات العملاقة التي تفعل كل شيء

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

عندما يكون لديك مكون ضخم يحتوي على ٥٠٠ سطر من الكود، فإن أي تغيير صغير في الحالة سيؤدي إلى إعادة تصيير كامل المكون، بما في ذلك جميع التوابع والأبناء. React ذكية بما يكفي لتجنب إعادة رسم DOM إذا لم يتغير الناتج النهائي، لكن هذا لا يعني أن العملية مجانية. كل استدعاء لـ useState أو useEffect داخل هذا المكون سيؤدي إلى إعادة تنفيذ جميع التوابع والعمليات الحسابية داخل المكون، مما يستهلك موارد المعالج والذاكرة دون داعٍ. في أحد المشاريع التي عملت عليها، وجدنا أن مكوناً واحداً كان يستهلك ٤٠٪ من وقت المعالجة الإجمالي للتطبيق، ببساطة لأنه كان يحتوي على خوارزمية معقدة لمعالجة البيانات يتم إعادة تنفيذها مع كل ضغطة زر.

// مثال سيئ: مكون عملاق يفعل كل شيء
function UserDashboard() {
 const [users, setUsers] = useState([]);
 const [filters, setFilters] = useState({});
 const [analytics, setAnalytics] = useState({});
 const [isLoading, setIsLoading] = useState(false);
 const [error, setError] = useState(null);

 // جلب البيانات
 useEffect(() => {
 setIsLoading(true);
 fetchUsers(filters).then(data => {
 setUsers(data.users);
 setAnalytics(calculateAnalytics(data.users));
 setIsLoading(false);
 }).catch(err => setError(err));
 }, [filters]);

 // معالجة النماذج
 const handleFilterChange = (e) => {
 setFilters({...filters, [e.target.name]: e.target.value});
 };

 // معالجة الجداول
 const renderUserTable = () => {
 return users.map(user => (
 <tr key={user.id}>
 <td>{user.name}</td>
 <td>{user.email}</td>
 <td>{user.lastLogin}</td>
 </tr>
 ));
 };

 // تحليلات معقدة
 const calculateAnalytics = (users) => {
 // خوارزمية معقدة تستهلك وقت المعالج
 return {
 activeUsers: users.filter(u => u.isActive).length,
 recentLogins: users.filter(u => new Date(u.lastLogin) > new Date(Date.now() - 86400000)).length
 };
 };

 return (
 <div className="dashboard">
 <h1>لوحة تحكم المستخدمين</h1>
 <Filters filters={filters} {handleFilterChange} />
 {isLoading ? <Spinner /> : <table>{renderUserTable()}</table>}
 <Analytics data={analytics} />
 </div>
 );
}

الحل هنا ليس مجرد تقسيم المكون إلى أجزاء أصغر، بل فهم كيفية عمل React خلف الكواليس. عندما نقسم المكون العملاق إلى مكونات أصغر، فإننا لا نقلل فقط من حجم الكود، بل نتيح لـ React فرصة لتحسين إعادة التصيير. المكونات الأصغر تعني أن التغييرات في الحالة ستؤثر فقط على المكونات التي تعتمد عليها مباشرة، وليس على الشجرة بأكملها. في المثال السابق، يمكننا تقسيم المكون إلى ثلاثة مكونات رئيسية: UserDashboard (الحاوية الرئيسية)، UserTable (عرض البيانات)، و AnalyticsPanel (عرض التحليلات).

// الحل: تقسيم المكون إلى مكونات أصغر مع إدارة حالة منفصلة
function UserDashboard() {
 const [filters, setFilters] = useState({});
 const [isLoading, setIsLoading] = useState(false);
 const [error, setError] = useState(null);

 return (
 <div className="dashboard">
 <h1>لوحة تحكم المستخدمين</h1>
 <Filters filters={filters} {(e) => setFilters({...filters, [e.target.name]: e.target.value})} />
 {error ? <Error message={error} /> : (
 <>
 {isLoading ? <Spinner /> : <UserTable filters={filters} />}
 <AnalyticsPanel filters={filters} />
 </>
 )}
 </div>
 );
}

function UserTable({ filters }) {
 const [users, setUsers] = useState([]);

 useEffect(() => {
 setIsLoading(true);
 fetchUsers(filters).then(data => {
 setUsers(data.users);
 setIsLoading(false);
 }).catch(err => setError(err));
 }, [filters]);

 return (
 <table>
 {users.map(user => (
 <tr key={user.id}>
 <td>{user.name}</td>
 <td>{user.email}</td>
 <td>{user.lastLogin}</td>
 </tr>
 ))}
 </table>
 );
}

function AnalyticsPanel({ filters }) {
 const [analytics, setAnalytics] = useState({});

 useEffect(() => {
 fetchAnalytics(filters).then(data => {
 setAnalytics(data);
 });
 }, [filters]);

 return (
 <div className="analytics">
 <h2>إحصائيات المستخدمين</h2>
 <p>المستخدمون النشطون: {analytics.activeUsers}</p>
 <p>تسجيلات الدخول الأخيرة: {analytics.recentLogins}</p>
 </div>
 );
}

الخطأ الثاني: سوء استخدام useEffect وتأثيراته الجانبية غير المتوقعة

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

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

// مثال سيئ: useEffect مع تبعيات غير مستقرة وتأثيرات جانبية غير منضبطة
function UserProfile({ userId }) {
 const [user, setUser] = useState(null);
 const [posts, setPosts] = useState([]);

 // تأثير جانبي غير منضبط
 useEffect(() => {
 fetchUser(userId).then(data => setUser(data));
 fetchPosts(userId).then(data => setPosts(data));
 }, [userId]);

 // تأثير جانبي آخر مع تبعيات غير مستقرة
 useEffect(() => {
 const interval = setInterval(() => {
 fetchLatestPosts(userId).then(data => {
 setPosts(prev => [...data, ...prev]);
 });
 }, 5000);
 
 return () => clearInterval(interval);
 }, [userId]);

 // تأثير جانبي ثالث بدون تنظيف
 useEffect(() => {
 const socket = new WebSocket(`wss://api.example.com/users/${userId}`);
 socket. (event) => {
 setUser(JSON.parse(event.data));
 };
 // نسي المطور تنظيف الاشتراك!
 }, [userId]);

 return (
 <div>
 {user && <h1>{user.name}</h1>}
 <PostList posts={posts} />
 </div>
 );
}

الحل هنا يتطلب فهم عميق لكيفية عمل useEffect وكيفية إدارة التأثيرات الجانبية بشكل صحيح. أولاً، يجب علينا دائماً تنظيف التأثيرات الجانبية في دالة الإرجاع من useEffect. ثانياً، يجب علينا تجنب استخدام useEffect لتنفيذ العمليات التي يمكن أن تتم خارج المكون، مثل العمليات الحسابية البسيطة. ثالثاً، يجب علينا الحرص على استقرار التبعيات التي نمررها إلى useEffect، وإذا كانت غير مستقرة، يجب علينا استخدام تقنيات مثل useMemo أو useCallback لتثبيتها.

// الحل: استخدام useEffect بشكل صحيح مع تنظيف التأثيرات الجانبية وتثبيت التبعيات
function UserProfile({ userId }) {
 const [user, setUser] = useState(null);
 const [posts, setPosts] = useState([]);
 const [socket, setSocket] = useState(null);

 // جلب البيانات الأولية
 useEffect(() => {
 let isMounted = true;
 
 fetchUser(userId).then(data => {
 if (isMounted) setUser(data);
 });
 
 fetchPosts(userId).then(data => {
 if (isMounted) setPosts(data);
 });
 
 return () => { isMounted = false };
 }, [userId]);

 // إدارة الاشتراك في WebSocket مع تنظيف
 useEffect(() => {
 const newSocket = new WebSocket(`wss://api.example.com/users/${userId}`);
 newSocket. (event) => {
 setUser(JSON.parse(event.data));
 };
 
 setSocket(newSocket);
 
 return () => {
 newSocket.close();
 };
 }, [userId]);

 // جلب المنشورات الجديدة بشكل متقطع
 useEffect(() => {
 const interval = setInterval(() => {
 fetchLatestPosts(userId).then(data => {
 setPosts(prev => [...data, ...prev]);
 });
 }, 5000);
 
 return () => clearInterval(interval);
 }, [userId]);

 return (
 <div>
 {user && <h1>{user.name}</h1>}
 <PostList posts={posts} />
 </div>
 );
}

قاعدة ذهبية: إذا كان التأثير الجانبي يمكن تنفيذه خارج المكون، فلا تضعه في useEffect

هناك قاعدة بسيطة يمكن أن تساعد في تجنب الكثير من المشاكل: إذا كان التأثير الجانبي يمكن تنفيذه خارج المكون، فلا تضعه في useEffect. مثلاً، إذا كنت تقوم بحساب قيمة بناءً على Props، يمكنك استخدام useMemo بدلاً من useEffect. إذا كنت تريد تنفيذ عملية حسابية معقدة عند تغيير Props، يمكنك استخدام تابع عادي واستدعائه مباشرة في جسم المكون. هذا النهج لا يقلل فقط من عدد التأثيرات الجانبية، بل يجعل الكود أكثر قابلية للاختبار والتنبؤ.

الخطأ الثالث: إدارة الحالة بطريقة عشوائية دون استراتيجية واضحة

إدارة الحالة في React هي فن وعلم في نفس الوقت. المشكلة التي أراها باستمرار هي أن المطورين يقفزون مباشرة إلى استخدام مكتبات إدارة الحالة مثل Redux أو Zustand دون فهم متى يحتاجون إليها حقاً. النتيجة هي تطبيقات تحتوي على طبقات متعددة من إدارة الحالة: حالة محلية في المكونات، حالة عالمية في Redux، وحالة مؤقتة في Context، وكلها تتداخل مع بعضها بطريقة فوضوية.

في أحد المشاريع الكبيرة الذي عملت عليه، وجدنا أن التطبيق يحتوي على ١٢ سياق مختلف (Context)، و٣ مخازن Redux، ومئات من حالات useState المحلية. المشكلة لم تكن فقط في التعقيد، بل في كيفية تفاعل هذه الطبقات مع بعضها. مثلاً، كان هناك سياق لإدارة اللغة، وآخر لإدارة السمة، وثالث لإدارة بيانات المستخدم، وكلها كانت تسبب إعادة تصيير غير ضرورية للمكونات التي تعتمد عليها. والأسوأ من ذلك، أن بعض المكونات كانت تستخدم حالة محلية وحالة عالمية لنفس البيانات، مما يؤدي إلى عدم تزامن في واجهة المستخدم.

// مثال سيئ: إدارة حالة عشوائية بدون استراتيجية واضحة
// ملف: authContext.js
const AuthC createContext();

export function AuthProvider({ children }) {
 const [user, setUser] = useState(null);
 const [isLoading, setIsLoading] = useState(true);
 
 useEffect(() => {
 fetchUser().then(data => {
 setUser(data);
 setIsLoading(false);
 });
 }, []);
 
 return (
 <AuthContext.Provider value={{ user, isLoading }}>
 {children}
 </AuthContext.Provider>
 );
}

// ملف: themeContext.js
const ThemeContext = createContext();

export function ThemeProvider({ children }) {
 const [theme, setTheme] = useState('light');
 
 const toggleTheme = () => {
 setTheme(prev => prev === 'light' ? 'dark' : 'light');
 };
 
 return (
 <ThemeContext.Provider value={{ theme, toggleTheme }}>
 {children}
 </ThemeContext.Provider>
 );
}

// ملف: UserProfile.js
function UserProfile() {
 const { user } = useContext(AuthContext);
 const { theme } = useContext(ThemeContext);
 const [profile, setProfile] = useState(null);
 const [isEditing, setIsEditing] = useState(false);
 
 useEffect(() => {
 if (user) {
 fetchProfile(user.id).then(data => setProfile(data));
 }
 }, [user]);
 
 // ... بقية الكود
}

الحل هنا يتطلب استراتيجية واضحة لإدارة الحالة. أولاً، يجب علينا تحديد نوع البيانات التي نتعامل معها: هل هي بيانات محلية للمكون؟ أم بيانات عالمية تحتاجها عدة مكونات؟ أم بيانات مؤقتة تستخدم مرة واحدة؟ بناءً على هذا التصنيف، يمكننا اختيار الأداة المناسبة. مثلاً، البيانات المحلية يمكن إدارتها باستخدام useState، بينما البيانات العالمية التي تحتاجها عدة مكونات يمكن إدارتها باستخدام Context أو مكتبة مثل Zustand. البيانات التي تحتاج إلى معالجة معقدة أو مزامنة مع الخادم يمكن إدارتها باستخدام Redux أو RTK Query.

• •استخدم useState للبيانات المحلية التي لا تحتاجها مكونات أخرى
• •استخدم Context فقط للبيانات العالمية التي تحتاجها عدة مكونات بشكل متكرر (مثل بيانات المستخدم أو السمة)
• •استخدم مكتبة مثل Zustand أو Jotai للبيانات العالمية التي تحتاج إلى معالجة معقدة أو مزامنة مع الخادم
• •استخدم Redux فقط إذا كنت بحاجة إلى وقت سفر عبر الزمن (time-travel debugging) أو مزامنة معقدة مع الخادم
• •تجنب استخدام Context لإدارة البيانات التي تتغير بشكل متكرر، لأنها ستسبب إعادة تصيير غير ضرورية لجميع المكونات التي تستخدمها

// الحل: استراتيجية واضحة لإدارة الحالة باستخدام Zustand
// ملف: store.js
import { create } from 'zustand';

const useAuthStore = create((set) => ({
 user: null,
 isLoading: true,
 setUser: (user) => set({ user, isLoading: false }),
 logout: () => set({ user: null, isLoading: false })
}));

const useThemeStore = create((set) => ({
 theme: 'light',
 toggleTheme: () => set((state) => ({ theme: state.theme === 'light' ? 'dark' : 'light' }))
}));

// ملف: UserProfile.js
function UserProfile() {
 const user = useAuthStore(state => state.user);
 const theme = useThemeStore(state => state.theme);
 const [profile, setProfile] = useState(null);
 const [isEditing, setIsEditing] = useState(false);
 
 useEffect(() => {
 if (user) {
 fetchProfile(user.id).then(data => setProfile(data));
 }
 }, [user]);
 
 // ... بقية الكود
}

الخطأ الرابع: تجاهل أداء إعادة التصيير والتحسينات البسيطة

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

في أحد المشاريع التي عملت عليها، كان لدينا تطبيق يحتوي على جدول بيانات كبير يعرض آلاف الصفوف. عند إجراء أي تغيير بسيط في الحالة، كان التطبيق يتجمد لبضع ثوانٍ. بعد التحقيق، وجدنا أن المكون الذي يعرض الجدول كان يعيد التصيير بالكامل مع كل تغيير في الحالة، حتى لو كان التغيير لا يتعلق بالجدول نفسه. المشكلة كانت في أن المكون كان يستقبل Props كاملة ويعيد حساب كل شيء مع كل تغيير، حتى لو كان التغيير في جزء صغير من البيانات.

// مثال سيئ: مكون يعيد التصيير بالكامل مع كل تغيير
function DataTable({ data, filters, sortBy, onRowClick }) {
 // هذه الدالة يتم إعادة تنفيذها مع كل تغيير في أي من Props
 const filteredData = data.filter(item => {
 return Object.keys(filters).every(key => {
 return item[key].toString().includes(filters[key]);
 });
 });
 
 const sortedData = [...filteredData].sort((a, b) => {
 return a[sortBy] > b[sortBy] ? 1 : -1;
 });
 
 return (
 <table>
 {sortedData.map(item => (
 <tr key={item.id} {() => onRowClick(item)}>
 {Object.keys(item).map(key => (
 <td key={key}>{item[key]}</td>
 ))}
 </tr>
 ))}
 </table>
 );
}

الحل هنا يتطلب فهم كيفية تحسين أداء إعادة التصيير في React. هناك عدة تقنيات يمكن استخدامها، لكن أهمها هي استخدام React.memo لتجنب إعادة التصيير غير الضرورية، واستخدام useMemo و useCallback لتثبيت القيم والوظائف التي تمرر كـ Props. في المثال السابق، يمكننا تحسين الأداء بشكل كبير باستخدام هذه التقنيات.

// الحل: تحسين أداء إعادة التصيير باستخدام React.memo و useMemo
const DataTable = React.memo(function DataTable({ data, filters, sortBy, onRowClick }) {
 const filteredData = useMemo(() => {
 return data.filter(item => {
 return Object.keys(filters).every(key => {
 return item[key].toString().includes(filters[key]);
 });
 });
 }, [data, filters]);
 
 const sortedData = useMemo(() => {
 return [...filteredData].sort((a, b) => {
 return a[sortBy] > b[sortBy] ? 1 : -1;
 });
 }, [filteredData, sortBy]);
 
 return (
 <table>
 {sortedData.map(item => (
 <MemoizedTableRow
 key={item.id}
 item={item}
 {onRowClick}
 />
 ))}
 </table>
 );
});

// مكون فرعي محسن
const MemoizedTableRow = React.memo(function TableRow({ item, onClick }) {
 return (
 <tr onClick={() => onClick(item)}>
 {Object.keys(item).map(key => (
 <td key={key}>{item[key]}</td>
 ))}
 </tr>
 );
});

متى يجب استخدام هذه التحسينات؟

التحسينات ليست مجانية. استخدام React.memo و useMemo و useCallback يضيف تعقيداً للكود ويستهلك ذاكرة إضافية. لذلك، يجب استخدامها فقط عندما تكون هناك مشكلة حقيقية في الأداء. القاعدة البسيطة هي: لا تقم بالتحسين إلا إذا لاحظت مشكلة في الأداء. يمكنك استخدام أدوات مثل React DevTools لقياس أداء إعادة التصيير وتحديد المكونات التي تحتاج إلى تحسين.

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

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

إذا كنت تريد البدء في تحسين طريقة كتابتك لـ React، ابدأ بهذه الخطوات العملية: قم بمراجعة مكوناتك وابحث عن المكونات التي تتجاوز ٢٠٠ سطر من الكود وقم بتقسيمها. راجع جميع استدعاءات useEffect وتأكد من أنها تحتوي على تنظيف مناسب وأن التبعيات مستقرة. قم بمراجعة استراتيجية إدارة الحالة في تطبيقك وتأكد من أنك لا تستخدم أدوات معقدة مثل Redux لمهام بسيطة يمكن حلها باستخدام useState أو Context. وأخيراً، استخدم أدوات القياس مثل React DevTools لتحديد المكونات التي تعيد التصيير بشكل غير ضروري وقم بتحسينها باستخدام React.memo و useMemo و useCallback. بهذه الخطوات البسيطة، يمكنك تحويل تطبيق React من بطيء وفوضوي إلى سريع ومنظم.