https://www.youtube.com/watch?v=qT8N7yx1bMA
*shadow-form-handler*
مكتبة بناها الشادو أخونا عشان ي handle ال Form validations ف وجب نوجهله كل الدعم ونجربها

Warning: Each child in a list should have a unique "key" prop

مستحيل تكون اشتغلت بريأكت ومشوفتش ال Warning ده :(
في اللحظة دي ممكن تفكر "ما هو مجرد تحذير"، لكن صدقني، الموضوع أخطر من كده. التحذير ده ممكن يكون سبب لمشاكل كبيرة في الـ application بتاعك.


إيه هو الـ key prop؟
الـ key prop بيكون هو الidentity بتاعت العنصر في الـ DOM. يعني لازم يكون unique وstatic عشان يفرق بين العناصر.
لو ما استخدمتش الـ key prop أو استخدمته غلط ف صدقني الموضوع مش بسيط
تعال بقي نبص للحوار دا من حياة الديفلوبرز ونشوف الديفلوبرز بيعملوا implement لل Keys إزاي ؟

استخدام Index of an array كـ KEY و جيس وات الحوار دا مش صح ، إستخدامك لل Index بيعتبر Anti-pattern.
وده رغم إنه أسهل طريقة للتخلص من التحذير اللي في الكونسول، لكنه زي السيف ذو الحدين.
الطريقة دي ممكن تسبب مشاكل كبيرة لو استخدمتها من غير ما تكون فاهم كويس إيه اللي بيحصل.
يعني فيه حالات مينفعش تستخدم فيها ال Index ك Keys منها :
لو ضفت عناصر جديدة في بداية أو نص الـ Array
لو عملت فلترة للـ Array
خلينا نبص على مثال في الصورة رقم 1
في الكود ده، عندنا Array ونقدر نضيف عناصر في البداية أو النهاية. لو ضفنا عنصر في النهاية، هتلاقي إن الـ Item 1 بياخد الـ Key 0 و الـ Item 2 بياخد الـ Key 1 ودا تمام تبدأ فين المشكلة ؟ لو ضفنا عنصر في بداية الـ Array، الـ Item 3 هيكون في الأول لكنه بياخد الـ Key 0 بدل ما ياخد 2.
وده ممكن يسبب مشاكل غير متوقعة في التطبيق زي إيه ؟
تخيل إنك شغال على تطبيق إدارة مهام (To-Do List) للمستخدمين، والتطبيق ده فيه قائمة مهام بتتحدث بشكل مستمر، والمستخدم بيقدر يضيف ويعدل ويحذف المهام في أي وقت.
الكود اللي عندك فيه مشكلة إنك بتستخدم index بتاع الـ Array كـ key لكل مهمة (task).
خليني أوريك إزاي ده ممكن يسبب كارثة فعلية.
المستخدم عنده القائمة التالية من المهام:

Task 1 (Key 0)
Task 2 (Key 1)
Task 3 (Key 2)
المستخدم قرر إنه يضيف مهمة جديدة في بداية القائمة (Task 4):

Task 4 (Key 0)
Task 1 (Key 1)
Task 2 (Key 2)
Task 3 (Key 3)
هنا كل حاجة ظاهرة تمام؟ المشكلة الكارثية بقي
تخيل إن المستخدم بيعدل على Task 3 (اللي كانت في الأصل في آخر القائمة، يعني Key 2) وبيكتب فيها ملاحظات مهمة جدًا للعمل بتاعه. وبعدين بيقرر يضيف مهمة جديدة في بداية القائمة. لما المستخدم يعمل كده، التطبيق بيقوم بعملية إعادة ترتيب للـ Keys:
Task 5 (Key 0)
Task 4 (Key 1)
Task 1 (Key 2)
Task 2 (Key 3)
Task 3 (Key 4)
اللي حصل هنا كارثة فعلية. ليه؟ لأن الـ Key بتاع كل مهمة اتغير، وده معناه إن الملاحظات اللي المستخدم كتبها في Task 3 اتحولت لمهمة تانية، أو حتى راحت تمامًا! السبب في ده هو إن الـ Key اللي مستخدمينه مش ثابت، وبمجرد ما بيحصل أي تغيير في ترتيب المهام، البيانات المرتبطة بالـ Key ده بتتلخبط.
عشان نتجنب المشاكل دي، ماينفعش نستخدم الـ Index كـ Key وهنبص ع حلول دلوقتي

في بعض الحالات ممكن نستخدم الـ Index كـ Key:

لو العناصر الجديدة بتضاف في نهاية الـ Array (لأن كده مش هيأثر على الـ Index بتاع العناصر القديمة).
لو الـ Array ثابتة (Static).
لو الـ Array مش بتتفلتر.
نبص ع الحلول بقي ؟
2. استخدام Unique ID من الـ Dataset
ده أفضل حل بدون شك، لأنك عندك Unique ID جاهز في البيانات.
3. توليد Unique IDs باستخدام Packages
في حالة إنك ماعندكش Unique IDs في الـ List، الأفضل إنك تولد Keys باستخدام بعض الـ Packages زي react-uuid أو uuid.
كمثال ع دا بص ع الصورة رقم 2
اتأكد دايمًا إنك بتولد الـ Keys قبل ما الـ Component يتعمله Mount (يعني في componentWillMount أو قبل ما يترندر). ده عشان تمنع توليد IDs جديدة في كل مرة الـ Component بيتعمله Render.
نصيحة أخيرة
استخدام Math.Random() مش مستحب نهائيًا عشان ممكن يتولد نفس الرقم مرتين، وده ممكن يسبب مشاكل.

دا مثال ع الpolyfill
لل include method
لو عاوز تعرف أكتر إيه هو ال polyfill
تقدر تقرأ المقال كامل هنا
https://whatsapp.com/channel/0029VaBfs40KAwEfBoG88Q2J/163

وإنت بتستخدم React Router أكيد قابلك المشكلة دي ،بشكل افتراضي، في أي تطبيق معمول بـReact Router، لما تعمل navigation من صفحة لصفحة تانية، الـscroll ما بيرجعش للأول، يعني لو كنت قافل الصفحة وانت في جزء معين منها، الصفحة التانية هتفتح وانت في نفس المكان.
في المقال ده، هنحل المشكلة دي سوا
بعد ما شفت إن الـscroll مش بيتغير، تعالوا نشوف مع بعض ليه ده بيحصل، وبعد كده نحل المشكلة.
ليه دا بيحصل؟
علشان نفهم ليه الـscroll position مبيتغيرش بشكل افتراضي بعد التنقل بين الصفحات في React Router، محتاجين نبص على طريقة عمل الـReact Router وكود الـSPA (Single Page Application).
ليه ما بيتغيرش الـscroll؟
لأن الكود ما بيحتويش على أي حاجة بتتحكم في الـscroll position. الـReact Router ببساطة بيعرض الصفحة الجديدة على نفس الوضع اللي كان فيه المستخدم قبل التنقل.
هو بيفترض إنك ممكن تكون عايز تحتفظ بمكانك على الصفحة اللي كنت فيها لما ترجع ليها. عشان كده، لما تضغط على رابط وتنتقل لصفحة جديدة، الصفحة الجديدة بتفتح بنفس المكان اللي كنت واقف فيه في الصفحة اللي قبلها.

فلو كنت مثلاً نازل تحت في الصفحة وشفت نص معين، وبعد كده انتقلت لصفحة تانية، هتلاقي إن الصفحة الجديدة فتحت وانت واقف تقريبًا في نفس المكان في الصفحة التانية، وما بترجعش لأعلى الصفحة بشكل تلقائي. ده اللي بنسميه "الحفاظ على حالة الـscroll"، وده الافتراضي في React Router.
الحل بيكون إنك تضيف كود أو تستخدم component زي ScrollRestoration عشان تتحكم في الـscroll position وتخليه يرجع لأول الصفحة بعد كل انتقال.
أول طريقة
طريقة ترجيع الـscroll باستخدام <ScrollRestoration />
React Router
بتوفر طريقة بسيطة جداً لترجيع الـscroll لمكانه الأول في كل مرة تعمل فيها انتقال بين الصفحات عن طريق استخدام الـ<ScrollRestoration /> .
بص كدا ع الكود اللي ف الصورة الأولي
في المثال دا SomePage و AnotherPage دي بتمثل الصفحات اللي المستخدم هيشوفها.
Root Component:
ده هو الـ layout الأساسي اللي كل الصفحات بترث منه. فيه Outlet اللي بيعرض مكونات الصفحات الفرعية، وفيه كمان nav اللي بيمثل قائمة الروابط للتنقل بين الصفحات. كمان، استخدمنا ScrollRestoration علشان نضمن إن الـ scroll بيتظبط تلقائيًا بعد كل انتقال.

createBrowserRouter
هنا بنعرّف ال (routes) بتاعة التطبيق. إحنا عرفنا طريقين (routes) أساسيين:
واحد لصفحة SomePage.
والتاني لصفحة AnotherPage.
ده بيخلي التطبيق يقدر يوجه المستخدم للصفحة المطلوبة بناءً على الـ URL.
RouterProvider
ده بيغلف التطبيق كله ويوفر التوجيهات (routing) اللي عرفناها علشان نقدر نستخدمها في كل مكان في التطبيق.
ScrollRestoration
هو كومبوننت من React Router بيساعد في ضبط مكان(scroll) بعد ما المستخدم ينتقل بين الصفحات.
ScrollRestoration
بيحل المشكلة دي وبيخلي السكرول يرجع لنقطة البداية (أعلى الصفحة) بعد كل انتقال.
الحل التاني بقي ؟
طريقة ترجيع الـscroll باستخدام useLayoutEffect() وscrollTo()
لو مش عايز المستخدم يشوف حركة الـscroll، ومحتاج الصفحة تتنقل لأعلاها مرة واحدة بدون أي أنيميشن، الحل ده ممكن يفيدك.
عشان نرجع الـscroll، هنستخدم الـuseLayoutEffect()
hook،
وهنستخدم الـscrollTo() عشان ننقل الصفحة لأعلاها وهنمرر القيمة "instant"
لـbehavior option عشان الأنيميشن يكون غير ملحوظ.
خلي بالك إننا بنستخدم useLayoutEffect() مش useEffect() عشان نرجع الـscroll قبل ما الصفحة الجديدة تتعرض ليه بقي ؟
useEffect()
بيتم تنفيذه بعد ما React يخلص من عملية ال (rendering) وعرض المحتوى على الشاشة.
useLayoutEffect()
بيتم تنفيذه بعد ما React يخلص من تعديل الـ DOM لكن قبل ما يحصل أي تحديثات تظهر للمستخدم على الشاشة.
منع الـ
FOUC (Flash of Unscrolled Content)
لو استخدمنا useEffect()، ممكن يحصل ما يسمى بـ FOUC، وهو إن المستخدم يشوف محتوى الصفحة الجديدة في مكان التمرير القديم للحظات قبل ما الـscroll يرجع لأعلى الصفحة.
useLayoutEffect() بيحل المشكلة دي لأنه بيتم تنفيذه في نفس اللحظة اللي بيتم فيها تعديل الـ DOM
فالمستخدم ما يلاحظش أي فرق.
كمثال ع دا بص ع الصورة رقم 2

https://useglass.ai/
أنا مش هتكلم ..

https://devdojo.com/tails
TailwindCSS Website Builder

فيه نسخة free إمكانياتها limited ، وفيه نسخة مدفوعة

https://uiball.com/ldrs/

preloaders
جامدة جمودة وتقدر ت customize فيها براحتك

https://llamacoder.together.ai/

خد الهدية دي مني وإدعيلي إديله اللي إنت محتاج تعمله وهيديهولك بريأكت

https://scrollbar.app
Design your scrollbar style online interactively and directly copy the adjusted CSS code.

يعني إيه Error Boundaries؟
Error Boundaries
ببساطة هما components في React بتتحط حوالين components تانية عشان تCatch أي أخطاء تحصل في الـrendering أو ال Lifecycle Methods بتاعة الcomponents دي. يعني زي شبكة أمان كده بتمنع التطبيق كله إنه ي failing لو فيه خطأ حصل في component معين. الفكرة إننا بدل ما المستخدم يشوف شاشة بيضا أو الأبلكيشن مش شغال بنعرضله fallback UIs
إيه فايدة Error Boundaries؟
الفايدة الرئيسية لـ Error Boundaries هي إنها بتحمي التطبيق من الcrashing لو حصلت مشكلة غير متوقعة. يعني لو فيه component حصل فيه مشكلة، Error Boundaries بتعزله وتتعامل معاه، وده بيضمن إن بقية التطبيق يفضل شغال بدون مشاكل. كمان هي بتحسن تجربة المستخدم لأنها بتعرض رسائل خطأ أو fallback بدل ما المستخدم يشوف حاجة مش مفهومة أو شاشة فاضية.
أنواع الأخطاء اللي ممكن تعملها Caught بال Error Boundaries

الأخطاء اللي بتحصل في الـRendering
لو فيه component حصل فيه مشكلة أثناء الـrendering، زي مثلًا قيمة مش متوقعة أو متغير undefined، بتcatch الخطأ ده. الأخطاء دي ممكن تحصل بسبب داتا غلط مبعوتة للcomponent، أو مشكلة في component structure أو في لوجيك ال component.
أخطاء في Lifecycle Methods
الcomponents في React عندها Lifecycle Methods زي componentDidMount, componentDidUpdate, وcomponentWillUnmount. الأخطاء هنا ممكن تحصل لو فيه مشكلة في API call، أو لما نعدل state، أو لو فيه مشكلة مع مكتبة خارجية. Error Boundaries بتcatch الأخطاء دي وتمنعها من إنها توقف عملية الـrendering أو تخلي التطبيق يfail.
شايفكم ي محدثين الريأكت وانتوا بتقولوا اي ال Lifecycle Methods دي أول مرة أسمع عنها :(
أخطاء في Child Components
ال Error Boundaries مفيدة جدًا في إنها تcatch الأخطاء اللي بتحصل في الComponent اللي جواها. يعني لو فيه مشكلة في الـrendering أو في Lifecycle Methods بتاعت child component،
ال Error Boundaries الأقرب لل Component هتcatch الخطأ ده وتمنعه من إنه يطلع لفوق ويأثر على بقية التطبيق.
أخطاء في Event Handlers
مهم نعرف إن Error Boundaries مبتعملش catch للأخطاء اللي بتحصل في Event Handlers أو الكود اللي بيشتغل بشكل غير متزامن زي setTimeout أو الـfetch requests. في الحالة دي، لازم نستخدم JavaScript try-catch عشان نتعامل مع الأخطاء.
أخطاء في Constructors كمان ممكن الأخطاء اللي بتحصل في الـconstructor بتاع الComponent. لو فيه خطأ حصل أثناء مرحلة الـinitialization،
ال Error Boundaries هتعمله catch وتتعامل معاه بشكل مناسب، وده بيضمن إن الComponent يفضل شغال تمام
إزاي نطبق ال Error Boundaries؟
عشان نعمل Error Boundary، لازم نعمل Class Component بتستخدم method اسمها getDerivedStateFromError وmethod تانية اسمها componentDidCatch. الميثود الأولانية بتسمح للكومبوننت إنه يغير الـstate لو حصل خطأ، والتانية بتتعامل مع الخطأ وتعرض واجهة بديلة أو ت log الخطأ عشان نعرف نصلحه.
بنحط Error Boundaries حوالين Components
عشان نستخدم الـError Boundary، بنحطها ك wrapper لل Component اللي محتمل يحصل فيها مشاكل. لما يحصل خطأ في child component
ال React بتشغل method componentDidCatch في أقرب Error Boundary وبتتعامل مع الخطأ.
نعال نبص ع مثال لل Error Boundary Component

نصايح لاستخدامها صح
حاول تحط الـError Boundaries في المكان الصح
الأفضل إنك تحطها حوالين الأجزاء اللي فيها احتمال أكبر لحدوث أخطاء، عشان تضمن إن الأخطاء في Component معين ما تأثرش على التطبيق كله.
استخدم أكتر من Error Boundary


لو عندكlarge component trees ، يبقى من الأفضل إنك تستخدم أكتر من Error Boundary. ده بيديك تحكم أدق في معالجة الأخطاء، وبتقدر تعرض واجهات بديلة أو رسائل خطأ مخصصة لكل جزء من التطبيق الnext عظمة ف الحوار دا
زي أي جزء تاني من الكود، لازم تختبر الـError Boundaries كويس. عشان تتأكد إنها بتشتغل زي ما أنت متوقع وتتعامل مع الأخطاء بشكل سليم.

ممكن توفر ع نفسك وتستخدم react-error-boundary واحد من اللي عاملينها kentcdodds اللي عامل كورس ريأكت عظمة

خلينا نتكلم شوية عن السر اللي بيخلي المواقع المفضلة عندك سريعة ومستجيبة بالشكل ده. السر في الموضوع ده بيرجع لطريقة التعامل مع الـ DOM.
الـ (Document Object Model) بيمثل الصفحة بتاعتك على هيئة structured tree.
زمان كنا بنستخدم طرق في الـ JavaScript زي getElementById أو removeChild عشان نعمل تعديلات على الصفحة. لكن مع تعقيد المواقع الويب وتوسعها، الطرق دي ممكن تخلي الأداء بطيء. هنا بتيجي قوة React بالـ Virtual DOM اللي غيرت قواعد اللعبة تمامًا.
المشكلة في التعامل مع الـ DOM بالطريقة التقليدية
تخيل الـ DOM كشجرة ضخمة مليانة فروع. كل مرة تحب تعدل حاجة بسيطة، زي إنك تحدث أول عنصر في قائمة من عشر عناصر، بتضطر "تهز" الشجرة كلها. ده ممكن يبطأ الأداء، وخصوصًا لما الصفحات تبقى معقدة أكتر. كل ما زاد عدد الفروع (العناصر)، كل ما بقى الموضوع أصعب.
الحل مع React

React قدمت حل رائع للمشكلة دي عن طريق الـ Virtual DOM، وده نسخة خفيفة من الـ HTML DOM.
(a lightweight in-memory representation of the real DOM)
عشان بناءا عليها هنعمل reflect لل updated state
التعديلات بتتحط الأول في الـ Virtual DOM وبعدها React بتعمل تحديث للـ DOM الحقيقي بشكل فعال وسريع.
العملية دي اسمها Reconciliation، وبتخلي التحديثات تحصل بس في الأجزاء اللي محتاجة تحديث فعلي، وده بيحسن الأداء بشكل كبير.
إزاي الـ Virtual DOM بيشتغل
لما بتعمل Render لعناصر JSX في React،
الـ Virtual DOM بيتحدث محتاجين هنا نقف ونسأل سؤال مهم أوي بيتحدث كليا ولا ؟
React only updates the parts of the Virtual DOM that have changed. This is known as "incremental rendering" or "partial rendering".

، ده أسرع بكتير من التعامل المباشر مع الـ DOM الحقيقي. ده بيحصل لإن React بتعمل نسخة من الـ Virtual DOM قبل ما تعمل أي تحديثات، وبتقارن النسخة دي مع التحديثات باستخدام عملية اسمها Diffing أو ( Reconciliation) العملية دي بتحدد العناصر اللي حصل فيها تغيير فعلاً، وReact بتحدث بس العناصر دي في الـ DOM الحقيقي.
Under the Hood React’s Diffing Algorithm

الـ Diffing في React هي السر ورا التحديثات الفعالة للـ DOM. الAlgorithm دي بتقارن بين نسختين من الـ Virtual DOM وبتطبق أقل مجموعة من التغييرات اللي محتاجها عشان تزامنهم.
مثلاً، لو أنواع العناصر الأساسية (root elements) في الشجرتين مختلفة، React هتبني الشجرة كلها من جديد. يعني لو غيرت

<div>
<Tree/>
</div>
ل
<span>
<Tree/>
</span>
بما إن العناصر الأساسية (div وspan) مختلفة، React هتعيد بناء الtree كلها.
طب لو الحالة زي دي


<span id="span1" />
<span id="span2" />


في الحالة دي، React هتحدث بس الـ id من غير ما تلمس باقي العنصر.
React كمان بتحسن التحديثات على مستوى الChild Elements
<ul>
<li>Child1</li>
<li>Child2</li>
</ul>


<ul>
<li>Child1</li>
<li>Child2</li>
<li>Child3</li>
</ul>

React هتشوف Child3 كعنصر جديد وهتحدث القائمة بناءً عليه. لكن لو أضفت عنصر جديد في البداية، React ممكن تعيد بناء القائمة كلها. وهنا بييجي دور الـ Keys.
الـ Keys بتساعد React إنها تتبع العناصر اللي حصل فيها تغيير، اللي اتضافت، أو اللي اتشالت. لازم تكون الـ Keys مميزة بين العناصر الsiblings يعني ميتككرش وثابتة بين الـ renders.
واتكلمت عنها قبل كده بالتفصيل !
Manipulating the DOM with Refs
رغم إن React بتعمل تحسينات على تحديثات الـ DOM باستخدام الـ Virtual DOM، في سيناريوهات معينة ممكن تحتاج فيها تتعامل مباشرة مع عناصر الـ DOM، زي إنك تركز على input معين، تعمل scroll لعناصر معينة، أو تقيس أبعاد عنصر. هنا بيجي دور الـ useRef Hook. من خلال إنشاء ref وربطه بعنصر DOM عن طريق ال ref، تقدر تحصل على الوصول المباشر للـ DOM node.
الـ useRef Hook بيرجع object فيه خاصية current، اللي بتبقى في الأول null لكن بتتخصص لـ DOM node بعد ما يتعمل Render. ده بيسمح لك تستدعي دوال الـ DOM مباشرة على العنصر، وده بيزود التحكم في التفاعلات المحددة.

خلينا نعمل مثال ممتع عشان نشوف الكلام ده في التطبيق. هنعمل div بيغير لونه لما تضغط على زرار. بص ع الصورة
فهم خوارزمية الـ Diffing والـ Keys في React هيساعدك تعمل تطبيقات React أنعم وأسرع لو فهمته صح

ولما تحتاج تحكم دقيق، React بتوفرلك refs اللي تساعدك تتفاعل مباشرة مع الـ DOM.