أنا الفترة اللي فاتت لاحظت إن في projects بشتغل عليها بـ React، الأداء فيها بيبدأ يبقى تقيل مع الوقت…
Pages بتترندر من غير داعي، حاجات بتتحرك على الفاضي، والـ DevTools بيشتكي كل شوية.

فقررت أعمل وقفة وأظبط شوية حاجات صغيرة… لكن فعليًا فرقت جدًا!

⸻

الحاجات اللي كانت مأثرة عندي:
- Functions بتتولد في كل render
- Props بتتغير شكليًا بس، فـ component بيرندر من غير سبب
- مفيش memoization
- List طويلة جدًا بتترندر كلها مرة واحدة
- مفيش Lazy loading، كل حاجة بتتحمّل في البداية

⸻

اللي عملته علشان أظبط الأداء:
- استخدمت React.memo علشان أمنع re-renders اللي ملهاش لازمة
- useCallback مع الدوال اللي بتتبعت كـ props
- useMemo لحساب أي data تقيلة مرة واحدة
- جربت react-window مع الـ lists الكبيرة
- استخدمت Debounce / Throttle في search inputs والـ scroll events

⸻

كمان فعلت “Highlight updates when components render” في DevTools
وشوفت بعيني إن فيه components بتترندر كل مرة من غير سبب، وده كان مأثر على حاجات تانية في الصفحة.

⸻

خلاصة الموضوع:
مش لازم تعمل refactor ضخم علشان تحسّن الأداء، أوقات شوية تفاصيل بتفرق جدًا.
ولو بتشتغل بـ React، حاول دايمًا تراجع إيه بيرندر، وليه، وإزاي تمنعه لو مالوش لازمة.

لو عندك tricks تانية بتستخدمها لتحسين الأداء، شاركني بيها، خلينا كلنا نستفيد.

بص يا صاحبي
أكتر حاجة بتقرفني وأنا شغال على مشروع React إنك تلاقي الصفحة بتفضل سودة، أو فيها spinner ضخم بيلف في النص كأنك بتستدعي جني 😅
والمستخدم يفضل مستني ومش فاهم هو فين ولا إيه اللي بيحصل

⸻

في الأول كنت بعمل زي الكل:
“هحط loading = true أول ما أفتح الصفحة، وأول ما الـ API ترد أخليها false… وبينهم أحط spinner”
بس اللي اكتشفته بعد كده إن ده بيبوّظ تجربة المستخدم أكتر ما بيساعده.

⸻

دلوقتي بقيت شايف إن الـ loading state جزء أساسي من الـ UI/UX…
مش كود بيتكتب وخلاص، لأ، دي لحظة حرجة في تجربة أي حد بيستخدم الموقع، ولو عملتها صح، المستخدم هيفضل مرتاح وسايق معاك، حتى لو في داتا بتتأخر.

⸻

ودي شوية حاجات بقيت بعملها في مشاريعي وفعلاً فرقت:

⸻

✅ مبقتش أستخدم spinner بيغطي الشاشة كلها
ليه؟ لأنه بيقطع التواصل بين المستخدم والموقع، كأنك بتقوله “اقعد ساكت ومستني لحد ما أنا أرجعلك”!
بدل كده، بخلي كل عنصر يتحمّل في مكانه:
-الزرار بيبقى فيه loader بسيط
- الجدول بيبقى فيه صفوف شبه حقيقية بس فاضية
- الكروت بتتحول لسكلتونات تمثّل مكان الصورة والنص

⸻

✅ Skeleton UI over spinners
السكلتون بيدي إحساس إن الحاجة موجودة وهي بس “بتشطب”،
وده بيخلّي الـ layout ثابت ومفيش حاجة بتقفز من مكانها، وبيقلل الـ layout shifts اللي بتضايق المستخدم.

⸻

✅ كل حاجة تتحمّل لوحدها
يعني لو عندي صفحة فيها جدول وتحته فورم، مش لازم أستنى الجدول يخلص علشان أعرض الفورم.
كل جزء بيحمّل بياناته لوحده، وبيظهر أول ما يجهز.

⸻

✅ استخدمت React Suspense
خصوصًا مع lazy-loaded components، بقيت أعمل fallback UI يظهر مكان الحاجة لحد ما تتحمّل.
مثال: صفحة فيها component تقيل شوية، أحط مكانه loader صغير أو skeleton مؤقتًا.

⸻

✅ ما بخلّيش الـ loading يقطع المحتوى
يعني حتى لو الداتا لسه جاية، بسيب الصفحة تتعرض وفيها أماكن placeholder أو states زي “No data yet” أو “Loading user info…”
المستخدم يبقى فاهم هو فين، مش تايه.

⸻

✅ جربت empty states ذكية
لو مفيش بيانات، مبظهرش صفحة فاضية أو error، لأ، أكتب له “لسه ما ضفتش بيانات” أو “ابدأ بإضافة عنصر جديد”،
ودي بتخلي شكل المشروع احترافي حتى لو مفيش داتا.

⸻

🎯 الخلاصة:
الناس متقبلين فكرة إن الحاجة تاخد وقت في التحميل، بس مش متقبلين يحسوا إن الموقع عطلان أو مش بيستجيب.
ولو عملت loading state كويسة، هتخلي الموقع شكله أسرع حتى لو الـ API بطيء فعلًا.

من أكتر الحاجات اللي اكتشفت إنها “مش بسيطة زي ما كنت متخيل” هي التعامل مع الـ forms في React و Next.js.

في أول مشروع ليّا، كنت بكتب كل حاجة manual:
useState لكل input، onChange بتعدّل في state، onSubmit بتبعت الداتا… وخلصنا.

بس لما المشروع كبر، والـ form بقى فيه validation، وerrors، وشوية شروط حسب حالة المستخدم، ساعتها بدأت أحس إني “بضرب في حيطة” مع كل تعديل صغير!

⸻

بدأت أراجع نفسي شوية وأسأل:
- إزاي أتعامل مع form كبير ومعقّد بدون ما الكود يتحول لكارثة؟
- إزاي أعمل validation محترم يدي feedback واضح للمستخدم؟
- إزاي أرجع errors من الـ backend وأعرضها من غير ما أخرّب تجربة المستخدم؟

⸻

وبدأت أشتغل على الحلول دي:

✅ استخدمت React Hook Form
أبسط وأخف من الطريقة التقليدية، وبتشتغل بشكل efficient جدًا — خصوصًا مع عدد كبير من الحقول.
الميزة كمان إنها مش بتعمل re-render غير لما الحاجة فعلاً تتغير، وده فرق معايا جدًا في الأداء.

✅ ربطتها بـ Zod
بديل ممتاز لـ Yup، والمميز فيه إنه static type safe، فـ بيشتغل ممتاز مع TypeScript.
بقيت أكتب validation schema مرنة وسريعة، والـ errors بتطلع مظبوطة من غير ما ألف حوالين الكود.

✅ عملت structure ثابت
كل form ليه custom hook خاص بيه بيحتوي على:
- default values
- validation schema
- onSubmit logic
- any side effects

ده خلاني أقدر أعيد استخدام نفس الفورم logic في أكتر من صفحة/وضع بسهولة.

✅ عملت تجربة مستخدم واضحة
- Error messages توضح بالضبط المشكلة
- Indicators أثناء الـ submit
- Reset واضح بعد النجاح
- ومعاملة الـ API errors بشكل friendly بدل ما تظهر للمستخدم رسالة سطرين JSON!

⸻

أهم دروس اتعلمتها:
1 - الـ forms دايمًا بتبان بسيطة في الأول، بس كل edge case بيكشفلك نقطة ضعف
2 - ما تستهونش بأي جزء خاص بـ UX جوه الفورم — لأن المستخدم بيفقد الثقة بسرعة
3 - لو اشتغلت كويس على الفورم من البداية، هتريح دماغك في الـ refactor بعدين
4 - تنظيم الكود حوالين الفورمز بيحسّن قابلية التعديل، وبيسهّل الشغل في التيم كمان

⸻

أنا شايف إن التعامل مع الفورمز بشكل صح مش رفاهية… دي skill لازم تبقى أساسية لأي frontend developer.

لو حد عنده setup معين أو أدوات تانية بيستخدمها ومرتاح معاها، شاركوني. بحب جدًا أسمع منكم وأطوّر من اللي بعمله.

لقيت كنز جامد جدًا لكل المبرمجين! 💻🔥
موقع overapi.com عبارة عن مرجع سريع بيجمع كل أوامر ودوال لغات البرمجة في مكان واحد.

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

🧰 أهم أدوات التطوير التي لا غنى عنها لأي مبرمج في رحلته البرمجية.

كنت دايمًا مستغرب
إزاي الكود ده بيشتغل من غير Error؟

console.log(name); // undefined
var name = "Adel";

المفروض الكود يضرب، بس لا بيطبع undefined
فضلت أدور وأقرأ لحد ما فهمت واحدة من أغرب وأهم الحاجات في JavaScript​:
Hoisting

⸻

اللي بيحصل ببساطة إن JavaScript قبل ما تنفذ الكود، بتعدي عليه مرة وتعمل حاجة اسمها hoisting، يعني بترفع تعريفات المتغيرات والدوال لأعلى الـ scope.

بس خد بالك، مش كل حاجة بتترفع بنفس الشكل.

⸻

اللي عرفته:
- var بيتعمله hoisting ويتساوى بـ undefined
- let و const بيتعملهم hoisting برضو، بس ما ينفعش تستخدمهم قبل تعريفهم (بيطلع Error)
- function declarations بتترفع كاملة وتشتغل عادي
- لكن function expressions أو arrow functions لأ، بتعتبر undefined لو استخدمتها قبل التعريف

⸻

مثال بسيط:

sayHi(); // Works fine

function sayHi() {
  console.log("Hi!");
}

لكن:

sayHi(); // Error

const sayHi = () => {
  console.log("Hi!");
};

⸻

من ساعتها بقيت أرتب الكود بعناية، وأبعد تمامًا عن استخدام var
استخدام let و const خلاني أتجنب مشاكل كتير، خصوصًا في المشاريع الكبيرة

لو لسه بتتعلم JavaScript، أنصحك تقرأ عن الـ hoisting بتركيز، لأنه بيوضحلك حاجات كتير بتحصل في الخلفية وانت مش واخد بالك

بص يا صاحبي انت بتشتغل React أو Next.js؟ طب حلو جدًا.

بس قولي بقى، إنت فاهم الفرق بين Client-Side Rendering و Server-Side Rendering و Static Site Generation؟
ولا شغال بأي حاجة تيجي وخلاص؟ 😅

أنا كنت كده بالظبط… لحد ما المشروع بدأ يتقل، والـ SEO راح في الوبا، والمستخدمين بيستنوا الصفحة تحمل كأننا في 2010!

⸻

تعالى أقولك الفرق كأننا بنشرب شاي بالنعناع:

🟢 Client-Side Rendering (CSR)
- الصفحة بتظهر فاضية الأول، وبعدين React يملأها بعدين.
- حلو في الـ Dashboards والحاجات اللي مش محتاجة SEO.
- سريع بعد أول تحميل، بس أول مرة المستخدم بيشوف الـ loader أكتر من المحتوى.

🟠 Server-Side Rendering (SSR)
- السيرفر بيبعتلك الصفحة جهّزها بالبيانات، فبتظهر أسرع من CSR.
- حلو للـ SEO، ومناسب لو بتبيع منتج وعايز جوجل يشوف المحتوى.
- كل مرة المستخدم يدخل، السيرفر بيشتغل.

🟡 Static Site Generation (SSG)
- الصفحة بتتولد مرة وقت الـ build وتتخزن HTML.
- سريع جدًا جدًا، مثالي لـ blogs و landing pages.
- بس لو المحتوى بيتغير كتير، هتحتاج rebuild أو ISR.

⸻

يعني باختصار:
- لو عندك Dashboard → روح لـ CSR
- لو موقع بيع وSEO مهم → استخدم SSR
- لو محتوى ثابت زي landing page → SSG

ولو Next.js، إنت ملك زمانك… تقدر تخلط اللي يعجبك.

⸻

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

لو انت مبرمج وبتتعامل مع Git وبتنسى الأوامر بسرعة الصورة دي هتكون دليل مختصر وسريع يساعدك تراجع أهم الأوامر اللي بنستخدمها باستمرار، من أول init لحد reset بشكل بسيط وواضح.

‏أوامر الشبكات في لينكس يجب أن تعرفها

لو نفسك تتقن Git بسهولة وبسرعة، الأوامر دي هتفيدك جداً، احفظها لوقت الحاجة

لو انت مبرمج وعايز تحسّن مستواك في حل المشكلات، جرّب المواقع دي:

‏🔹 codewars.com – تمارين متنوعة
‏🔹 leetcode.com – تحضير إنترفيو
‏🔹 hackerrank.com – مناسب للمبتدئين
‏🔹 topcoder.com – تحديات محترفين
‏🔹 coderbyte.com – مستويات مختلفة
‏🔹 codeforces.com – مسابقات حيّة

ابدأ بـ HackerRank و Codewars، وبعدها خش عالم LeetCode وCodeforces

لو بتشتغل بـ React وبتدور على طرق تختصر بيها وقتك وتزود إنتاجيتك، أنصحك تشوف
‏⁦ usehooks.com ⁩

‏الموقع ده عبارة عن مكتبة جاهزة ومجانية لأشهر وأهم الـ custom hooks اللي بنحتاجها كمطوري Front-End.
‏بدل ما تعيد اختراع العجلة وتكتب نفس الكود من الصفر، هتلاقي حلول جاهزة، مدروسة، ومتجربة في مشاريع حقيقية.

‏النتيجة؟
‏✔️ وقت أقل في كتابة الكود
‏✔️ مجهود أقل في التفكير في الحلول التكرارية
‏✔️ تركيز أكتر على منطق المشروع وتفاصيله الأساسية

‏لو بتشتغل على مشروع React حاليًا، دي أداة هتفيدك جدًا. جربها وهتحس بالفرق

‏لو عايز تظبط كودك وتخليه أنضف وأحسن من غير ما تستنى حد يراجعه، في أدوات هتعمل الشغل ده بدل منك وبسرعة ⚡

‏الأدوات دي بتفحص الكود أوتوماتيك، تطلعلك الأخطاء، وتقترحلك الحلول، وكمان تحسن جودة المشروع كله من غير وجع دماغ.

‏جرب الحلوين دول:
‏1- Codacy – خفيف وسريع.
‏2- SonarQube – مثالي للمشاريع الكبيرة والمعقدة.
‏3- CodeClimate – بيركز على تحسين جودة الكود.
‏4- DeepSource – بيكشف أدق التفاصيل.
‏5- CodeGuru – بيقدم اقتراحات ذكية لتحسين الأداء.

‏جرب أي واحدة منهم وهتحس بالفرق بجد

طرق التعامل مع Objects في JavaScript

‏لكل الطلاب:

‏دلوقتي تقدروا تستفيدوا من Google Gemini Pro مجانًا لمدة سنة كاملة!

‏مع Gemini Pro هتقدروا:
‏- تستخدموا الذكاء الاصطناعي في كتابة الأبحاث والمشاريع بسهولة.
‏- تلخصوا مقالات ودروس طويلة في ثواني.
‏- تكتبوا أكواد برمجية وتصلحوا الأخطاء أسرع.
‏- تطوروا مهاراتكم وتنجزوا مهامكم بشكل أسرع وأكثر ذكاء.

‏متاح مجانًا للطلاب الجامعيين.
‏سجل دلوقتي من هنا:
‏⁦ gemini.google/students/ ⁩

‏في الصورة دي ملخص ل الشبكات الأساسية

انواع قواعد البيانات

التقنيات البرمجية الحديثة