معماری و ساختار های پوشه بندی در React

مسائلی که قرار درباره ش صبحت کنم

• مقدمه
• یه flow کلی از برنامه
• ساختار flat چیه و چه معایب و مزایایی داره
• ساختار Domain Driven Design(DDD) و معایب و مزایا
• و در اخر هم درباره ساختار view-state صحبت خواهیم کرد

مقدمه

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

مقیاس‌پذیری را به معنی کارآمدی و توانایی یک سازمان، سیستم، مدل یا عملگر زیر فشار گسترش یا افزایش حجم کاری توصیف می‌کنند

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

قبل از سازماندهی ساختار پوشه های برنامه, درک flow برنامه ی که درحال ساخت هست بسیار مهم هستش
من در این مقاله از react استفاده میکنم و flow مورد نظرمون رو ریکت تمرکز داره اما باطن و تئوری ساختار پروژه تقریبا تفاوتی در تکنولوژی های دیگه ندارد.

یک نمای کلی از flow برنامه فرانت در ریکت

برای پلن و سازماندهی کردن اپلیکشین فرانتمون قبلش باید بدونیم که چطور کار میکنه و یا اینکه بقیه اجزا چطور
باهمدیگه درارتباط هستند

همونطور که عکس بالا رو مشاهده میکنید : کاربر با برنامه تعامل برقرار میکنید و روتر , veiw خاصی از کامپونتها
نمایش خواهد داد.هر veiw میتواند یک یا چند کامپونت داشته باشد.

درمرحله بعدی ریداکس و اکشن های ریداکس رو داریم و ممکن است که API فراخوانی کند که در اخرین لایه وجود دارد.

ساختار flat چیست؟

ساختار falt یکی از معروفت ترین و پرکاربردترین ساختاری های شناخته شده فرانت هستش که logic برنامه رو از veiw ها و redux جدا میکند.
یه مثال ساده بزنیم از یه پلفترم وبلاگ نویسی که چطور پوشه بندی و ساختار دهی شده است

└── src
    ├── api
    │   ├── api.js
    │   ├── posts.js 
    │   ├── comments.js 
    ├── components
    │   ├── PostComponent.js
    │   ├── CommentComponent.js    
    ├── shared
    │   ├── ButtonComponent.js
    │   ├── ModalComponent.js
    ├── containers 
    │   ├── PostListContainer.js
    │   ├── CommentListContainer.js   
    |── actions
    │   ├── PostActions.js
    │   ├── CommentActions.js  
    ├── reducers
    │   ├── PostReducers.js
    │   ├── CommentReducers.js 
    |── App.js
    |── store.js

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

ساختار Domain Driven Design چیست (DDD) ?

قبل اینکه درباره ساختار کلی این روش صحبت کنم , بهتر که درباره Domain صحبت کنیم و بدونیم که اصلا در اپلیکشین ها به چه معناست.

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

اگر مه بخواهیم ساختار پروژه رو بر اساس دامین ها جلو بریم باید که دامین ها متمایزی بسازیم که همانند مثال قبلی از مثال یک وبلاگ استفاده خواهیم که در این جا app , posy ,comment کاملا متمایز خواهد بود

└── src
    ├── app
    │   ├── App.js
    │   ├── reducers.js
    ├── post
    │   ├── PostComponent.js
    │   ├── PostContainer.js    
    │   ├── PostReducer.js    
    │   ├── PostActions.js
    │   ├── PostsListComponent.js    
    ├── comment 
    │   ├── CommentComponent.js
    │   ├── CommentContainer.js    
    │   ├── CommentReducer.js    
    │   ├── CommentActions.js
    │   ├── CommentsListComponent.js

ا.برای نوشتن هم میتوان دو روش رو پیش برد که یکی قراردادن ان ها در دامین خودشون
و دومی هم یه پوشه کاملا جدا برای تست ها در نظر گرفت

از مزایای این ساختار میتونیم به مقیاس پذیری بالا و هچنین تمیز بودن کد ها اشاره کرد که رسیدن به هر قسمت از پروژه بر اساس لاجیک رو خیلی ساده میکنه همچین اوردن نیرو های جدید رو پروژه رو سریع تر میکنه چون ساختار واضح و قابل درکی میکنه
یکی از مشکلات اساسیی توسعه نرم افزار رو حل میکنه اقای scott millett در کتابی که برای معماری DDD نوشتن اشاره میکنه :

کدی که کار مفیدی انجام میده اما بدون توضیح چگونه !!!

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

ساختار view-state چیست؟

این روش خیلی به روش flat شباهت دارد اما بهبود یافته تر که همه پوش های فایل redux در یک فهرست و فایل جمع اوری شده و پوشه های view and logic ب همان روش قبلی در پوشه اصلی باقی موندن.
این معماری ساختار بسیار بهتری برای برنامه هایی است که بزرگ هستند و به نگهداری تعداد زیادی فایل مرتبط به Redux نیاز دارند.

└── src
    ├── api
    │   ├── api.js
    │   ├── posts.js 
    │   ├── comments.js 
    ├── components
    │   ├── PostComponent.js
    │   ├── CommentComponent.js    
    ├── shared
    │   ├── ButtonComponent.js
    │   ├── ModalComponent.js
    ├── containers 
    │   ├── PostListContainer.js
    │   ├── CommentListContainer.js   
    |── redux
    |   |── store.js   
    |   |── middleware.js   
    │   ├── post
    │   │   ├── PostActions.js  
    │   │   ├── PostReducers.js
    │   ├── comment
    │   │   ├── CommentActions.js
    │   │   ├── CommentReducers.js 
    |── App.js

از مزایای این موضوع میتوان به ساختارمندی فایل های ریداکس اشاره کرد که نسبت به ساختار flat بسیار ساده و منظم تر خواهند بود و همچنین اضافه کردن فیچر ها به سادگی انجام خواهد شد

از معایت این ساختار میتوان به پیچیدگی بخش logic , view زمانی که پروژه بزرگتر خواهد شد اشاره کرد که توسعه و اموزش پروژه رو سخت تر میکنه