دغدغه این روزهای من درست نوشتن و صحیح نوشتن کدی هست که برای اپلیکیشن توسعه میدم بعد دیدم چه خوبه که در مورد همین موضوع یک مقاله بنویسم و از تجربیات خودم در این زمینه براتون بگم سعی شده داخل این مقاله تمامی مباحث رو پوشش بدم اما اگر دیدین یک مبحث گفته نشده برام داخل بخش کامنت ها کامنت بذارید که knowledge sharing داشته باشیم باهم .
نکته این سری مقالات به عنوان بهینه نوشتن در استک های مختلف فرانت قراره هر یک ماه یک بار بهش بپردازیم که این ماه سراغ ری اکت رفتیم در ماه های اینده سعی میکنم در مورد Next , Nuxt , Vue هم مطلب بذاریم .
انتخاب یک ساختار مناسب برای استک هر پروژه ای از نظر من باعث برد اون پروژه میشه چرا چون اگر ساختار مناسبی برنامه نویس برای اپلیکیشن نچینه باعث بهم ریختگی داخل پروژه میشه و این باعث میشه خودش باعث یک گلوگاه بشه پس بهتره در وحله اول برای پروژه مون ساختار صحیح بچینیم .
انواع ساختار بندی در پروژه های ری اکت
نکته : این نوع از ساختار ها صرفا بر اساس تجربیات برنامه نویس های این حوزه به وجود آمده است پس به عنوان بهترین روش نیستن
یکی از ساختارهای مرسوم داخل ری اکت همچین ساختاری هستش که شامل این دایرکتوری ها میشه که هر کدومش کار خاصی رو دنبال میکنه
دایرکتوری api : ما داخل این دایرکتوری میایم api خودمون call میکنیم و response رو بر میگردونیم
دایرکتوری assets : شامل فایل استاتیک مون شامل SVG هامون image هامون css هامون و ...
دایرکتوری components : شامل کامپوننت های اپلیکیشن مون میشه که میتونه به روش atomic design پیش بریم یا organism design و .. بسته به شرایط این دایرکتوری میتونه شامل تغییراتی بشه داخلش
دایرکتوری context : شامل Provider های برنامه مون میشه این دایرکتوری میتونه نام providers هم داشته باشه .
دایرکتوری layout : شامل قسمت های اشتراکی ui مون میشه مثل فوتر منو و ...
دایرکتوری pages : شامل صفحات اپلیکیشن مون میشه
دایرکتوری reducer : شامل reducer های پروژه مون میشه که اگر از redux استفاده میکنید داخل برنامه این دایرکتوری به store تغییر نام پیدا میکنه
دایرکتوری router : که شامل یک فایل index.ts یا index.js میشه و یک متغییر ارایه ای که روت هامون داخل این متغییر تعریف میکنیم سپس داخل root پروژه با یک حلقه روت های خودمون رو مشخص میکنیم .
دایرکتوری services : شامل کانفینگ سرویس های که داخل پروژه مون استفاده میکنیم میشه
نکته : دایرکتوری های دیگه وجود دارند بسته به سطح پروژه به معماری پروژمون اضافه میشه مثل i18n برای چند زبانه کردن یا دایرکتوری utility که بهمون کمک میکنه یک سری helper متد تعریف کنیم یا دایرکتوری hooks که شامل کاستوم هوک هامون میشه .
یکی دیگه از روش های که خیلی باب هم هست داخل معماری ری اکت معماری بر پایه ماژول هستش که میاد یک دایرکتوری به اسم views قرار میدیم و هر بخش از پروژه داخل یک دایرکتوری قرار میدیم قسمت های هر بخش داخل دایرکتوری ماژول خودش قرار میدیم
نکته در معماری بالا دو بخش داریم لوکال ماژول و share ماژول
احتمالا داخل پروژه های مختلف داشتید با یک سری نام گذاری اشنا شدین اما واقعا کدوم جز بهترین روش میتونه باشه ؟
راستش هنوز این مورد هنوز قانونی براش وجود نیومده داخل ری اکت و هر برنامه نویسی میتونه با هر ساختار و نام گذاری مربوطه خودش پیش بره اما بهتره از این قوانین نام گذاری استفاده کنیم .
اسم دایرکتوری به صورت role-permissions باشد به صورت حروف کوچیک و جداکننده بین دو کلمه
اسم فایل به صورت Camel Case باشد و اسم کامپوننت ها به همین شکل .
برای دایرکتوری های خودمون از اسم جمع استفاده کنیم مثلا pages , forms ,etc ...
از path clean استفاده کنیم یعنی چی این موضوع ؟ یعنی اینکه اگر همچین چیزی داشتیم .
@components/atom/card/card
نیایم اینطور import کنیم بیایم به این شکل یک فایل به اسم index.js or index.ts درست کنیم و داخل این فایل مون به این شکل export بگیریم و فایل index فراخوانی کنیم تا path clean داشته باشیم .
نکته : اگر به این شکل import export میگیرید حجم کمتری هم blunder شما خواهد داشت .
احتمالا داخل اپلیکیشن خودتون از پکیج های ایکون استفاده میکنید یا uikit های روی پروژه تون نصب شده دارید و ازش استفاده میکنید . و توصیه میشه برای استفاده از هر کدوم بخش های مختلف که لازم دارید به این شکل استفاده کنید .
خیلی ها رو دیدم داخل فایل خودشون میاد کل سورس svg خودشون رو میذارن داخل کدشون ایراد کار اینجاست .
پس بهتره که هر کدوم از فایل svg مون رو به یک کامپوننت تبدیل کنیم و سپس داخل جای مدنظرمون call کنیم .
فرض کنید داخل اپلیکیشن شما کلی کامپوننت وجود داره همه شون زیر دسته هم دیگه هستند و حالا کامپوننت پدر state or props تغییر میکنه :) خب تمام کامپوننت ها چه خودی چه نخودی چه بیخودی re render میشن مثلا کامپوننت تایپوگرافی شما چرا باید دوباره re render بشه ؟ یا دکمه های شما یا یک کامپوننتی که اصلا side effect داخلش رخ نداده memo به شما کمک میکنه که کامپوننت های خودتون رو Memorizing کنید هر موقعه یک تغییر که تاثیر داشت روی کامپوننت شما این کامپوننت re render بشه .
این از پارت اول این بخش بود امیدوارم لذت برده باشید ازش لایک کامنت یادتون نره اشتراک گذاری هم فراموش نشه :)