زیر ساخت مناسب پروژه های روی ری اکت و نکست
shahryarjb opened this issue · 0 comments
در این ایشو یک سری نیازمندی ها قراره مطرح بشند که در هر پروژه با اون ها بخورد می کنیم و خیلی طول می کشه. اگر به صورت یک کلاس باشند و مباحث بهینه سازی نیز در اون ها پیش بینی بشند خیلی کمک کننده هست پروژه ها با ثبات بیشتر و همینطور سرعت بیشتر جلو برند
۱. درست کردن اسکیما برای بخش های عمومی با zod
یکی از مواردی که اخیرا با اون مشکل دارم آماده نبودن یک سری آبجکت های zod هست که همیشه در همه پروژه ها می یاند و تقریبا ۹۰ درصد بخش هارو پشتیبانی می کنند
۲. ساخت interceptors کلی برای تمامی درخواست ها
در interceptors فعلی که در حال استفاده اون هستیم همیشه باید کلی از بخش ها مثل دانلود blob و همینطور آپلود و تبدیل به base64 رو از اول بنویسیم و این باعث می شود که ما برای axios بخش های زیادی داشته باشیم که تکرار مکرارات هست . این بخش باید بر اساس کلاس مدنظر اطلاعات اولیه رو قبول کنه و در صورت نیاز بیاییم اون رو با اطلاعات جدید به روز رسانی کنیم. این بخش حتما باید اسکلتون رو به عنوان پترن قبول کنه و نیاییم کلی کلاس درست کنیم چون درخواست ها زیاد هستند و بخش ها متعدد و ساخت یک اینستنس هر سری جالب نیست
۳. ساخت هندلینگ ارور و دیتا بعد از ارجاع به توابع کال بک react query مثل onError
این بخش یکی از بخشی هایی هست که همیشه کپی می شود و با کمترین تغییرات دوباره داپلیکییت می شود و باعث می گردد وقت زیادی از دست برود و همینطور مشکل بزرگتر این است که باعث کثیف شدن کامپوننت و سنگین شدنش می شود. اگر یک نگاه اجماعی به اون بخواهیم بکنیم متوجه می شیم که بله اطلاعات داخل اون کلا تفاوت زیادی با بخش های دیگه ندارد.
۴. ساخت کواری های پایه به ای پی آی
در هر پروژه این بخش نیز بسیار تکرار می شود. به عنوان مثال چند مبحث CRUD همیشه در همه ای پی آی ها وجود دارد و همین موضوع باعث می شود کلی کواری جدید نوشته شود.
مورد بعدی اینکه این کواری ها به علت کنترل نشدن تکرار می شوند یا به شرایط مختلف نوشته می شوند که توسعه بلند مدت رو سخت می کنند
۵. دسترسی مناسب ران تایم
این بخش هم یکی از مواردی هست که باید از طرف ای پی آی نیز مورد پشتیبانی قرار بگیرد. ولی بر اساس رول کاربر نیاز هست که پیاده سازی شود در پروژه الیکسیر گروه میشکا یک نمونه یونیکس لایک وجود دارد که بهترین گزینه می باشد
https://github.com/mishka-group/mishka_developer_tools/blob/master/guidance/permission-access.md
ساختار کلی
اگر بخشی از مدل کانورس در این بخش مدنظر گرفته شود می تواند کمک کننده باشد. در مورد ساخت یک پروژه پلاگین بیس فعلا نیاز به تحقیقات بیشتری دارد ولی باید مدنظر گرفته شود تا کل پروژه بر اساس پلاگین ها مختلف درست شود و نیاز نباشد هر سری هسته کامل دست زده شود و پروژه باید در کمترین زمان ممکن توسعه پیدا کند.
مورد بعدی اینکه تا اونجا امکان داره اطلاعات باید از چشم افزونه های مروگر و ... مخفی بماند /
Core
- plugin
- notification
- time
- connection
- http
- upload
- download
- error
- auth
- multilanguage
- helper
- index.ts
ساختار پیشنهادی دریافت خروجی از بکند
const data = {
status: 'error', // error | ok
action: 'create', // create, read, update, delete
message: 'A message of an error or a success data',
errors: [
{
message: 'Based on field provider input you have to send authorized data',
field: 'provider',
field_path: 'profile.social.provider', // optional for user auto generating
errors: [],
},
{
message:
'There are several errors in sending emails to pre-prepared users',
field: 'email',
field_path: 'email', // optional for user auto generating
errors: [
'This field is required and must be submitted',
'The minimum number of email characters must be 5',
],
},
],
data: [{ test: 'hi' }, { test: 'bye' }],
section: 'admin:user', // the first one is parent the other is childeren Ex: admin:tickets:details
role: 'admin:edit', // can be *:* or admin:edit or user:view , or user:delete
count: 10 // The number of errors or the number of data
// Example for role: https://github.com/mishka-group/mishka_developer_tools/blob/master/guidance/permission-access.md
};
نکته: در صورتی که می خواهید اروری بدهید که در فیلد نیست می تونید فقط کلید message رو پر کنید و کلید errors رو روی آرایه خالی قرار بدهید ولی به این نکته توجه کنید که status باید حتما روی ارور ست شود
پست به روز رسانی می شود ...