كتابة واجهة برمجة تطبيقات لمكونات التفاعل ، الجزء 4: احذر من Apropacalypse

كتابة واجهة برمجة تطبيقات لمكونات React ، الجزء 1: لا تقم بإنشاء الدعائم المتعارضة

كتابة واجهة برمجة تطبيقات لمكونات التفاعل ، الجزء 2: إعطاء أسماء للسلوك ، وليس التفاعل

كتابة واجهة برمجة تطبيقات لمكونات React ، الجزء 3: ترتيب الدعائم هو المهم

كتابة واجهة برمجة تطبيقات لمكونات التفاعل ، الجزء 4: احذر من Apropacalypse!

كتابة واجهة برمجة تطبيقات لمكونات التفاعل ، الجزء 5: مجرد استخدام التكوين

نكتب واجهة برمجة التطبيقات لمكونات React ، الجزء 6: نخلق التواصل بين المكونات

دعونا نتحدث عن المكون Avatar .

 <Avatar image="simons-cat.png" /> 

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

دعنا نضيف size الدعامة (دعامة للأحجام).

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

 <Avatar size="xsmall" image="simons-cat.png" /> <Avatar size="small" image="simons-cat.png" /> <Avatar size="medium" image="simons-cat.png" /> <Avatar size="large" image="simons-cat.png" /> <Avatar size="xlarge" image="simons-cat.png" /> 

في الكون ، لا يزال لدينا تجسدات للتطبيقات. نريدهم أن يبدووا مختلفين قليلاً - مربع مستدير بدلاً من دائرة.

يتمثل جزء من إنشاء واجهة برمجة تطبيقات جيدة في إعطاء المطورين القدرة على التفكير في البيانات بدلاً من التصميم - يجب أن يكون التصميم بالفعل في المكون

يمكننا إضافة دعامة أخرى تميز بين نوعين من الصور الرمزية. دعامة واحدة صغيرة لا يمكن أن تؤذي ، أليس كذلك؟

 <Avatar type="user" image="simons-cat.png" /> <Avatar type="app" image="firebase.png" /> 

تبدو جيدة ، أليس كذلك؟

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

 <Avatar type="app" size="xsmall" image="firebase.png" /> <Avatar type="app" size="small" image="firebase.png" /> <Avatar type="app" size="medium" image="firebase.png" /> <Avatar type="app" size="large" image="firebase.png" /> <Avatar type="app" size="xlarge" image="firebase.png" /> 

دعنا نتحدث عن كيفية استخدام المطور لهذا المكون بالفعل في تطبيقه. ربما تأتي معلومات المستخدم من واجهة برمجة التطبيقات (API) وتحتوي على رابط الصورة الرمزية. سيقوم المطور بتمرير هذه المعلومات إلى مكون Avatar باستخدام الدعائم.

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

 <Avatar type="user" image={props.user.avatar} /> <Avatar type="user" image={missing} /> <Avatar type="app" image={props.app.logo} /> <Avatar type="app" image={missing} /> 

يتم تضمين الصورة الافتراضية بالفعل في المكون ، لذلك لا نطلب من المطور صورة الصورة الافتراضية.

هذا تراجع جيد ، لكننا نستطيع فعل المزيد.

يمكننا عرض الأحرف الأولى من اسم المستخدم بخلفية فريدة من نوعها (جعل Gmail هذا القالب شائعًا ، مما يساعد على التمييز بسرعة بين الأشخاص)

 <Avatar type="user" image={props.user.avatar} /> <Avatar type="user" image={missing} /> <Avatar type="user" initials={props.user.intials} image={missing} /> <Avatar type="app" image={props.app.logo} /> <Avatar type="app" image={missing} /> <Avatar type="app" icon={props.app.type} image={missing} /> 

دعونا نلقي نظرة على جميع الدعائم التي يدعمها مكوننا:

لقد بدأنا بمكون تجسيد بسيط ، لكنه الآن يدعم كل هذه الدعائم والسلوك!

عندما ترى مكونًا يدعم العديد من الدعائم ، فمن المحتمل أنه يحاول القيام بأشياء كثيرة. لقد أنشأت للتو Apropcalypse .

صاغ هذا المفهوم من قبل جين كريتون .

نحن نحاول جعل مكون Avatar يعمل للمستخدمين والتطبيقات ، وفي الوقت نفسه نعمل بأحجام مختلفة وخيارات مختلفة لسلوك الإرجاع.

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

حسنًا ، كيف نتعامل مع هذا؟ إنشاء عنصرين مختلفين.

مجلس:

لا تخف من إنشاء مكون جديد بدلاً من إضافة الدعائم ومنطق إضافي لمكون موجود.

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

 <UserAvatar size="large" image="simons-cat.png" /> <UserAvatar size="large" image="" /> <UserAvatar size="large" fallback="LA" image="" /> <AppAvatar image="firebase.png" /> <AppAvatar image="" /> <AppAvatar fallback="database" image="" /> 

هناك العديد من الأشياء الجديرة بالملاحظة في واجهة برمجة التطبيقات هذه:

1. تمكنا من إزالة الميزات غير الضرورية ، مثل size ، في AppAvatar .
2. قللنا حجم واجهة برمجة التطبيقات الخاصة بنا من خلال الحفاظ على نفس اسم الرجوع (الاحتياطية) للمكونين.
   تذكر نصيحة رقم 2 في هذه السلسلة ؟ نريد للمطورين أن يفكروا في السلوك ( fallback ) ، وليس حول التفاعل / التنفيذ (الأحرف الأولى أو الرموز) . هذا يساعد المطورين على تعلم واجهات برمجة التطبيقات وطرق استخدام المكونات بشكل أسرع.
3. يمكننا أيضا تجنب أي الدعائم المتضاربة .
4. أخيرا ، قللنا عدد الدعائم. انظر إلى طاولة الدعائم ، لقد أصبح أكثر نظافة:

userAvatar:

AppAvatar:

الشيء الوحيد الذي أزعجني قليلاً في واجهة برمجة التطبيقات هذه هو أنه على الرغم من أن كلا المكونين لهما نفس الاسم والنوع للرجوع fallback: string ( fallback: string احتياطية مع string حروف سلسلة) ، واحد منهم يأخذ حرفين في الأحرف الأولى ، بينما وقت آخر هو اسم الرمز.

دعنا نتحدث عن التنفيذ. من المغري إنشاء مكون BaseAvatar يستخدم كل من UserAvatar و AppAvatar ، بينما سيتم حظر بعض الدعائم.

 function UserAvatar(props) { return ( <BaseAvatar image={props.image} type="user" initials={props.fallback} /> ) } render(<UserAvatar fallback="LA" />) 

وهذه ليست فكرة سيئة على الإطلاق. ولكن من الصعب للغاية في البداية التنبؤ بما قد نحتاجه. نحن نتوقع بشكل سيء المطالب المستقبلية.

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

الازدواجية أفضل من التجريد غير الصحيح - ساندي ميتز

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

لمزيد من الدراسة:

1. محاضرة لجين كريتون ، حيث تتحدث عن Apropacalips
2. ساندي ميتز محاضرة عن التكرارات والتجريدات