diff --git a/src/content/learn/choosing-the-state-structure.md b/src/content/learn/choosing-the-state-structure.md index 5be2b4d34..d8fd6b597 100644 --- a/src/content/learn/choosing-the-state-structure.md +++ b/src/content/learn/choosing-the-state-structure.md @@ -1,53 +1,52 @@ --- -title: Choosing the State Structure +title: اختيار هيكلة الحالة --- - -Structuring state well can make a difference between a component that is pleasant to modify and debug, and one that is a constant source of bugs. Here are some tips you should consider when structuring state. - +إن هيكلة للحالة (state) بشكل صحيح هي أحد العناصر الأساسية التي يمكن أن تجعل المكون (component) سهل التعديل والتصحيح عند مواجهة الأخطاء، أو بالعكس، قد تكون مصدراً للتعقيد والمشاكل في مشروعك. لذا، إليك بعض النصائح التي يمكنك اتباعها لهيكلة الحالات (state) بشكل فعّال: -* When to use a single vs multiple state variables -* What to avoid when organizing state -* How to fix common issues with the state structure +* متى تستخدم متغير حالة واحد مقابل عدة متغيرات حالة +* ما يجب تجنبه عند تنظيم الحالة +* كيفية إصلاح المشكلات الشائعة في هيكلة الحالة -## Principles for structuring state {/*principles-for-structuring-state*/} +## مبادئ هيلكة الحالات {/*principles-for-structuring-state*/} -When you write a component that holds some state, you'll have to make choices about how many state variables to use and what the shape of their data should be. While it's possible to write correct programs even with a suboptimal state structure, there are a few principles that can guide you to make better choices: +عندما تقوم بكتابة مكون يحتوي على حالة، ستحتاج إلى اتخاذ قرارات بشأن عدد متغيرات الحالة التي ستستخدمها وشكل البيانات التي تحتويها. بينما من الممكن كتابة برامج صحيحة حتى مع هيكلة حالة غير مثلى، هناك بعض المبادئ التي يمكن أن تساعدك في اتخاذ قرارات أفضل: -1. **Group related state.** If you always update two or more state variables at the same time, consider merging them into a single state variable. -2. **Avoid contradictions in state.** When the state is structured in a way that several pieces of state may contradict and "disagree" with each other, you leave room for mistakes. Try to avoid this. -3. **Avoid redundant state.** If you can calculate some information from the component's props or its existing state variables during rendering, you should not put that information into that component's state. -4. **Avoid duplication in state.** When the same data is duplicated between multiple state variables, or within nested objects, it is difficult to keep them in sync. Reduce duplication when you can. -5. **Avoid deeply nested state.** Deeply hierarchical state is not very convenient to update. When possible, prefer to structure state in a flat way. +1. **دمج الحالات المتشابهة** اذا كنت تحدث اثنين او اكثر من الحالات في آن واحدة. فكر في دمجهم الى حالة واحدة +2. **تجنب تناقضات في الحالة.** عندما تكون الحالة مهيكلة بطريقة يكون فيها اجزاء من الحالة متناقضة, فهذا يفتح مجال للأخطاء. حاول تجنبها +3. **تجنب الحالة الزائدة.** اذا كنت تعالج معلومة ما عن طريق خصائص (prop) او الحالة موجودة مسبقا. فيجب عليك تفادي وضع تلك المعلومة في حالات ذلك المكون +4. **تجنب تكرار الحالات.** عندما تكون نفس البيانات مكررة بين عدة حالات، أو ضمن كائنات متداخلة، يصبح من الصعب الحفاظ على تزامنها. تفادى التكرار قدر الإمكان. +5. **تجنب الحالة المتداخلة بعمق.** تجنب الحالة المتداخلة بعمق. الحالة ذات الهيكلية العميقة ليست مناسبة للتحديث. يُفضّل هيكلة الحالة بطريقة مسطحة. -The goal behind these principles is to *make state easy to update without introducing mistakes*. Removing redundant and duplicate data from state helps ensure that all its pieces stay in sync. This is similar to how a database engineer might want to ["normalize" the database structure](https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description) to reduce the chance of bugs. To paraphrase Albert Einstein, **"Make your state as simple as it can be--but no simpler."** +الهدف من هذه المبادئ هو *تسهيل تحديث الحالة دون فتح مجال للأخطاء*. من خلال إزالة البيانات الزائدة والمتكررة من الحالة، نضمن تماسك جميع أجزائها. هذا مماثل لما قد يفعله مهندس قاعدة المعلومات ["تطبيع" لهيكلة قاعدة المعلومات](https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description) لتقليل من الأخطاء المحتملة. كما قال أينشتاين, **"اجعل حالتك بسيطة بقدر الإمكان—لكن لا تجعلها أبسط من ذلك."** + -Now let's see how these principles apply in action. +لنرى الآن كيف يمكن تطبيق هذه المبادئ عملياً. -## Group related state {/*group-related-state*/} +## جمع الحالة المتعلقة {/*group-related-state*/} -You might sometimes be unsure between using a single or multiple state variables. +قد تكون أحياناً غير متأكد مما إذا كنت ينبغي أن تستخدم متغير حالة واحداً أم عدة متغيرات حالة. -Should you do this? +هل يجب عليك فعل هذا؟ ```js const [x, setX] = useState(0); const [y, setY] = useState(0); ``` -Or this? +او هذا؟ ```js const [position, setPosition] = useState({ x: 0, y: 0 }); ``` -Technically, you can use either of these approaches. But **if some two state variables always change together, it might be a good idea to unify them into a single state variable.** Then you won't forget to always keep them in sync, like in this example where moving the cursor updates both coordinates of the red dot: +من الناحية التقنية، يمكنك استخدام أي من هاتين الطريقتين. ولكن **إذا كان هناك متغيران من الحالة يتغيران دائماً معاً، فقد يكون من الجيد دمجهما في متغير حالة واحد.** بذلك، لن تنسى دائماً الحفاظ على تزامنهما، كما في هذا المثال حيث يؤدي تحريك المؤشر إلى تحديث إحداثيات النقطة الحمراء: @@ -61,7 +60,7 @@ export default function MovingDot() { }); return (
{ + onPointerMove={e => { setPosition({ x: e.clientX, y: e.clientY @@ -93,17 +92,18 @@ body { margin: 0; padding: 0; height: 250px; } -Another case where you'll group data into an object or an array is when you don't know how many pieces of state you'll need. For example, it's helpful when you have a form where the user can add custom fields. +في حالة أخرى، قد تحتاج إلى جمع بيانات الحالة في كائن أو مصفوفة عندما لا تعرف عدد أجزاء الحالة التي ستحتاجها. على سبيل المثال، ستكون هذه الطريقة مفيدة عندما يكون لديك نموذج يتيح للمستخدم إضافة حقول مخصصة -If your state variable is an object, remember that [you can't update only one field in it](/learn/updating-objects-in-state) without explicitly copying the other fields. For example, you can't do `setPosition({ x: 100 })` in the above example because it would not have the `y` property at all! Instead, if you wanted to set `x` alone, you would either do `setPosition({ ...position, x: 100 })`, or split them into two state variables and do `setX(100)`. +إذا كان متغير الحالة الخاص بك هو كائن، فتذكر أنه [لا يمكنك تحديث حقل واحد فقط فيه](/learn/updating-objects-in-state) دون نسخ الحقول الأخرى بشكل صريح. على سبيل المثال، لا يمكنك استخدام `setPosition({ x: 100 })` في المثال أعلاه لأنه لن يحتوي على خاصية `y` على الإطلاق! بدلاً من ذلك، إذا كنت ترغب في تعيين `x` فقط، يمكنك إما استخدام +`setPosition({ ...position, x: 100 })`، أو تقسيمها إلى متغيرين للحالة واستخدام `setX(100)`. -## Avoid contradictions in state {/*avoid-contradictions-in-state*/} +## تجنب التناقضات في حالات {/*avoid-contradictions-in-state*/} -Here is a hotel feedback form with `isSending` and `isSent` state variables: +هنا نموذج تقييم للفندق يحتوي على متغيري حالة `isSending` و `isSent`: @@ -124,12 +124,12 @@ export default function FeedbackForm() { } if (isSent) { - return

Thanks for feedback!

+ return

شكرًا لتقديم الملاحظات!

} return (
-

How was your stay at The Prancing Pony?

+

كيف كانت إقامتك في فندق The Prancing Pony؟