سمعت عن Keycloak؟
.
.
وأنا شغال على أكتر من مشروع في الفترة اللي فاتت، كان دايمًا فيه سؤال بقابله كل مرة:
"إزاي أظبط موضوع تسجيل دخول المستخدمين والصلاحيات بتاعتهم من غير ما أضطر أبني سيستم Auth كامل من الصفر كل مرة؟"
في الأول زي أي حد…
الـ Login بسيط، شوية JWT، شوية Middleware، وبعدها Roles، Permissions، Social Login، Refresh Tokens...
وفجأة تلاقي نفسك بتبني System كامل علشان حاجة مش هي الـ core بتاع المشروع أصلًا وبتحرق فيها وقت جامد.
لغاية ما قابلت Keycloak 💯
———
أداة Keycloak ببساطة عبارة عن Identity & Access Management
يعني سيستم متكامل بيشيل عنك وجع دماغ التوثيق والصلاحيات، ويديك حاجة جاهزة، قوية، وقابلة للتخصيص.
اللي عجبني فيه مش بس إنه:
- بيدعم OAuth2 / OpenID Connect / SAML
- Single Sign-On (SSO)
- User Management + Roles + Groups
- Social Login (Google, GitHub, …)
- Two-Factor Authentication
- عندك UI جاهز تشتغل عليه أو تعدله
———
الفكرة كلها إنك: تفصل الـ Auth عن البزنس لوجيك بتاع المشروع.
يعني بدل ما كل مشروع يبقى فيه Login مختلف، أو كل Microservice يشيل هم المستخدمين، Keycloak تبقى هي المصدر الوحيد للعمليات دي كلها.
———
لما تبدأ تستخدم Keycloak هتحس لأول مرة إن كل حاجة واضحة:
- مين المستخدم اللي داخل على السيستم
- وليه عنده صلاحية يعمل الحاجة دي
- وإزاي تتحكم في ده كله من غير ما تدخل تعدل في الكود لكل خدمة أو صفحة
ده بيفرق جدًا لو شغال على مشاريع فيها:
- Microservices
- Frontend و Backend منفصلين
- أو حتى سيستم كبير للشركات (Enterprise Systems)
———
طبعًا هي مش حاجة سهلة ومش “Plug & Play” ببساطة، بس أول ما تفهمها صح، هتوفر وقت ومجهود كبير...
.
.
وأنا شغال على أكتر من مشروع في الفترة اللي فاتت، كان دايمًا فيه سؤال بقابله كل مرة:
"إزاي أظبط موضوع تسجيل دخول المستخدمين والصلاحيات بتاعتهم من غير ما أضطر أبني سيستم Auth كامل من الصفر كل مرة؟"
في الأول زي أي حد…
الـ Login بسيط، شوية JWT، شوية Middleware، وبعدها Roles، Permissions، Social Login، Refresh Tokens...
وفجأة تلاقي نفسك بتبني System كامل علشان حاجة مش هي الـ core بتاع المشروع أصلًا وبتحرق فيها وقت جامد.
لغاية ما قابلت Keycloak 💯
———
أداة Keycloak ببساطة عبارة عن Identity & Access Management
يعني سيستم متكامل بيشيل عنك وجع دماغ التوثيق والصلاحيات، ويديك حاجة جاهزة، قوية، وقابلة للتخصيص.
اللي عجبني فيه مش بس إنه:
- بيدعم OAuth2 / OpenID Connect / SAML
- Single Sign-On (SSO)
- User Management + Roles + Groups
- Social Login (Google, GitHub, …)
- Two-Factor Authentication
- عندك UI جاهز تشتغل عليه أو تعدله
———
الفكرة كلها إنك: تفصل الـ Auth عن البزنس لوجيك بتاع المشروع.
يعني بدل ما كل مشروع يبقى فيه Login مختلف، أو كل Microservice يشيل هم المستخدمين، Keycloak تبقى هي المصدر الوحيد للعمليات دي كلها.
———
لما تبدأ تستخدم Keycloak هتحس لأول مرة إن كل حاجة واضحة:
- مين المستخدم اللي داخل على السيستم
- وليه عنده صلاحية يعمل الحاجة دي
- وإزاي تتحكم في ده كله من غير ما تدخل تعدل في الكود لكل خدمة أو صفحة
ده بيفرق جدًا لو شغال على مشاريع فيها:
- Microservices
- Frontend و Backend منفصلين
- أو حتى سيستم كبير للشركات (Enterprise Systems)
———
طبعًا هي مش حاجة سهلة ومش “Plug & Play” ببساطة، بس أول ما تفهمها صح، هتوفر وقت ومجهود كبير...
❤12
backend-handbook.pdf
17.5 MB
كتاب مهم جدًا لجماعة الباك إند 💯
.
.
الكتاب عبارة عن مسار تعلم الباك إند خطوة بخطوة بالإضافة إلى أهم المفاهيم اللي تخص عالم الـ API وكمان أشهر أكواد الـ HTTPS ومعنى كل كود، وأفكار مشاريع تقدر تطبقها خلال رحلة التعلم، وغيرها من المواضيع اللي هتساعدك تطور مهاراتك بشكل كبير في مجال الباك إند. 💡
———
The guide covers the Backend dev roadmap and explains core API concepts, common HTTP status codes, project ideas, & much more.
.
.
الكتاب عبارة عن مسار تعلم الباك إند خطوة بخطوة بالإضافة إلى أهم المفاهيم اللي تخص عالم الـ API وكمان أشهر أكواد الـ HTTPS ومعنى كل كود، وأفكار مشاريع تقدر تطبقها خلال رحلة التعلم، وغيرها من المواضيع اللي هتساعدك تطور مهاراتك بشكل كبير في مجال الباك إند. 💡
———
Complete Backend Handbook 🚀
The guide covers the Backend dev roadmap and explains core API concepts, common HTTP status codes, project ideas, & much more.
❤9👏1
تعال أقولك على كام نصيحة تخلي بالك منها قبل ما تبدأ أي مشروع فريلانسنج 💯
.
.
أولًا: اتفق على كل التفاصيل قبل ما تحط إيدك في المشروع زي مدة تسليم المشروع وهيكلف كام وطريقة التسليم هتكون إزاي وكمان التعديلات المسموح بها خلال فترة العمل أو حتى بعد تسليم المشروع...خليك متفاهم مع العميل وحاول تكون مستمع جيد جدًا.
ثانيًا: خليك واضح مع العميل وعرفه إيه الحاجات اللي هتعملها في المشروع (الصفحات والمميزات وغيرها)...ده هيمنع أي سوء تفاهم بينك وبين العميل وكمان هتكون مريح نفسك من التعديلات اللي بتظهر فجأة وتنكد عليك عيشتك.
ثالثًا: اتفق على الدفعات المالية وإزاي هتاخد فلوسك من العميل وعلى كام مرة...فيه عملاء بترضى إنها تدفع عربون وفيه عملاء بتدفع نصف المبلغ وفيه عملاء مبترضاش غير لما تشوف المكنة طلعت قماش (يعني بدأت شغل في المشروع وطلعت نتائج)...أنا بفضل إنك تاخد جزء من فلوس المشروع أو نصف المبلغ لو ده متاح مع العميل علشان تضمن إن تعبك ميروحش على الأرض.
رابعًا: قبل ما تبدأ في كتابة سطر كود واحد حاول تدرس المشروع كويس جدًا جدًا جدًا...من حيث المشروع كام صفحة وهتحتاج مكتبات إيه وهتشتغل بأي طريقة وهتبدأ من أي مكان في المشروع وهكذا...وأكيد مش هتكون مُلم بكل ده من أول مشروع ولكن الموضوع بيجي مع الممارسة وكثرة الشغل.
خامسًا: لو المشروع كبير شوية وفيه إمكانية تكتب عقد مع العميل (لو هو من بلدك) اعمل ده واضمن حقك علشان لو العميل قرر يخلع في نص المشروع...والعقد يكون موضح فيه كل تفاصيل المشروع.
سادسًا: خليك على تواصل دائم مع العميل وبلغه بالنتائج أول بأول...ده هيخلي عنده انطباع كويس عنك وممكن يكون سبب في باب رزق لك قدام (وده عن تجارب شخصية)...متنامش في الخط وتسيب العميل يكلم في نفسه ويظن فيك سوء.
سابعًا: خليك صريح مع العميل لو حصلت عندك ظروف أو حصل تأخير في تسليم المشروع وحاول تعوضه بأي حاجة زي إنك هتزود فترة التعديلات اللي بعد التسليم 48 ساعة مثلًا أو إنك هتضيف ميزة جديدة شايف إنها هتكون كويسة في المشروع (خليك ناصح).
ثامنًا: خليك هادي مع العميل واوعى تتعصب عليه أو تكلمه بطريقة وحشة لأن ده هيعود عليك بالسلب ده غير إنه ممكن يخلع وتضيع مجهودك على الفاضي...ادفع بالتي هي أحسن...كل عيش يا حماده ومشي أمورك.
تاسعًا: خليك جاهز للنقد والتقييم حتى لو بالسلب...حاول تاخد تقييم من العميل وكمان تكون متقبل النقد لأنك صعب تلاقي عميل راضي 100% ولكن اسمع منه التقييم والنقد وحاول تصلح الحاجات دي في المشروع الجاي.
وأخيرًا: لو المشروع كبير عليك وهياخد منك وقت كبير ممكن تستعين بصديق أو تبحث عن أي شخص يساعدك فيه...وده من باب واللهُ في عونِ العبدِ ما كان العبدُ في عونِ أخيه.
———
بالتوفيق يا صديقي 🌿
.
.
أولًا: اتفق على كل التفاصيل قبل ما تحط إيدك في المشروع زي مدة تسليم المشروع وهيكلف كام وطريقة التسليم هتكون إزاي وكمان التعديلات المسموح بها خلال فترة العمل أو حتى بعد تسليم المشروع...خليك متفاهم مع العميل وحاول تكون مستمع جيد جدًا.
ثانيًا: خليك واضح مع العميل وعرفه إيه الحاجات اللي هتعملها في المشروع (الصفحات والمميزات وغيرها)...ده هيمنع أي سوء تفاهم بينك وبين العميل وكمان هتكون مريح نفسك من التعديلات اللي بتظهر فجأة وتنكد عليك عيشتك.
ثالثًا: اتفق على الدفعات المالية وإزاي هتاخد فلوسك من العميل وعلى كام مرة...فيه عملاء بترضى إنها تدفع عربون وفيه عملاء بتدفع نصف المبلغ وفيه عملاء مبترضاش غير لما تشوف المكنة طلعت قماش (يعني بدأت شغل في المشروع وطلعت نتائج)...أنا بفضل إنك تاخد جزء من فلوس المشروع أو نصف المبلغ لو ده متاح مع العميل علشان تضمن إن تعبك ميروحش على الأرض.
رابعًا: قبل ما تبدأ في كتابة سطر كود واحد حاول تدرس المشروع كويس جدًا جدًا جدًا...من حيث المشروع كام صفحة وهتحتاج مكتبات إيه وهتشتغل بأي طريقة وهتبدأ من أي مكان في المشروع وهكذا...وأكيد مش هتكون مُلم بكل ده من أول مشروع ولكن الموضوع بيجي مع الممارسة وكثرة الشغل.
خامسًا: لو المشروع كبير شوية وفيه إمكانية تكتب عقد مع العميل (لو هو من بلدك) اعمل ده واضمن حقك علشان لو العميل قرر يخلع في نص المشروع...والعقد يكون موضح فيه كل تفاصيل المشروع.
سادسًا: خليك على تواصل دائم مع العميل وبلغه بالنتائج أول بأول...ده هيخلي عنده انطباع كويس عنك وممكن يكون سبب في باب رزق لك قدام (وده عن تجارب شخصية)...متنامش في الخط وتسيب العميل يكلم في نفسه ويظن فيك سوء.
سابعًا: خليك صريح مع العميل لو حصلت عندك ظروف أو حصل تأخير في تسليم المشروع وحاول تعوضه بأي حاجة زي إنك هتزود فترة التعديلات اللي بعد التسليم 48 ساعة مثلًا أو إنك هتضيف ميزة جديدة شايف إنها هتكون كويسة في المشروع (خليك ناصح).
ثامنًا: خليك هادي مع العميل واوعى تتعصب عليه أو تكلمه بطريقة وحشة لأن ده هيعود عليك بالسلب ده غير إنه ممكن يخلع وتضيع مجهودك على الفاضي...ادفع بالتي هي أحسن...كل عيش يا حماده ومشي أمورك.
تاسعًا: خليك جاهز للنقد والتقييم حتى لو بالسلب...حاول تاخد تقييم من العميل وكمان تكون متقبل النقد لأنك صعب تلاقي عميل راضي 100% ولكن اسمع منه التقييم والنقد وحاول تصلح الحاجات دي في المشروع الجاي.
وأخيرًا: لو المشروع كبير عليك وهياخد منك وقت كبير ممكن تستعين بصديق أو تبحث عن أي شخص يساعدك فيه...وده من باب واللهُ في عونِ العبدِ ما كان العبدُ في عونِ أخيه.
———
بالتوفيق يا صديقي 🌿
❤9
Sync External State with React ✅
Integrate external state managers into React the right way using useSyncExternalStore.
❤2
to-learn-in-react.pdf
372 KB
دليل شامل هيساعدك تتعلم React.js وتعرف كل الأدوات والمفاهيم اللي هتفيدك خلال رحلة التعلم 💯
𝐓𝐨 𝐋𝐞𝐚𝐫𝐧 𝐢𝐧 𝐑𝐞𝐚𝐜𝐭: 𝐀 𝐂𝐨𝐦𝐩𝐫𝐞𝐡𝐞𝐧𝐬𝐢𝐯𝐞 𝐆𝐮𝐢𝐝𝐞 ✅
𝐓𝐨 𝐋𝐞𝐚𝐫𝐧 𝐢𝐧 𝐑𝐞𝐚𝐜𝐭: 𝐀 𝐂𝐨𝐦𝐩𝐫𝐞𝐡𝐞𝐧𝐬𝐢𝐯𝐞 𝐆𝐮𝐢𝐝𝐞 ✅
❤2👍2
أداة Chrome DevTools MCP هدفها أنها تساعد الـ AI Agent يختبر الموقع على المتصفح.
It acts as a Model-Context-Protocol (MCP) server, giving your AI coding assistant access to the full power of Chrome DevTools for reliable automation, in-depth debugging, and performance analysis.
———
https://github.com/ChromeDevTools/chrome-devtools-mcp
Chrome DevTools MCP 🚀
chrome-devtools-mcp lets your coding agent (such as Gemini, Claude, Cursor or Copilot) control and inspect a live Chrome browser. It acts as a Model-Context-Protocol (MCP) server, giving your AI coding assistant access to the full power of Chrome DevTools for reliable automation, in-depth debugging, and performance analysis.
———
https://github.com/ChromeDevTools/chrome-devtools-mcp
❤1🤩1
أدوات_الذكاء_الإصطناعي_مرتبة_حسب_الإستخدام.pdf
9.6 MB
ملف رائع من سدايا .. كل أدوات الذكاء الإصطناعي مرتبة حسب الإستخدام باللغة العربية 💯
❤1👍1
البرمجة الوظيفية (Functional Programming)
.
.
البرمجة الوظيفية (Functional Programming) هي واحدة من الأنماط البرمجية اللي بتختلف عن النمط التقليدي اللي بنسميه الـ Imperative Programming.
الفكرة الأساسية في البرمجة الوظيفية إنها بتركز على استخدام الدوال (functions) كعنصر أساسي في كتابة الكود، وبتعتمد على فكرة إن الكود يكون واضح وسهل التتبع، بدون ما نغير الـ state أو البيانات بشكل مباشر.
———
📌 إيه اللي بيميز البرمجة الوظيفية؟
في البرمجة الوظيفية، بنستخدم حاجة اسمها pure functions، ودي دوال بتستقبل مدخلات (inputs) وتطلع مخرجات (outputs) من غير ما تأثر على أي حاجة خارج الدالة نفسها.
يعني الدالة اللي بتشتغل بالطريقة دي، كل مرة تستخدمها بنفس المدخلات، هتطلع نفس النتيجة. ده بيسهل جدًا اختبار الكود والتأكد إنه شغال صح.
كمان في البرمجة الوظيفية بنبعد تمامًا عن فكرة side effects، اللي هي تغيير في البيانات أو الـ state خارج الدالة. وده بيدي الكود ميزة إنه يبقى قابل للتوقع (predictable) وسهل الصيانة.
———
📌 الـ Higher-Order Functions
البرمجة الوظيفية بتعتمد بشكل كبير على نوع خاص من الدوال اسمه Higher-Order Functions. الدوال دي بتستقبل دوال تانية كمدخلات أو بتطلع دوال كمخرجات.
مثلًا في JavaScript عندنا دوال زي map, filter, reduce، ودي أمثلة ممتازة على الـ Higher-Order Functions.
الدوال دي بتخليك تقدر تعمل عمليات معقدة على البيانات بطريقة مختصرة ومنظمة، وبدون ما تكتب كود كتير. مثلًا لو عاوز تعدل قيم معينة في Array، بدل ما تستخدم for loop، ممكن تستخدم map واللي بتخليك تقدر تعيد بناء الـ Array بطريقة أسرع وأسهل.
———
📌 الـ Immutable Data
واحدة من المفاهيم الأساسية كمان في البرمجة الوظيفية هي immutable data، يعني البيانات مبتتغيرش. بدل ما نعدل على نفس الـ Array أو الـ Object، بنرجع نسخة جديدة من البيانات بعد التعديل.
ده بيدي الكود أمان أكتر، وبيمنع الأخطاء اللي ممكن تحصل لما البيانات تتغير بطريقة غير متوقعة.
البرمجة الوظيفية بتتطبق في لغات زي Haskell وElm بشكل كبير، لكن الأفكار دي كمان ممكن تتطبق في لغات زي JavaScript, Python وحتى Java و#C.
———
📌 ليه تستخدم البرمجة الوظيفية؟
- الكود بيكون واضح جدًا وسهل التتبع.
- التقليل من الأخطاء بفضل استخدام الـ pure functions.
- سهولة اختبار الكود.
- دعم الـ parallelism والـ concurrency بشكل أفضل.
———
وفقكم الله لكل خير ☘️
.
.
البرمجة الوظيفية (Functional Programming) هي واحدة من الأنماط البرمجية اللي بتختلف عن النمط التقليدي اللي بنسميه الـ Imperative Programming.
الفكرة الأساسية في البرمجة الوظيفية إنها بتركز على استخدام الدوال (functions) كعنصر أساسي في كتابة الكود، وبتعتمد على فكرة إن الكود يكون واضح وسهل التتبع، بدون ما نغير الـ state أو البيانات بشكل مباشر.
———
📌 إيه اللي بيميز البرمجة الوظيفية؟
في البرمجة الوظيفية، بنستخدم حاجة اسمها pure functions، ودي دوال بتستقبل مدخلات (inputs) وتطلع مخرجات (outputs) من غير ما تأثر على أي حاجة خارج الدالة نفسها.
يعني الدالة اللي بتشتغل بالطريقة دي، كل مرة تستخدمها بنفس المدخلات، هتطلع نفس النتيجة. ده بيسهل جدًا اختبار الكود والتأكد إنه شغال صح.
كمان في البرمجة الوظيفية بنبعد تمامًا عن فكرة side effects، اللي هي تغيير في البيانات أو الـ state خارج الدالة. وده بيدي الكود ميزة إنه يبقى قابل للتوقع (predictable) وسهل الصيانة.
———
📌 الـ Higher-Order Functions
البرمجة الوظيفية بتعتمد بشكل كبير على نوع خاص من الدوال اسمه Higher-Order Functions. الدوال دي بتستقبل دوال تانية كمدخلات أو بتطلع دوال كمخرجات.
مثلًا في JavaScript عندنا دوال زي map, filter, reduce، ودي أمثلة ممتازة على الـ Higher-Order Functions.
الدوال دي بتخليك تقدر تعمل عمليات معقدة على البيانات بطريقة مختصرة ومنظمة، وبدون ما تكتب كود كتير. مثلًا لو عاوز تعدل قيم معينة في Array، بدل ما تستخدم for loop، ممكن تستخدم map واللي بتخليك تقدر تعيد بناء الـ Array بطريقة أسرع وأسهل.
———
📌 الـ Immutable Data
واحدة من المفاهيم الأساسية كمان في البرمجة الوظيفية هي immutable data، يعني البيانات مبتتغيرش. بدل ما نعدل على نفس الـ Array أو الـ Object، بنرجع نسخة جديدة من البيانات بعد التعديل.
ده بيدي الكود أمان أكتر، وبيمنع الأخطاء اللي ممكن تحصل لما البيانات تتغير بطريقة غير متوقعة.
البرمجة الوظيفية بتتطبق في لغات زي Haskell وElm بشكل كبير، لكن الأفكار دي كمان ممكن تتطبق في لغات زي JavaScript, Python وحتى Java و#C.
———
📌 ليه تستخدم البرمجة الوظيفية؟
- الكود بيكون واضح جدًا وسهل التتبع.
- التقليل من الأخطاء بفضل استخدام الـ pure functions.
- سهولة اختبار الكود.
- دعم الـ parallelism والـ concurrency بشكل أفضل.
———
وفقكم الله لكل خير ☘️
❤6👍1
مفهوم الـ Optimistic UI 💯
.
.
إزاي تخلي المستخدم يشوف التطبيق بتاعك سريع حتى لو هو سلحفاة؟
تخيل معايا السيناريو ده: أنت فاتح تطبيق طلبات الأكل، ضغطت على زرار "تأكيد الطلب" أو "Confirm Order"، وفورًا ظهر لك إن الطلب اتبعت واتسجل، وبعدها بثانية كده جالك إشعار إن المطعم بدأ يحضّر الأكل. إحساسك إيه؟ التطبيق سريع، ومفيش أي تأخير.
بس الحقيقة إن الطلب ممكن يكون لسه بيتبعت للسيرفر، ولسه فيه احتمال إنه يفشل، صح؟
هنا بقى بييجي دور الـ Optimistic UI ... تعال ندردش شوية ونفهم إزاي بيشتغل وأهم الاستخدامات.
———
📌 إزاي الـ Optimistic UI بيشتغل؟
بدل ما تستنى الـ API Response، التطبيق بيعمل تحديث فوري للـ UI بافتراض إن العملية هتنجح، وبعدها بيتأكد من السيرفر. لو الـ API رجعت success، مفيش حاجة تتغير لأن المستخدم أصلًا شاف النتيجة المتوقعة. لكن لو حصل فشل، ساعتها بتعمل Rollback وترجع الـ UI للحالة الأصلية، أو تعرض رسالة خطأ.
———
🎯 مثال عملي بسيط
خلينا نقول عندنا تطبيق To-Do List، لما المستخدم يضيف Task جديدة:
- بدل ما تستنى Response من السيرفر، بتضيف الـ Task مباشرة في الـ UI.
- في الخلفية، التطبيق بيبعت الـ Request للسيرفر لحفظ الـ Task في قواعد البيانات (Database).
- لو كل حاجة مشيت تمام، مفيش حاجة هتتغير.
- لو حصل Error، بتعمل Rollback وتشيل الـ Task من الواجهة، أو تعرض رسالة خطأ.
———
📌 أهم استخدامات الـ Optimistic UI:
- الـ Like و Follow في السوشيال ميديا (أكيد لاحظت في بعض المنشورات على لينكدإن لما بتتفاعل معها وتعمل سكرول شوية تظهر رسالة إنه حدث خطأ في التفاعل مع المنشور).
- إضافة منتجات لعربة التسوق في المتاجر الإلكترونية.
- التعديلات الفورية على البيانات بدون Reload.
———
⚠️ إمتى تستخدم الـ Optimistic UI وإمتى تبعد عنه؟
✅ استخدمه لو العملية بنسبة كبيرة جدًا هتنجح، زي إضافة لايك، حفظ تعليق، أو تعديل بيانات المستخدم.
❌ بلاش تستخدمه لو العملية فيها احتمالية فشل كبيرة أو ممكن تسبب مشاكل لو حصل Rollback، زي عمليات الدفع المالية أو مسح بيانات حساسة.
———
🛠 تطبيق عملي باستخدام React
لو بتستخدم الـ React Query، فالموضوع سهل وبسيط، عندك useMutation بتوفر خاصية onMutate عشان تحدث الـ UI قبل ما العملية تحصل، ولو فشلت، بتستخدم onError تعمل Rollback.
———
خلاصة القول
الـ Optimistic UI بيحسّن تجربة المستخدم بشكل كبير، وبيخلي التطبيقات سريعة من وجهة نظر المستخدم. بس لازم تخلي بالك من كل حالات الفشل.
———
وفقكم الله لكل خير 🌿
.
.
إزاي تخلي المستخدم يشوف التطبيق بتاعك سريع حتى لو هو سلحفاة؟
تخيل معايا السيناريو ده: أنت فاتح تطبيق طلبات الأكل، ضغطت على زرار "تأكيد الطلب" أو "Confirm Order"، وفورًا ظهر لك إن الطلب اتبعت واتسجل، وبعدها بثانية كده جالك إشعار إن المطعم بدأ يحضّر الأكل. إحساسك إيه؟ التطبيق سريع، ومفيش أي تأخير.
بس الحقيقة إن الطلب ممكن يكون لسه بيتبعت للسيرفر، ولسه فيه احتمال إنه يفشل، صح؟
هنا بقى بييجي دور الـ Optimistic UI ... تعال ندردش شوية ونفهم إزاي بيشتغل وأهم الاستخدامات.
———
📌 إزاي الـ Optimistic UI بيشتغل؟
بدل ما تستنى الـ API Response، التطبيق بيعمل تحديث فوري للـ UI بافتراض إن العملية هتنجح، وبعدها بيتأكد من السيرفر. لو الـ API رجعت success، مفيش حاجة تتغير لأن المستخدم أصلًا شاف النتيجة المتوقعة. لكن لو حصل فشل، ساعتها بتعمل Rollback وترجع الـ UI للحالة الأصلية، أو تعرض رسالة خطأ.
———
🎯 مثال عملي بسيط
خلينا نقول عندنا تطبيق To-Do List، لما المستخدم يضيف Task جديدة:
- بدل ما تستنى Response من السيرفر، بتضيف الـ Task مباشرة في الـ UI.
- في الخلفية، التطبيق بيبعت الـ Request للسيرفر لحفظ الـ Task في قواعد البيانات (Database).
- لو كل حاجة مشيت تمام، مفيش حاجة هتتغير.
- لو حصل Error، بتعمل Rollback وتشيل الـ Task من الواجهة، أو تعرض رسالة خطأ.
———
📌 أهم استخدامات الـ Optimistic UI:
- الـ Like و Follow في السوشيال ميديا (أكيد لاحظت في بعض المنشورات على لينكدإن لما بتتفاعل معها وتعمل سكرول شوية تظهر رسالة إنه حدث خطأ في التفاعل مع المنشور).
- إضافة منتجات لعربة التسوق في المتاجر الإلكترونية.
- التعديلات الفورية على البيانات بدون Reload.
———
⚠️ إمتى تستخدم الـ Optimistic UI وإمتى تبعد عنه؟
✅ استخدمه لو العملية بنسبة كبيرة جدًا هتنجح، زي إضافة لايك، حفظ تعليق، أو تعديل بيانات المستخدم.
❌ بلاش تستخدمه لو العملية فيها احتمالية فشل كبيرة أو ممكن تسبب مشاكل لو حصل Rollback، زي عمليات الدفع المالية أو مسح بيانات حساسة.
———
🛠 تطبيق عملي باستخدام React
لو بتستخدم الـ React Query، فالموضوع سهل وبسيط، عندك useMutation بتوفر خاصية onMutate عشان تحدث الـ UI قبل ما العملية تحصل، ولو فشلت، بتستخدم onError تعمل Rollback.
———
خلاصة القول
الـ Optimistic UI بيحسّن تجربة المستخدم بشكل كبير، وبيخلي التطبيقات سريعة من وجهة نظر المستخدم. بس لازم تخلي بالك من كل حالات الفشل.
———
وفقكم الله لكل خير 🌿
❤10