القائمة الرئيسية

الصفحات

خطأ: تم عرض خطافات أقل من المتوقع. قد يكون هذا بسبب بيان إرجاع مبكر عرضي

 خطأ: تم عرض خطافات أقل من المتوقع. قد يكون هذا بسبب بيان إرجاع مبكر عرضي

Error: Rendered fewer hooks than expected. This may be caused by an accidental early return statement.



يُحدِّد موضع الخطافات أثناء تصيير المكوِّن الأول مكان وجود الخطافات بواسطة React في كل تصيير لاحق. بالنظر إلى أن الخطافات ثابتة طوال عمر المكون ، ألن يكون من المنطقي بالنسبة لنا أن نعلن عنها في بناء المكون بدلاً من مرحلة العرض؟ إذا قمنا بإرفاق خطافات أثناء بناء أحد المكونات ، فلن نحتاج بعد الآن إلى القلق بشأن تطبيق قواعد الخطافات ، لأنه لن يُمنح الخطاف أبدًا مرة أخرى خلال عمر المكون فرصة لتغيير المواضع أو إزالته. لسوء الحظ ، لم يتم إعطاء مكونات الوظيفة أي مفهوم للمنشئ ، لكن دعنا نتظاهر بذلك. أتخيل أنه سيبدو مثل ما يلي
The placement of our hooks during a component's first render determines where the hooks must be found by React on every subsequent render.      Given that hooks are static through the lifetime of a component, wouldn't it make more sense for us to declare them on component construction as opposed to during the render phase? If we attach hooks during the construction of a component, we no longer need to worry about enforcing the rules of hooks, because never again during the lifetime of a component would a hook be given the chance to change positions or be removed.      Unfortunately, function components were given no concept of a constructor, but let's pretend that they were. I imagine that it would look something like the following.
const App = createComponent(() => {
    // This is a constructor function that only runs once 
    // per component instance.
    
    // We would declare our hooks in the constructor.
    const [countsetCount] = useState(0)
    
    // The constructor function returns a render function.
    return (propsstate=> (
      <div>
        {/*...*/}
      </div>
    );
  });
  
  
من خلال إرفاق الخطافات الخاصة بنا بالمكون في المُنشئ ، لا داعي للقلق بشأن تغييرها أثناء إعادة التصيير. إذا كنت تفكر في هذه المرحلة ، "لا يمكنك فقط نقل الخطافات إلى المُنشئ ، بل يجب تشغيلها على كل تصيير للحصول على أحدث قيمة" ، فأنت محق تمامًا! لا يمكننا نقل الخطافات من وظيفة التصيير لأننا سنكسرها. لهذا السبب يتعين علينا استبدالها بشيء آخر. لكن أولاً ، المشكلة الرئيسية الثانية للخطافات
By attaching our hooks to the component in a constructor, we wouldn't have to worry about them changing during re-renders.      If you're thinking at this point, "you can't just move hooks to a constructor, they need to run on every render to grab the latest value", then you're totally correct!      We can't just move hooks out of the render function because we will break them. That's why we'll have to replace them with something else. But first, the second major problem of hooks.

مشكلة الخطافات رقم 2: تغييرات الحالة المفترضة

Hooks Problem #2: Assumed state changes

نعلم أنه في أي وقت تتغير حالة المكون ، ستعيد React تصيير هذا المكون. يصبح هذا مشكلة عندما تصبح مكوناتنا منتفخة بالكثير من الحالة والمنطق. لنفترض أن لدينا مكونًا يحتوي على جزأين غير مرتبطين بالحالة ، A و B. إذا قمنا بتحديث الحالة A ، فسيتم إعادة عرض المكون بسبب تغيير الحالة. على الرغم من أن B لم يتغير ، فإن أي منطق يعتمد عليه سيعاد تشغيله ما لم نلف هذا المنطق بـ useMemo
We know that any time a component's state changes, React will re-render that component. This becomes problematic when our components become bloated with lots of state and logic. Say we have a component that has two unrelated pieces of state, A and B. If we update state A, our component re-renders due to the state change. Even though B has not changed, any logic that depends on it will re-run unless we wrap that logic with useMemo

البرمجة التفاعلية

Reactive Programming

كانت البرمجة التفاعلية موجودة منذ فترة طويلة ولكنها أصبحت مؤخرًا نموذجًا شائعًا للبرمجة بين أطر عمل واجهة المستخدم. الفكرة الأساسية للبرمجة التفاعلية هي أن المتغيرات يمكن ملاحظتها وكلما تغيرت قيمة ما يمكن ملاحظته ، سيتم إخطار المراقبين بهذا التغيير عبر وظيفة رد الاتصال
Reactive programming has been around for a long time but has recently become a popular programming paradigm among UI frameworks. The core idea of reactive programming is that variables are observable and whenever an observable's value changes, observers will be notified of this change via a callback function.
const count$ = observable(5)

observe(count$, (count=> {
  console.log(count)
})

count$.set(6)
count$.set(7)

// Output:
// 6
// 7

لاحظ كيف يتم تمرير وظيفة رد الاتصال لمراقبة التنفيذ في أي وقت نقوم فيه بتغيير قيمة العد $ التي يمكن ملاحظتها. قد تتساءل عن $ في نهاية العد $. يُعرف هذا بالتدوين الفنلندي ويشير ببساطة إلى أن المتغير يحمل رمزًا يمكن ملاحظته. في البرمجة التفاعلية هناك أيضًا مفهوم للحساب
Note how the callback function passed to observe executes any time that we change the count$ observable's value. You might be wondering about the $ on the end of count$. This is known as Finnish Notation and simply indicates that the variable holds an observable. In reactive programming there is also a concept of computed
const count$ = observable(5)
const doubledCount$ = derived(count$, (count=> count * 2)

observe(doubledCount$, (doubledCount=> {
  console.log(doubledCount)
})

count$.set(6)
count$.set(7)

// Output:
// 12
// 14
هذا مشابه لمثالنا السابق فيما عدا الآن سنقوم بتسجيل عدد مضاعف.
This is similar to our previous example except now we will log a doubled count.
هل اعجبك الموضوع :

تعليقات