تطوير رد الفعل: 6 مسارات للنمو المهني

طوال الأشهر الستة الماضية ، كنت أراقب تطور مبرمجي رد الفعل الطموحين. خلال هذا الوقت ، اجتازوا مسارًا لا يصدق. سرعة تعلمهم ، وتعطشهم للمعرفة ، ورغبتهم في التميز - كل هذا ترك انطباعًا قويًا علي.



كيف فعلوا ذلك؟ كيف انتقلوا من أولئك الذين لا يستطيعون فتح العلاقات العامة دون مساعدة خارجية لأولئك الذين يلجأ إليهم الآخرون للمساعدة؟ ما الذي جعل الناس يطلبون النصيحة من الأشخاص الراغبين في تقديم المشورة للآخرين؟ كيف أصبح الطلاب معلمين؟ سألتهم هذه الأسئلة. إليكم ما ردوا عليه.

1. استخدم ESLint و TypeScript

JavaScript هي لغة برمجة مكتوبة بشكل فضفاض. باستخدام هذه اللغة ، يمكننا حل نفس المشكلة بطرق لا حصر لها. جافا سكريبت ليس لديها آليات مدمجة لحمايتنا من كتابة كود عربات التي تجرها الدواب أو التعليمات البرمجية ذات الأداء الضعيف. ولكن لحسن الحظ بالنسبة لنا ، يمكننا تحسين الوضع باللجوء إلى أداتين لتحليل الكود الثابت. هذه هي TypeScript و ESLint.



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



على سبيل المثال ، يمكنك تثبيت المكوّن الإضافي ESLinteslint-plugin-react-hooks... سيلاحظ هذا البرنامج المساعد المشكلة في الكود التالي ، والتي تبدو طبيعية تمامًا ، وستبلغنا أننا ننتهك إحدى قواعد استخدام الخطافات.

//    ,    
  if (userName !== '') {
    useEffect(function persistForm() {
      localStorage.setItem('formData', userName);
    });
  }

يسمح لك TypeScript باستخدام نظام نوع ثابت لالتقاط الأخطاء ذات الصلة. عند استخدام TypeScript ، يمكنك استخدام تلميح أداة التحسس الذكي الذي يجعل العمل مع المكونات والمكتبات المختلفة أسرع وأسهل. توفر تلميحات الأدوات التي تظهر أثناء كتابة التعليمات البرمجية معلومات حول الآليات الداخلية للمكونات والمكتبات. هذا يسرع إعادة الهيكلة ويشجع اصطلاحات الترميز مثل الأدوية الجنسية.



لا يصبح الشخص الجيد في TypeScript مبرمج JavaScript أفضل فحسب ، بل يبدأ في نهاية المطاف في كتابة كود React أفضل.

2. تعرف على خطافات رد الفعل

تفاعلت خطافات React على عالم تطوير React منذ تقديمها في فبراير 2019. على الرغم من أن فريق React يقول أنه لا يجب إعادة صياغة الرمز القديم بترجمته إلى خطافات ، إلا أن الخطافات موجودة حرفياً في كل مكان هذه الأيام.



إذا كنت ترغب في المضي قدمًا في مجال تطوير التفاعل ، فإن أفضل وقت يمكنك القيام به هو تعلم الخطافات بعمق حتى تتمكن من فهمها بالكامل.



هل تحتاج إلى نوع من الآثار الجانبية؟ إذا كان الأمر كذلك ، فإن الخطاف useEffectهو أفضل صديق لك. هل تحتاج إلى مراقبة حالة المكون وإعادة عرضه عندما تتغير الحالة؟ نلقي نظرة علىuseState... هل تحتاج إلى تخزين وتحديث بعض القيم بين العروض ، ولكن عندما تتغير هذه القيم ، لا يتم عرضها؟ أو ربما تحتاج إلى معرفة ارتفاع أو عرض عناصر DOM؟ ثم صديقك هذا useRef.



على سبيل المثال ، دعنا نلقي نظرة على أبسط حالات الاستخدام useEffect. افترض أننا نريد الترتيب لعنوان الصفحة لتحديث (في شكل تأثير جانبي) عند النقر على زر. يمكنك محاولة حل هذه المشكلة كما يلي:

useEffect(() => {
  document.title = `You clicked ${count} times`;
}); //    

من السهل تحسين هذا الخطاف من خلال جعله لا يعمل على كل عرض ، ولكن فقط عندما يتغير المتغير count. يتم ذلك عن طريق تضمين countالتبعيات في الصفيف:

useEffect(() => {
  document.title = `You clicked ${count} times`;
}, [count]); //      count

يجب أن تكون مرتاحًا لاستخدام الخطافات الأكثر شيوعًا وإنشاء الخطافات الخاصة بك. يجب أن تكون أيضًا على دراية جيدة بالاستخدام العقلاني للخطافات. على سبيل المثال ، يبدو أن معرفة وقت استخدام الخطاطيف useEffectيؤدي إلى إعادة العرض وعندما لا يحدث ذلك.

3. لا تقم بتحسين التعليمات البرمجية الخاصة بك في وقت مبكر للغاية

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



دعونا نلقي نظرة على مكون بسيط يأخذ مجموعة من معلومات الحلويات مثل props. يقوم المكون بتصفية الصفيف ويعرض قائمة بأسماء الشوكولاتة (خصائصها typeتساوي قيمة سلسلة chocolate).



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

const Chocolate = (props) => {
  const chocolates = useMemo(
    () => props.candies.filter((candy) => candy.type === "chocolate"),
    [props.candies]
  );
  return (
    <>
      {chocolates.map((item) => (
        <p>{item.name}</p>
      ))}
    </>
  );
};

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



أوصي بتأجيل بدء عمل التحسين حتى تحصل على قياس أداء التطبيق الذي يشير بوضوح إلى وجود مشكلة.



يجب عدم استخدامه في كل مكان useCallbackو useMemoفقط لأنك قرأت مؤخرا حول لهم في مكان ما. لا تقم بتحسين كل شيء. من الأفضل انتظار ظهور المشكلة ، ثم حلها. لا تحل المشاكل غير الموجودة.

4. معرفة متى يتم إنشاء مكونات جديدة

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



لتحقيق ذلك ، تحتاج إلى السعي للحفاظ على الفصل بين مكونات العرض والمكونات التي تنفذ نوعًا من المنطق. في السابق ، كان الأسلوب الشائع هو تقسيم المكونات إلى "حاويات" ، وفي الواقع ، "مكونات". لكن هذا النهج فقد أهميته تدريجياً.



دعنا نلقي نظرة على مكون يحمّل قائمة بالعناصر من مكان ما ويعرضها على الصفحة. لاحظ أنه يتم تنفيذ كل من هذه المهام في نفس المكون.

const ListItems = () => {
  const items = React.useState([]);
  React.useEffect(() => {
    async function fetchItems() {
      await fetched = fetchItems();
      setItems(fetched);
    }
  });
return (
    <>
      {items.map((item) => (
        <div className="item-container">
          <img src={item.img} />
          <div className="name">{item.name}</div>
          <div className="author">{item.author}</div>
        </div>
      ))}
    </>
  );
};

قد يكون من المغري اتخاذ مسار "الحاوية". بعد هذا الطموح ، سنأتي لإنشاء مكونين:

const ListContainer = () => {
  const items = React.useState([]);
  React.useEffect(() => {
    async function fetchItems() {
      await fetched = fetchItems();
      setItems(fetched);
    }
  });
return <List items={items} />;
};
const List = (props) => {
  return (
    <>
      {props.items.map((item) => (
        <div className="item-container">
          <img src={item.img} />
          <div className="name">{item.name}</div>
          <div className="author">{item.author}</div>
        </div>
      ))}
    </>
  );
};

ولكن في مثل هذه الحالة ، يجب أن تتصرف بشكل مختلف. وبالتحديد ، تحتاج إلى تجريد تلك الأجزاء من المكون التي تلعب دور عرض بحت. ستكون النتيجة مكونين - مكون List(قائمة) ومكون Item(عنصر):

const List = () => {
  const items = React.useState([]);
  React.useEffect(() => {
    async function fetchItems() {
      await fetched = fetchItems();
      setItems(fetched);
    }
  });
return (
    <>
      {items.map((item) => (
        <Item item={item} />
      ))}
    </>
  );
};
const Item = ({ item }) => {
  return (
    <div className="item-container">
      <img src={item.img} />
      <div className="name">{item.name}</div>
      <div className="author">{item.author}</div>
    </div>
  );
};

5. انتبه بشكل خاص للاختبار

مستوى الكفاءة في تقنيات الاختبار هو ما يفصل الصغار عن كبار السن. إذا لم تكن على دراية باختبار تطبيقات التفاعل ، فيمكنك العثور على العديد من المواد حولها ودراستها.



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



على سبيل المثال ، إليك مقالتي حول الدورة الكاملة لاختبار تطبيق مكدس كامل قائم على رد الفعل.

6. التمييز بين المواقف التي يجب أن تستخدم فيها الدولة المحلية والعالمية

هنا سنتطرق إلى موضوع إدارة حالة التطبيق في React. هناك أطنان من التقنيات لحل هذه المشكلة. على سبيل المثال ، هذا هو redux و mobx و recoil و API contextوالمزيد. ليس من السهل سردها.



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

• هل نحتاج إلى بعض المكونات غير المرتبطة مباشرة بمكوننا حتى نتمكن من العمل مع بياناته؟ على سبيل المثال ، قد يظهر اسم المستخدم في شريط التنقل وفي شاشة الترحيب.
• هل يجب أن تستمر البيانات عند التنقل بين صفحات التطبيق؟
• هل تستخدم العديد من المكونات نفس البيانات؟

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

النتيجة

الآن أنت تعرف أي المسارات يجب أن تتخذ من أجل النمو بشكل احترافي في مجال تطوير التفاعل.



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



ما هي مسارات النمو المهني لمبرمجي التفاعلات التي تعرفها؟