۸ قدم برای حرفه‌ایی شدن در React (قسمت سوم)

در قسمت اول درباره ESLint, WebPack و Babel صحبت کردیم و دیدیم که با یه تغییر کوچیک داخل کانفیگ ESLint چقدر میشه تمیز و بهینه تر کد نویسی کرد.
تو قسمت دوم ویژگی‌های پلاگین transform-class-properties و تکنیک Code Splitting را مورد بررسی قرار دادیم.
و رسیدیم به قسمت هیجان انگیز Design Patterns 🙂
و البته بیشتر درباره Higher Order Components


شاید بارها و بارها براتون اتفاق افتاده باشه که یک کد رو بخواهید به طور منظم بین تمام کامپوننت‌ها باز نویسی کنید ؟
خب شاید تعریفش یکم گیج کننده باشه ولی تا آخر این مقاله کامل متوجه HOC و اهمیت اون داخل برنامه‌های React می‌شید.

HOC یک تکنیک هستش که شما یک Component رو به یک فانکشن پاس میدید و یک Component جدید می‌گیرید 🙂

قطعه کد بالا رو در نظر بگیرید. یک کامپوننت ساده که اطلاعات کاربر رو از سرور میگیره و داخل صفحه قرار میده. اگر دقت کرده باشید متد render یکم شلوغ شده و داخل WillMount داریم AJAX می‌زنیم …

میشه اینکارو راحت‌تر کرد و کامپوننت‌های ساده‌تری داشت.
مثلا: یک کامپوننت برای دریافت اطلاعات از سرور و یک کامپوننت برای مدیریت وضعیت دریافت اطلاعات از سرور.

کامپوننت دریافت اطلاعات از سرور

اصل مطلب اینکه یک متدی به نام fetchData یک رشته به عنوان url و یک کامپوننت به عنوان پارامتر دوم دریافت می‌کنه. اطلاعات رو از سرور می‌گیره و به کامپوننتی که پاس دادیم تقدیم می‌کنه

این کامپوننت یا همون HOC خودمون اطلاعات رو از HOC قبلی میگیره یکسری شرط رو بررسی می‌کنه و به به کامپوننت اصلی پاس میده.
متغیر displayName برای debuging و اینکه اگر خطایی در کامپوننت به وجود اومد متوجه بشیم در کدوم قسمت این خطا بوده.
مثلا اگر ۳،۴ بار این HOC رو در DOM به کار برده باشیم و LoadingHOC خطا بده شما داخل کنسول می‌بینید که Error نوشته شده مربوط LoadingHOC هست ولی کدوم LoadingHOC. برای کامپوننت Profile, Shop یا ‌Basket ؟
و اینجاست که displayName باعث میشه داخل Console شما بجای پیغام خطای LoadingHOC خطای LoadingHOC(نام Component Wrap شده رو دارید)

Error in LoadingHOC(Basket)

و در آخر برای استفاده از HOC کافیه که:

الان یک کامپوننت شلوغ به ۳ کامپوننت سبک و خوانا تبدیل شد که هر کدوم state خودشون رو دارن و جالبترین قسمت اینکه این کامپوننت ها reusable هستن شاید لازم باشه اطلاعات رو بجای ajax از فایل بخونید مشکلی نیست فقط کافیه props ها رو پاس بدین 🙂 یا شاید چند جا لازم باشه اطلاعات رو از سرور دریافت کنید نیازی به باز نویسی نیست
اینجاست که react بیشتر از یک کتابخونه JS عمل می‌کنه و به شما یک طرز فکر رو القا می‌کنه، شما باید همه چیز رو از بالا و با ذهنی باز نگاه کنید. تمیز کد بزنید و کامپوننتهاتونو بدون محدودیت همه جا استفاده کنید.


انتقال اطلاعات بین کامپوننت‌ها

کامپوننت بالا رو در نظر بگیرید.
از کامپوننت پدر A به کامپوننت فرزند B یک prop به نام name پاس داده شد، و فرضاً B اون prop رو چاپ می‌کنه.

خب سادس همه خوشحالن و هیچ مشکلی نداره اما مشکل زمانی به وجود میاد که:
۱. اگر بخوایم از A به H یا G مقادیر رو ارسال کنیم چه روندی باید طی بشه

می بینید که چه‌قدر کد تکراری باید نوشته بشه و تغییر مقدار یک prop باعث میشه مجددا Component ها نیاز به re-render داشته باشن و کلی از performance از دست میره و کد اصلا خوانا نیست و علاوه بر همه اینا کامپوننت ها re-usable نیستن

۲. اگر لازم باشه از فرزند به پدر اطلاعات منتقل بشه باید کلی کثیف کاری دیگه کینم و اگر همین روند رو پیش بگیریم اسپاگتی داریم با طعم react

این مثال برای ۲ کامپوننت ساده هستش شما در نظر بگیرید بجای B باید F رو داشته باشیم و ۴ متد برای ۴ state مختلف

اینجاست که نیاز به redux, context, mobx , … احساس شد.
این کتابخونه ها و object ها اطلاعات رو داخل یک فایل یا قسمتی از حافظه نگه‌داری می‌کنن و وقتی که اطلاعات تغییر کرد کامپوننت های متصل شده رو re-render می‌کنن، در اصل همون state رو در خارج از component نگه داری می‌کنن …

در مقالات بعدی در رابطه با پیاده سازی Redux و Context Api React 16 بیشتر صحبت خواهیم کرد


ادامه مطالب رو سعی می کنم تا چند روز آینده در قالب مقاله دیگه‌ایی تکمیل کنم و لینکش رو همینجا قرار بدم
تا اون موقع این چندتا لینک رو مطالعه کنید:

https://medium.com/@franleplant/react-higher-order-components-in-depth-cf9032ee6c3e

https://redux.js.org/basics/usage-with-react

https://hackernoon.com/how-to-use-the-new-react-context-api-fce011e7d87

https://github.com/acdlite/recompose

خوشحال میشم بدونم این مقاله مفید واقع شده یا نه! و آیا شما کاربردی بودن HOC ها رو درک کردید ؟

نوشته ۸ قدم برای حرفه‌ایی شدن در React (قسمت سوم) اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

جوری کد بنویس که بشه خوند…!

همیشه یکی از بزرگ‌ترین مشکلات در برنامه‌نویسی تیمی و گروهی، ناخوانا یا نامفهوم بودن کدهاست. چون معمولا استایل کدزنی ما با هم فرق می‌کنه، مثلا یکی تب میزنه یکی اسپیس. یا در اکثر مواقع، ما نمی‌تونیم کدهای هم‌دیگه رو بخونیم و بفهمیم و درک کنیم. البته همیشه نوشتن کد از خوندنش راحت‌تره و این از اول بوده؛ چون منطقاً فکر کردن از خوندن فکر دیگران راحت‌تره، نیست؟

یکی‌کردن استایل‌ها

تو این دست از مشکلات، ادیتورها به‌کمکمون میان. مثلا همون قضیه تب و اسپیس که گفتم رو میشه با یه فایل .editorconfig حل کرد! ادیتورکانفیگ یه فایل کوچولو و جمع‌وجوره که اکثر ادیتورا اگه اینو توی فایلاتون پیدا کنن، بهش عمل می‌کنن و از استایل اون پیروی می‌کنن. اکثر ادیتورا ساپورتش می‌کنن؛ اگر هم نکنن، پلاگینش قطعاً پیدا میشه. این یه مثال از ادیتورکانفیگ:

به‌همین سادگی، ما یه استایل واحد داریم که همه ازش پیروی می‌کنن!

اهمیت کامنت‌ها

شاید کامنت‌ها به‌صورت تئوریک بی‌اهمیت باشن چون کامپایلر یا موتور یا … اونا رو به‌حساب نمیاره؛ اما ما کامپایلر نیستیم. کامنت‌ها می‌تونن درواقع نقش داکیومنشن داشته‌باشن.
کد زیر رو فرض کنید:

این کد شاید برای من که نوشتمش، قابل‌فهم باشه؛ اما برای کسی که شاید سطح پایین‌تری داشته‌باشه یکم مبهمه؛ هرچند من سعی کردم خیلی مرتب بنویسم. مثلا طرف مقابل ممکنه بگه‌:

  • خب، این قراره چیکار کنه؟ من سردرنمیارم.
  • الان چه آرگومنتی باید بهش بدم؟
  • چی قراره بهم برگردونه؟

خب، باید بهش حق بدیم. اتکا به خود کد برای قابل‌فهم بودن کافی نیست، باید همه‌جا کامنت گذاشت تا درکش ساده‌تر بشه.
حالا بذارید یکم کامنت بهش اضافه کنیم:

 

خب، الان با همین یه‌خط کامنت، پیشرفت چشمگیری داشتیم.
حالا اگه بخوایم یکم حرفه‌ای‌تر برخورد کنیم، اینطوری می‌نویسیم:

خب، الان اگه ادیتورتون یکم فهم داشته‌باشه، خودش اینا رو بهتون پیشنهاد میده!

همین فانکشن رو تو VSCode نوشتم؛ نتیجه رو ببینید 🙂

و به‌همین زیبایی، کدهای ما خواناتر و قابل‌فهم‌تر شدند!
امیدوارم این مطلب به‌دردتون بخوره‌ 🙂

نوشته جوری کد بنویس که بشه خوند…! اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

سری غیر آموزشی لاراول

فکر میکنم حدود یک سالی هست که از فریم ورک لاراول برای انجام پروژه های وب استفاده میکنم. چند وقت پیش حین یک گفتگو با یکی از دوستان برنامه نویس این مساله به ذهنم رسید که من واقعا چقدر این ابزار رو میشناسم؟ و چقدر اجازه دارم تو فایل رزومه م از عبارت مسلط به لاراول استفاده کنم؟

خوشبختانه هفته قبل به طور کاملا تصادفی لینک مربوط به Laravel Certification Program رو تو سایت اصلی لاراول دیدم. قسمت جالب این لینک، بخشی بود که موضوعات مربوط به این آزمون رو لیست کرده بود و خب طبیعتا از نظر توسعه دهنده های اصلی لاراول، اگر کسی این موضوعات رو درست درک کنه و بشناسه، میتونه خودش رو یک Certified Laravel Developer بدونه.

من هم تصمیم گرفتم این لیست رو ملاک قرار بدم و به مرور درباره ی بخش های مختلفش مطالعه کنم و چیزی رو که درک کردم با بیان خودم توضیح بدم.

طبیعتا جنس این مطالب، با مطالب آموزشی که هدفشون توضیح از صفر تا صد یک مطلب هست، یکسان نخواهند بود.

میشه به این مطالب به عنوان تلاش یک برنامه نویس متوسط برای عمیق کردن فهم و افزایش تسلط خودش به این فریم ورک نگاه کرد.

پیشاپیش از لطف دوستانی که بعد از خوندن این نوشته ها کمکی در بهتر شدن این مطالب (و طبیعتا بهتر شدن فهم من از این مطالب) خواهند کرد، ممنونم.
این کمک ها میتونه از طریق:
* اشاره به ایرادات فنی یا ویرایشی
* معرفی موضوعات و مفاهیم مرتبط
* یا هر روش دیگه ای که به ذهن خود شما میرسه

منبع تصویر: http://www.tutoriallaravel.com

نوشته سری غیر آموزشی لاراول اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی