از زمانی که کار بر روی پروژه های فرانت اند را شروع کردم، به دنبال معماری های تمیزی بودم که با برخی از اصول اولیه توسعه من همسو باشد: کد قابل نگهداری، مقیاس پذیر و قابل خواندن. پس از جستجوی طولانی، به این نتیجه رسیدم که معماری به پروژه بستگی دارد، نه فناوری هایی که ما استفاده می کنیم. بنابراین، اگرچه ما از این مدل برای React و Redux استفاده می‌کنیم، اما می‌توان آن را با بسیاری از چارچوب‌ها یا کتابخانه‌های وب دیگر استفاده کرد.
هدف نهایی این است که یک تصویر کلی از نحوه مدل سازی پروژه های فرانت اند خود با React و مدیر ایالت مورد نظر خود داشته باشیم. پوشش می دهیم ساختار پوشه، معماری شش ضلعی، مدیریت اجزا، معماری CSS، و البته، آزمایش کردن.
تاریخچه مختصری از توسعه Frontend
توسعه معماری های تمیز در نمای جلویی ارگانیک بوده است. ما از زمانی آمده‌ایم که تمام منطق کسب‌وکار در پس‌زمینه بود. وب چیزی بیش از صفحات ثابت ارائه شده توسط سروری با منطق تجاری کمی نبود. سپس به سراغ jQuery رفتیم، که به ما استقلال کمی بیشتر داد، مانند اعتبارسنجی یا منطق UI، تا اینکه به فناوری‌های فعلی رسیدیم: SPA، که به ما اجازه می‌دهد برنامه‌های واقعی اجرا شده در مرورگر کاربر بسازیم.
از اولین تا آخرین سال، تنها چند سال گذشته است، و با چنین رشد سریع، شرکت های کمی متوقف شده اند تا به این فکر کنند که آیا واقعاً شروع به استانداردسازی کدهای نوشته شده در front-end منطقی است یا خیر. پس از همه، ما فقط چیزها را در DOM رندر می کنیم، درست است؟
چرا معماری های تمیز؟
معماری های پاک هدفی فراتر از (معمولا) افزایش تعداد فایل ها در پروژه ما دارند: جدا کردن منطق تجاری از بقیه عناصر برنامه. در این مورد، آن را از اتصالات پشتیبان و رابط جدا کنید. بیایید مورد یک برنامه کاربردی به سبک Trello را تصور کنیم. مستقل از نحوه نمایش مولفه برای ایجاد یک کار، منطقی که هنگام کلیک کردن روی دکمه “ذخیره” اجرا می شود، یکسان خواهد بود. حالا تصور کنید که تمام منطق ذخیره روی آن کامپوننت باشد. یافتن آن دشوار خواهد بود و بازسازی آن جزء مانند خلع سلاح یک بمب است.
حال تصور کنید که هنگام کلیک بر روی دکمه ذخیره، یک مورد استفاده با پارامترهایی که کاربر معرفی کرده است، فراخوانی شود. این use case اعتبارسنجی ها را انجام می دهد و یک شی جدید با تمام داده ها ایجاد می کند که آن را به مخزن مسئول حفظ آن می فرستد. مخزن، جدا از بقیه منطق، در حال حاضر اطلاعات را در حافظه محلی ذخیره می کند، زیرا ما می خواهیم یک MVP ایجاد کنیم تا ببینیم آیا پروژه قابل اعتماد است یا خیر، اما در آینده می خواهیم آن را به یک API متصل کنیم. این مخزن همچنین وضعیت را در Redux به روز می کند تا تغییر در UI منعکس شود.
در این مورد کوتاه، ما از چندین الگو و بهترین روش مانند الگوی مخزن یا the استفاده کرده‌ایم معماری شش ضلعی. در فصل های بعدی این مجموعه با جزئیات بیشتری به هر یک از این موضوعات خواهیم پرداخت. اما بیایید نگاهی دقیق تر به معماری شش ضلعی داشته باشیم.
معماری شش ضلعی (یا معماری پورت ها و آداپتورها) مدلی است که برای جدا کردن منطق دامنه، منطق برنامه و زیرساخت طراحی شده است.
همانطور که ممکن است بسیاری از شما قبلاً بدانید که چگونه این کار می کند، من تا حد امکان مختصر خواهم بود. با این حال، اگر به مقاله ای دقیق تر علاقه مند هستید، می توانم مقاله ای بنویسم که بیشتر روی قسمت ظاهری تمرکز کند
این معماری باید به عنوان یک پیاز با سه لایه (از بیرون به داخل) دیده شود: زیرساخت، برنامه کاربردی و دامنه. جایی که زیرساخت در مورد اپلیکیشن و دامنه می‌داند، اپلیکیشن از دامنه می‌داند، و دامنه فقط درباره خودش می‌داند.
React در کجای معماری شش ضلعی قرار می گیرد؟
به سوال میلیون دلاری می رسیم: React کجا در معماری شش ضلعی قرار می گیرد؟ برای پاسخ به این سوال پیچیده، ما یک پاسخ ساده داریم: در لایه زیرساخت. همانطور که در مستنداتش توضیح داده شده است، React یک کتابخانه برای ساخت رابط های کاربری است، نه چیزی بیشتر. بنابراین، ما آن را درست مانند سایر کتابخانه ها یا فریمورک ها مانند Vue یا Svelte در آنجا قرار می دهیم. بنابراین ساختار مورد قبلی به صورت زیر است:
-
React، اجزای JSX، قلاب‌ها، منطق رابط، استایل‌ها و Redux همگی در زیر ساخت لایه. پیاده سازی مخزن و سرویس گیرنده Local Storage (که در آینده با یک کلاینت REST جایگزین خواهد شد) نیز در اینجا قرار دارند.
-
مواردی مانند ایجاد یک کار جدید، اختصاص آن به کاربر، افزودن یادداشت یا حذف یک کار در کاربرد لایه.
-
در نهایت، در دامنه لایه، ما انواع عناصر دامنه، رابط های مخزن و به طور کلی منطق دامنه داریم.
به نظر بهتر است، اینطور نیست؟ حالا ما همه چیز را سر جای خودش داریم. پیدا کردن آن آسان تر است، اما برای آن، ما باید یک ساختار پوشه خوب داشته باشیم، که در فصل بعدی این مجموعه به آن خواهیم پرداخت.
