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

الصفحات

 مقدمة في React Hooks ولماذا هي تجريد خاطئ


قبل أن أبدأ ، أود أن أعبر عن مدى امتناني لكل العمل الذي قام به فريق React على مر السنين. لقد أنشأوا إطارًا رائعًا كان من نواحٍ عديدة مقدمتي للويب الحديث. لقد مهدوا الطريق بالنسبة لي لتصديق الأفكار التي أنا على وشك تقديمها ولم أكن لأصل إلى هذه الاستنتاجات بدون براعتهم. في الفقرات التالية ، أود أن أتصفح خطوة بخطوة أوجه القصور التي لوحظت في الخطافات وأقترح واجهة برمجة تطبيقات بديلة تكون قادرة ، ولكن مع عدد أقل من التحذيرات. سأقول الآن أن واجهة برمجة التطبيقات البديلة هذه مطولة بعض الشيء ، لكنها أقل إهدارًا من الناحية الحسابية ، وأكثر دقة من الناحية المفاهيمية ، وهي حيادية للإطار
Before I get started, I'd like to express how grateful I am for all of the work that the React team has put in over the years. They've created an awesome framework that in many ways was my introduction to the modern web. They have paved the path for me to believe the ideas I'm about to present and I would not have arrived at these conclusions without their ingenuity.      In the following paragraphs, I would like to walk step by step through my observed shortcomings of hooks and propose an alternative API that is as capable, but with fewer caveats. I'll say right now that this alternative API is a bit verbose, but it is less computationally wasteful, more conceptually accurate, and it's framework agnostic

مشكلة الخطافات رقم 1: مرفقة أثناء العرض

Hooks Problem #1: Attached during render

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

As a general rule of design, I've found that we should always first try to disallow our users from making mistakes. Only if we're unable to prevent the user from making a mistake, should we then inform them of the mistake after they've made it.      For example, if allowing a user to enter a quantity in an input field, we could allow them to enter alphanumeric characters and then show them an error message if we find an alphabetic character in their input. However, we could provide better UX if we allowed them only to enter numeric characters into the field, which would eliminate the need to check whether they have included alphabetic characters.      React behaves quite similarly.      If we think about hooks conceptually, they are static through the lifetime of a component. By this I mean that once declared, we cannot remove them from a component or change their position in relation to other hooks. React uses lint rules and will throw errors to try to prevent developers from violating this detail of hooks.      In this sense, React allows the developer to make mistakes and then tries to warn the user of their mistakes afterward. To see what I mean, consider the following example.
const App = () => {
    const [countOnesetCountOne] = useState(0);
    if (countOne === 0) {
      const [countTwosetCountTwo] = useState(0);
    }
  
    return (
      <button
        onClick={() => {
          setCountOne((prev=> prev + 1);
        }}
      >
        Increment Count One: {countOne}
      </button>
    );
  };
  ينتج عن هذا خطأ في العرض الثاني عند زيادة العداد لأن المكون سيزيل خطاف useState الثاني
اقرأ المزيد

هل اعجبك الموضوع :

تعليقات