خب ... یه جورایی میشه گفت هیچ قانونی برای ساختار پوشه ها وجود نداره و شما میتونین هر طوری که دوست دارین کدهاتون رو بنویسی. میدونیم که یه برنامه ی ریاکت ترکیبی از کامپوننت هاست ...هر کامپوننت هم تعدادی فایل js , فایل تست , فایل استایل, فایل استوری ,فایل ترجمه و... ممکنه داشته باشه. وقتی پروژه هارو نگاه میکنی میبینی که از دو تا شیوه ی کلی استفاده میکنن
در شیوه ی اول توی روت پروژه یه پوشه برای تست ,یه پوشه برای استوری , یه پوشه برای ترجمه , یه پوشه برای استایل و در نهایت یه پوشه برای کامپوننت ها درست میکنن ...حالا متناسب با هر پوشه و فایل جدیدی که برای کامپوننت ساخته میشه پوشه ها و فایل هایی هم داخل استایل, تست,ترجمه و استوری میسازن.این شیوه خوبیش اینه که همه ی استایل ها داخل یه پوشه هستن یا همه ی تست ها داخل یه پوشه هستن. بدیش هم اینه که شما وقتی با یه کامپوننت کار داری بایداجزای مختلفش رو در جاهای مختلف دنبالش بگردی که اصلا به نظرم جالب نیست.
در شیوه ی دوم هر فایلی که مربوط به یه کامپوننت هست همراه همون کامپوننت و توی همون پوشه نگه داری میشه ..اینجوری اگه بخوای کامپوننتی رو ادیت کنی همه ی فایل های مربوط به اون رو میتونی یه جا ببینی و ویرایش کنی و یا اگه بخوای محل قرارگیری کامپوننتی رو عوض کنی کافیه همین یه پوشه رو جابه جا کنی. من این شیوه رو بیشتر دوست دارم.
ما چون داریم از next.jsاستفاده میکنیم مجبوریم پوشه ی page و static رو داشته باشیم ..البته next.js قراره در نسخه های جدیدش این اجازه رو به ما بده که بتونیم این پوشه هارو جابه جا کنیم. پوشه ی page رو که قبلا دیده بودید ...پوشه ی static هم برای نگه داری فایل های استاتیک کاربرد داره ..هر فایلی مثل yourfile.jpg که داخل این پوشه قرار بگیره از طریق آدرس زیر قابل دسترسه
127.0.0.1:3000/static/yourfile.jpg
البته اگه شما از express استفاده میکنین میتونین فایل های استاتیکتون رو از هر جایی که دوست دارین هندل کنین
یه پوشه به اسم src درست میکنیم تا سایر پوشه های پروژه رو داخلش بسازیم . پس تا اینجا ما داخل روت پروژه مون همچین ساختاری داریم
پوشه vscode شامل تنظیمات vscode هست. پوشه ی node_module هم شامل کتابخونه هایی هست که ما نصب کردیم. پوشه ی next هم بعد از این که پروژه رو بیلد میگیرید به صورت خودکار ساخته میشه و شامل بیلد ها و... هست. اون فایل های زیر هم تنظیماتی هستن که قبلا دیدیمشون
و اما در ادامه
ما برای پروژه مون واقعا به چه پوشه هایی نیاز داریم؟
پوشه ی api
یه بخش زیادی از یه پروژه ی فرانت استفاده از api هایی هست که بک اند برامون ساخته ..این که بخوایم مدام در وسط کد api هارو صدا بزنیم کار قشنگی نیست و من ترجیح میدم توابعی برای کار با api هام بسازم و اونارو توی پوشه ی api نگه داری کنم..و اگه قراره تنظیمات خاصی براشون در نظر بگیرم یه بار این کار رو انجام بدم..شاید شما دلتون نخواد همچین پوشه ای داشته باشین و حس کنین نهایتا لازم دارین که یه فایل به اسم api داشته باشین ...تجربه ی شخصی میگه اگه یه روز حس کردی لازم داری یه فایل به اسم api یا rout یا هر چی داشته باشی... به زودی و با گسترش پروژه ت لازم میشه اون فایل رو به چند تا فایل ریز تر بشکونی.
پوشه ی context
ما برای مدیریت استیت هامون داریم از context ها استفاده میکنیم برای مدیریت راحت تر کانتکست ها بهتره اونارو یه جا نگه دارید ..کجا بهتر از پوشه ای به نام context?
پوشه ی type
وقتی که دارید از تایپ اسکریپت استفاده میکنید تایپ ها خیلی کمکتون میکنن. اگه تایپی رو داخل فایلی با فرمت .d.ts بزارید . در کل پروژه بدون نیاز به ایمپورت میتونین از اون تایپ استفاده کنین .اینقابلیت خیلی کمکتون میکنه. بنابراین برای قسمت های مختلف بهتره که چند تا فایل برای نگه داری تایپ ها داشته باشیم و اونارو توی پوشه ی type قرار بدیم
پوشه ی hook
نسخه ی جدید react بهمون اجازه میده تا کاستون هوک هایی بسازیم که کاربرد های متنوعی دارند و جاهای مختلفی از پروژه بتونیم از اونا استفاده کنیم ما این هوک هارو در پوشه hook نگه داری میکنیم
پوشه ی util
بعضی از فانکشن ها هستند که کارهایی رو برای ما انجام میدن و ما دوس داریم در سراسر پروژه هر جا که لازم شد بتونیم ازشون استفاده کنیم .چنین فانکشن هایی رو توی پوشه ی util نگه میداریم ...میپرسی مثل چی؟ مثل فانکشن تبدیل عدد به حروف.
پوشه ی constant
هر پروژه ای مجموعه ای از مقادیر ثابت داره که میتونیم اینجا نگه داریشون کنیم و یا اگه حس میکنین مقادیرتون کمه میتونین موقتا توی یه فایل و در پوشه ی util نگه داریدشون
و اما پوشه ی component
اول اینو بگم که ما دولوپر هایی هستیم که مجبوریم موقع تنظیم express نقش بک اند هارو بازی کنیم , موقع تنظیم چرخه ci\cd و دیپلوی و nginx نقش دواپس هارو بازی کنیم و موقع طراحی کامپوننت ها هم گریزی به دیزاینر ها بزنیم. اینو نگفتم که بگم خیلی خفنیم ...اینو گفتم که بدونین خیلی کم و در حدی که لازم مون میشه از سایر چیزا میدونیم .. پس قطعا من توی خیلی از قضایا همه ی مسیر هارو نرفتم و فقط قدر مسیری که تا اینجا طی کردم دانش دارم.
اتمیک دیزاین یا atomic design
خیلی خلاصه میگه که شما برای طراحی یک سایت باید اون رو به قسمت های کوچیکی که قابلیت استفاده ی مجدد داشته باشه بشکونین
یک سایت از قسمت های مختلفی تشکیل شده که میشه اون هارو به اجزای ریز تری تقسیم کرد .اسم کوچک ترین اجزا رو atom گذاشتن که شامل دکمه ها, آیکن ها , input, select و ... میشه
ترکیب این اجزای کوچک تر منجر به تشکیل قسمت های بزرگتری میشه که بهش میگن مولکول ...مثلا شما اگه هدر یک سایت رو نگاه کنی شامل منوی جستجو , ناوبار, لوگو و... هست . حالا خود منوی جستجو شامل یک input و یک button هست .
شما ممکنه این منوی جستجو رو علاوه بر هدر در منوی کناری صفحات دیگر هم استفاده کنین بنابراین بهتره خود منوی جستجو رو هم در جایی جدا نگه داریم . و اگه لازم شد دوباره ازش استفاده کنیم
میتونین در این لینک بیشتر در مورد اتمیک دیزاین بخونین
atom,molecule,organism,template
و توی هر کدوم از این پوشه ها پوشه هایی متناسب با اسم کامپوننت ها ساخته میشه که شامل فایل های تست و استوری و ... هست.
این سیستم چند تا چیز رو به ما دیکته میکنه
هیچ ایمپورتی از لایه های بالاتر به لایه های پایین تر نباید داشته باشیم.
لایه ی اتم ها نباید لاجیک وابسته ای داشته باشه
این که اسمشون چیه اصلا مهم نیست بلکه ساختارشون مهمه ..شما میتونین از اسم های دیگه ای مثل element,component,module,layout استفاده کنین
ما فقط توی اتم ها اجازه داریم از المان هایی مثل <button> <input> <select> <a> و ... استفاده کنیم
از پیچیده نوشتن اتم ها جلوگیری کنین و سعی کنین خوب داکیومنتشون کنین
با گذشت زمان احتمالا باز هم این ساختار کمی تغییر کنه ولی فعلا من این رو دوست دارم
در انتها این رفرنس ها هم ببینین بد نیست
خب توی قسمت بعد ایمپورت هارو خوشگل میکنیم و git رو هم میاریم وسط
