در طول رفت و آمد روزانه، تقریباً به طور کامل با حافظه ماهیچه‌ای و رفلکس‌های شرطی رانندگی می‌کنم، به سختی از مغزم استفاده می‌کنم، که ذهن من را برای پرسه زدن و فکر کردن در مورد چیزهای مختلف آزاد می‌گذارد.
یک روز صبح، ناگهان به ذهنم رسید که در سال‌های اخیر، صنعت از رویکردهای «داده محور» برای به‌روزرسانی دیدگاه‌ها حمایت کرده است. با تأمل در کاری که در چند ماه گذشته انجام داده‌ام، متوجه شدم که توسعه لایه دید ما صرفاً مبتنی بر داده نیست، بلکه “پیکربندی محور” است.
مشاهده به روز رسانی ها
بیایید ابتدا نحوه به روز رسانی نماها را در توسعه لایه دید، چه در گذشته و چه در حال بررسی کنیم.
قبل از محبوبیت کتابخانه ها/فریم ورک های فرانت اند مانند React و Vue، دستکاری دستی DOM معمول بود:
در Vue، داده binding استفاده می شود:
label="Are you married?">
v-model="married">
:label="true">Yes
:label="false">No
label="Number of children" v-show="married">
/>
export default {
data() {
return {
married: false
};
}
}
و در اینجا نحوه انجام همان کار از طریق پیکربندی آمده است:
widget="form">
name="married" label="Are you married?" widget="radio" />
name="childrenCount" label="Number of children" widget="input" invisible="record.married !== true" />
آیا روش آخر را خیلی راحت و خوانا نمی بینید؟
در مقایسه با دستکاری DOM دستی، اتصال داده نسبتاً «هوشمندتر» است، که یک رویکرد توسعه مبتنی بر داده است. با این حال، هدایت داده خالص فقط مشکلات اصلی نمایش داده ها را حل می کند و هیچ گونه پشتیبانی برای توسعه پذیری لایه view ارائه نمی دهد، مانند همان جزء جدول:
- در مدل A می خواهید فیلدهای a, b, c و در مدل B فیلدهای d, e, f را نمایش دهید.
- در بدنه اصلی صفحه، میخواهید تنظیمات ترجیحی ستون و تنظیمات چگالی متن سلول را نمایش دهید، اما نه در یک کادر محاورهای.
- در برنامه A، سر جدول دارای گوشه های تیز و پس زمینه آبی روشن است، در حالی که در برنامه B دارای گوشه های گرد و پس زمینه اسطوخودوس است.
در سناریوهای پیچیده و متغیر کسب و کار میانی و بکاند، برای به حداکثر رساندن استفاده مجدد از یک کامپوننت و ساخت سریع یک اپلیکیشن میانی و بکاند با برخی اجزا، به یک سیستم توسعهپذیر انعطافپذیر و قدرتمند نیاز است.
مشاهده پیکربندی
نکات اصلی که می توان برای یک صفحه یا یک نما پیکربندی کرد عبارتند از: قالب ها، مدل ها، منطق و تم ها.
قالب ها
“الگوهای” مورد استفاده در توسعه وب بیشتر مطابق با HTML و جهتگیری توسعه هستند، مانند: قالبهای Vue، Pug (Jade)، Thymeleaf، FreeMarker، Velocity و غیره.
با این حال، «الگوها» در اینجا مستقیماً به HTML مربوط نمیشوند، بلکه توصیفی از ساختار view، ساختار داده یا ساختار منطقی یک دامنه خاص است که یک DSL خارجی است:
- تشریح الگوهای نمایش ظروف داده.
- تشریح الگوهای جستجوی فیلترها و اپراتورهای جستجو؛
- تشریح الگوهای طرح بندی طرح بندی های کلی.
- تشریح قالب های چاپی برای چاپ کاغذ.
- تشریح الگوهای پرسشنامه برای نظرسنجی.
این قالب ها از اصول طراحی یکسانی پیروی می کنند و از مجموعه تجزیه کننده های مشابهی برای حل مشکلات دامنه های مختلف استفاده می کنند. آنها مجموعه ای از برچسب ها هستند و تا زمانی که مشکلات دامنه جدیدی برای حل وجود دارد، می توان مجموعه جدیدی از برچسب ها را اضافه کرد.
الگوها نه تنها به افراد اجازه می دهند اطلاعاتی را که توصیف می کنند در یک نگاه درک کنند، بلکه شکل نهایی ارائه شده را نیز کنترل کنند. برای جزئیات بیشتر، مقاله قبلی من “اجازه دهید درباره توسعه فرانت اند مبتنی بر الگو صحبت کنم” را ببینید.
مدل ها
«مدلهای» ذکر شده در اینجا عمدتاً به ابرداده اشاره دارد. فراداده چیست؟ به زبان ساده، «دادههایی است که دادهها را توصیف میکنند».
تصور کنید یک فرم اطلاعات شخصی وجود دارد که باید اطلاعات زیر را پر کنید:
- نام
- تاریخ تولد
- سن
- جنسیت
- وضعیت تأهل
- تعداد فرزندان
- درآمد ماهانه
- سرگرمی ها
به این فکر کنید که این اطلاعات چه نوع داده هایی هستند. تصور نکنید که نام ها به جای متن طولانی، رشته هستند، سن به جای یک رشته، یک عدد است، و جنسیت به جای شمارش، یک بولی است…
برای استانداردسازی پردازش داده ها، لازم است داده هایی که باید پردازش شوند، یعنی استفاده از ابرداده، توصیف شود.
اطلاعاتی که توضیح داده می شود عمدتاً شامل انواع داده ها و برچسب های متنی است که باید نمایش داده شوند. اگر یک نوع پایه مانند بولی، عددی یا رشته ای نیست، بهتر است منبع داده آن را توصیف کنید، مانند enumeration. در صورت لزوم، همچنین میتواند توضیح دهد که آیا مورد نیاز است، آیا فقط خواندنی است و غیره:
[
{
"name": "name",
"label": "Name",
"type": "string",
"required": true
},
{
"name": "birthday",
"label": "Date of Birth",
"type": "date",
"required": true
},
{
"name": "age",
"label": "Age",
"type": "integer",
"required": true
},
{
"name": "gender",
"label": "Gender",
"type": "enum",
"options": [],
"required": true
},
{
"name": "married",
"label": "Marital Status",
"type": "boolean",
"required": true
},
{
"name": "childrenCount",
"label": "Number of Children",
"type": "integer",
"required": true
},
{
"name": "monthlySalary",
"label": "Monthly Income",
"type": "currency"
},
{
"name": "hobbies",
"label": "Hobbies",
"type": "m2m",
"options": "",
"chosen": []
}
]
تأثیر ابرداده بر روی نما عمدتاً مربوط به داده است و بر فرم نمایش تأثیر نمی گذارد، مانند: کدام فیلدها برای نمایش (تولید الگوهای نمایش بر اساس ابرداده)، قوانین اعتبار سنجی فیلد، وضعیت ویرایش فیلد، پارامترهای درخواست و غیره.
قالب view ایجاد شده بر اساس ابرداده فوق چیزی شبیه به این خواهد بود:
widget="form">
name="name" label="Name" required="true" />
name="birthday" label="Date of Birth" required="true" />
name="age" label="Age" required="true" />
name="gender" label="Gender" required="true" />
name="married" label="Marital Status" required="true" />
name="childrenCount" label="Number of Children" required="true" />
name="monthlySalary" label="Monthly Income" />
name="hobbies" label="Hobbies" />
هنگام استفاده از ابرداده، بهترین کار این است که باطن بتواند با هم بازی کند، که باعث صرفه جویی در زمان زیادی در طراحی رابط، بررسی و اشکال زدایی مشترک می شود. در عوض، backend مدل را تعریف می کند. اگر فرانت‌اند تنها بتواند به تنهایی بازی کند، میتوان از ابزارهایی مانند JSON Schema استفاده کرد.
منطق
اگر فریم ورک به طور معقول طراحی شده باشد، باید بتوان منطق قابل تنظیم خارجی را بدون تغییر پیاده سازی داخلی کامپوننت، ترکیب کرد. بر اساس وزن منطق و نحوه ترکیب و 联动 می توان آن را به طور تقریبی به اعمال و عبارات تقسیم کرد.
«اقدامات» انتزاع یک منطق کامل، معادل یک تابع است که برای توصیف و فقط توصیف «چه باید کرد» استفاده میشود، نه «آنچه به نظر میرسد». یک عمل قابل استفاده مجدد باید اتمی باشد.
بر اساس تعریف منطق و موقعیتی که در آن اجرا می شود، می توان آن را به اقدامات سمت کلاینت (حس گسترده) و اقدامات سمت سرور تقسیم کرد: اقدامات سمت مشتری (حس گسترده) در قسمت جلویی تعریف و اجرا می شوند. اقدامات سمت سرور در قسمت پشتی تعریف و اجرا می شوند.
اقدامات سمت مشتری (معنای گسترده) را می توان بر اساس سناریوها و ویژگی های خاص به چندین نوع اقدام تقسیم کرد:
اقدامات مسیریابی برای پیمایش صفحه هستند. اقدامات CRUD برای عملیات داده است. اقدامات سمت مشتری (معنای محدود) یک منطق ساده است که می تواند به سادگی به عنوان یک تابع JS درک شود. کنشهای ترکیبی برای «بستهبندی» انواع دیگر کنشها، مانند تابعی که توابع دیگر را فراخوانی میکند، استفاده میشود.
اقدامات سمت سرور را می توان به سادگی و به طور خام به عنوان رابط های پشتیبان CRUD غیر متعارف درک کرد.
عبارات یک منطق سبک هستند که عمدتاً برای محاسبات مقدار فیلد، فیلتر گزینه، پیوند وضعیت و سایر سناریوهایی که از منطق ساده استفاده می کنند استفاده می شود:
widget="form">
...
name="married" label="Marital Status" required="true" />
name="childrenCount" label="Number of Children" required="record.married === true" invisible="record.married !== true" />
...
تم ها
باور کنید که وقتی کلمه “تم” را می بینید، اولین واکنش تغییر فونت، رنگ، رنگ پس زمینه و غیره “پوست” است. با این حال، در زمینه این مقاله، کاملاً صحیح نیست.
الگوها، مدلها و منطقی که در بالا ذکر شد، پیکربندیهای سطح پایینتری هستند که بر نمایش اجزاء از بیرون تأثیر میگذارند. از سوی دیگر، تمها پیکربندیهای سطح بالایی هستند که بر اجزای داخلی یا خودشان تأثیر میگذارند – سبکها، رفتارها، مؤلفهها و زمانهای اجرا وابسته به آنها.
درک «سبکها» آسان است، «پوستههایی» که فونت، رنگ، رنگ پسزمینه و غیره را تغییر میدهند، اما «رفتارها» چیست؟ به الزامات زیر توجه کنید:
- فیلدهای بولی میخواهند از اجزای سوئیچ در یک برنامه و از چک باکس، رادیو یا اجزای انتخاب در برنامههای دیگر استفاده کنند.
- جداول میخواهند تنظیمات ترجیحی ستون و تنظیمات چگالی متن سلول را در بدنه اصلی صفحه نمایش دهند، اما نه در کادرهای گفتگو.
پیکربندیهایی که برای حل این نوع نیازها استفاده میشوند «رفتار» هستند.
در مورد اینکه چرا کامپوننتها و زمانهای اجرا وابسته به آنها نیز پیکربندی هستند، به این دلیل است که در این سیستم، منطق تجاری اصلی توسط سیستم زیربنایی گرفته میشود و اساساً فقط منطق تعاملی وجود دارد که به خود مؤلفه تعلق دارد. بنابراین، چه Vue، چه React یا موارد دیگر، یا ترکیبی از چندین مورد، بر پیشرفت کسب و کار واقعی تأثیری نخواهد داشت.
خلاصه افکار
دلیل استفاده از «ویو توسعه» در عنوان مقاله به جای «توسعه جلویی» این است که تمرکز کل مقاله بر روی لایه view است و اساساً هیچ اشاره ای به لایه های دیگر نشده است، اما به این معنا نیست. که فقط لایه view را می توان پیکربندی محور کرد.
در تئوری، در یک معماری front-end که می تواند به سرعت به تغییرات تجاری پاسخ دهد، باید کاملاً قابل تنظیم باشد و هر لایه را می توان جایگزین کرد، اما آنچه که نمی توان جایگزین کرد اهداف طراحی، ایده های طراحی و پروتکل های رابط است. اینها روح هستند. تا زمانی که آنها آنجا هستند، معماری بدون تغییر باقی می ماند.
