چیزهایی در مورد زمینه ها در پروژه های فرانت اند

پس از دو مقاله “چیزهایی درباره ماژول ها در پروژه های فرانت اند” و “سیستم اجزای رابط کاربری در پروژه های فرانت اند”، در نهایت می توانیم مقاله ای را به طور خاص به موضوع “زمینه” اختصاص دهیم.

شفاف سازی مفهوم

قبل از پرداختن به موضوع اصلی، اجازه دهید ابتدا چندین مفهوم مرتبط نزدیک با موضوع را روشن کنیم: دولت، مدیریت دولتی، و زمینه.

ایالت

گاهی اوقات، دو گروه از مردم در یک بحث داغ شرکت می‌کنند – یک گروه ادعا می‌کند، “جلو همه چیز درباره وضعیت است؛ هیچ داده‌ای وجود ندارد. این حالت است که دیدگاه را هدایت می‌کند، نه داده‌ها”. گروه دیگر پاسخ می دهد، “آیا دولت فقط داده نیست؟ چه چیز دیگری می تواند باشد؟” – هر دو طرف اشتباه نمی کنند. آنها به سادگی از دیدگاه های مختلف ایستاده اند.

به طور کلی، “داده” به داده های پایدار ذخیره شده در پایگاه های داده یا سیستم های فایل اشاره دارد که “ایستا” و “پایدار” هستند که اغلب به عنوان مخفف “منبع داده” استفاده می شود. از سوی دیگر، «وضعیت» داده‌های گذرا نگه‌داشته‌شده در حافظه است که «پویا» و «موقت» هستند، که از داده‌های خوانده‌شده از طریق درخواست‌های HTTP یا ذخیره‌سازی محلی، و همچنین عملیات کاربر روی رابط سرچشمه می‌گیرند. هر دو داده هستند

به عبارت دیگر، می توان در نظر گرفت که در معماری کلاسیک سه لایه، تمام داده های بالای لایه داده “وضعیت” هستند:

برای frontend، همتای ارتباطی لایه داده، سرور و ذخیره‌سازی محلی است.

مدیریت دولتی

«مدیریت دولتی» چیست؟ همانطور که از نام آن پیداست، “مدیریت” “دولت” است. اگرچه این اصطلاح با محبوبیت Redux و مواردی از این دست به یک کلمه رایج در جامعه frontend تبدیل شده است، اما مفهوم جدیدی نیست.

همه چیز در دنیا نیاز به مدیریت دارد. با این حال، زمانی که به اندازه کافی پیچیده نیست، نیازی به بحث در مورد آن به عنوان یک رشته یا روش جداگانه وجود ندارد.

با توجه به جدایی فرانت اند و بک اند و ظهور اپلیکیشن های تک صفحه ای، وضعیت موجود در فرانت اند پیچیده تر شده است و مدیریت موثر را به یک چالش تبدیل می کند و در نتیجه منجر به وضعیت فعلی می شود که بسیاری از افراد به “مدیریت دولتی” توجه و بحث می کنند. .

در پروژه‌های فرانت‌اند که من با آن‌ها مواجه شده‌ام، راه‌حل‌های مدیریت دولتی «قطبی» هستند – یا در بین اجزای مختلف UI پراکنده شده‌اند یا در یک به اصطلاح «فروشگاه جهانی» متمرکز هستند – من کاملاً با هیچ‌یک از این رویکردها موافق نیستم.

زمینه

در مقاله‌های «چیزهایی درباره ماژول‌ها در پروژه‌های فرانت‌اند» و «سیستم اجزای رابط کاربری در پروژه‌های فرانت‌اند»، مفهوم «زمینه» توضیح داده شده است. به زبان ساده، نقشی را در برنامه‌هایی شبیه به «زمینه» ایفا می‌کند که به افراد کمک می‌کند چیزها را بفهمند و واکنش‌های مربوطه را انجام دهند، بالاخره اصطلاح انگلیسی آن‌ها نیز «زمینه» است.

در کاربردهای عملی، “زمینه” احتمالاً یک شی با ویژگی ها و روش های بسیاری برای خواندن و نوشتن عملیات بر روی آنها است. متغیرهایی که در معرض دید قرار گرفته‌اند یا آشکار نشده‌اند، «وضعیت‌های» فوق‌الذکر هستند، و روش‌ها یا کارکردهای آشکار برای مدیریت این «وضعیت‌ها» هستند – آنها با هم «زمینه» را تشکیل می‌دهند.

یک زمینه را می توان با استفاده از رویکرد کلاس پیاده سازی کرد:

class ValueContext {
  private value;

  constructor({ initialValue }) {
    this.value = initialValue;
  }

  public getValue() {
    return this.value;
  }

  public setValue(value) {
    return this.value = value;
  }
}

const context = new ValueContext({ initialValue: 'Hello, Ourai!' });

یا با استفاده از یک رویکرد کاربردی:

function createValueContext({ initialValue }) {
  let value = initialValue;

  return {
    getValue: () => value,
    setValue: newValue => (value = newValue),
  };
}

const context = createValueContext({ initialValue: 'Hello, Ourai!' });

صرف نظر از روش پیاده‌سازی یا منطق خاص، برای مصرف‌کنندگان زمینه، یک API است – «زمینه» رابطی است که بخش‌های مختلف منطق را به هم متصل می‌کند و دارای درجه معینی از معناشناسی تجاری تعمیم‌یافته است.

اجزا و حالت

تعامل و حالت جدایی ناپذیرند. جدا از مؤلفه‌های رابط کاربری صرفاً نمایشگر، معمولاً مؤلفه‌های رابط کاربری دارای وضعیت‌های مرتبط هستند، البته در مکان‌های مختلف حفظ می‌شوند.

بر اساس اینکه آیا یک مؤلفه UI وضعیت خود را در داخل حفظ می کند، آنها را می توان به «مولفه های بدون حالت» و «مولفه های حالت دار» تقسیم کرد.

اجزای رابط کاربری نمایشگر صرفاً بدون شک “مولفه های بدون حالت” هستند. برای مؤلفه‌های رابط کاربری تعاملی، اگر حالت به صورت خارجی حفظ شود، «مولفه‌های بدون حالت» هستند. در غیر این صورت، آنها “مولفه های حالت” هستند-

مثال بالا یک کامپوننت حالت دار است، در حالی که نمونه زیر یک جزء بدون حالت است:

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

کنترل‌ها معمولاً به‌عنوان اجزای بدون حالت طراحی می‌شوند، به‌ویژه آنهایی که دارای تعاملات ساده و صرفاً نمایش‌گرا هستند. برای اطمینان از عملکرد پایه، کنترل های تعاملی پیچیده ممکن است به عنوان اجزای حالت دار طراحی شوند.

هنگام کپسوله کردن اجزا، رویکرد اکثر افراد شبیه به کپسوله کردن کنترل ها است که منجر به:

در اجزای نسبتاً درشت، اگر عمدتاً به ویژگی ها و رویدادها برای برقراری ارتباط متکی باشند، تعداد آنها به راحتی می تواند از کنترل خارج شود و ساختار داخلی و منطق نیز غیرقابل تشخیص مخدوش می شود و نگهداری را بسیار دشوار و ناخوشایند می کند. آشفتگی💩!

اورای سیستم اجزای رابط کاربری در پروژه‌های فرانت‌اند

محصور کردن اجزاء به روشی مشابه کنترل ها می تواند به راحتی منجر به تعداد غیرقابل کنترلی از ویژگی ها و رویدادها، یا گسترش منطق داخلی شود و اجزاء را بسیار متورم کند – در هر صورت، هزینه نگهداری را افزایش می دهد.

من معتقدم که مؤلفه‌ها در حالت ایده‌آل نباید منطق تعامل یا منطق تجاری را در داخل داشته باشند، و همچنین نباید هیچ حالتی را حفظ کنند – حالت و منطق کسب‌وکار باید به متن بالا برود، منطق تعامل باید در کنترل‌ها غرق شود، و حالت نمایش باید از وضعیت کسب و کار محاسبه شود – در حالت ایده آل، تنها منطق در مؤلفه ها تبدیل بین تجارت و تعامل / نمایش است.

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

به طور خلاصه، در “ارگانیسم” یک برنامه کاربردی جلویی، کنترل ها و اجزاء “بافت ها” و “ارگان ها” هستند که عملکردهای خاصی را ایجاد می کنند، در حالی که زمینه، “اعصاب” و “رگ های خونی” است که اطلاعات و مواد مغذی را به آنها منتقل می کند. .

نمای کلی زمینه

علاوه بر حالت‌هایی که باید حفظ شوند و روش‌ها/عملکردهای خواندن/نوشتن آن‌ها که قبلاً ذکر شد، عناصر اساسی که یک زمینه را می‌سازند همچنین شامل یک مکانیسم همگام‌سازی است که عمدتاً بر اساس الگوی مشاهده‌گر است تا داده‌ها را در داخل و خارج از زمینه ثابت نگه دارد. .

در سیستمی که در این سری مقالات توضیح داده شده است، زمینه ها تقریباً به سه دسته تقسیم می شوند: زمینه برنامه، زمینه ماژول و زمینه داده.

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

زمینه برنامه، حالت های مشترک در یک برنامه را حفظ می کند، مانند مسیریابی، موضوع، اطلاعات پیکربندی بین المللی، و اطلاعات و مجوزهای اولیه کاربر.

«زمینه ماژول» عمدتاً برای حفظ حالت‌های متمرکز حول «ماژول‌ها» استفاده می‌شود، مانند اطلاعات وابستگی به منابع ماژول‌های دیگر که یک ماژول خاص به آن‌ها تکیه دارد و منابع موجودی که در اختیار ماژول‌های دیگر قرار می‌دهد، و همچنین ابرداده‌هایی مانند ماژول‌ها. اقدامات مدل، نمایش و سرور (عملکردهایی برای درخواست های HTTP برای برقراری ارتباط با سرور).

“زمینه داده” نیروی اصلی است که باعث می شود داده ها در برنامه های کاربردی فرانت اند جریان یابد، که بعدا توضیح داده خواهد شد.

زمینه داده

قبل از ادامه دادن به «زمینه داده»، درک «نمایش ظاهر از منظر داده» که در «سیستم اجزای رابط کاربری در پروژه‌های فرانت‌اند» ذکر شده است، ضروری است.

“زمینه داده” بیشتر به “متن زمینه” و “زمینه جستجو” تقسیم می شود و بسته به پیچیدگی کل سیستم، می توان آنها را به “زمینه میدان” و “زمینه فیلتر” تقسیم کرد. در واقع، «زمینه جستجو» را می توان یک «مشاهده زمینه» تخصصی برای جمع آوری شرایط فیلتر کردن داده های فهرست در نظر گرفت.

انتزاع “ارزش”

ویژگی مشترک «زمینه‌های داده» مختلف، عملیات روی «ارزش‌ها» است، بنابراین می‌توان برخی انتزاع‌ها را حول «ارزش‌ها» انجام داد.

بر اساس استفاده از آنها، سه حالت از “ارزش ها” وجود دارد – “مقدار فعلی” که همیشه فعال است، که توسط value; «مقدار اولیه» و «مقدار پیش‌فرض» که برای تخصیص در هنگام تنظیم اولیه و بازنشانی استفاده می‌شود، نشان داده شده توسط initialValue و defaultValueبه ترتیب.

معنای “مقدار فعلی” در زمینه های مختلف داده متفاوت است. به عنوان مثال، در زمینه نمای شی، به مجموعه ای از جفت های کلید-مقدار فیلد که با عملیات کاربر تغییر می کنند، اشاره دارد، در حالی که در زمینه نمای لیست، به رکوردهای انتخاب شده اشاره دارد.

در کاربردهای عملی، تفاوت اصلی بین «مقدار اولیه» و «مقدار پیش‌فرض» اولویت است. «مقدار اولیه» اولویت بالاتری نسبت به «مقدار پیش‌فرض» دارد، به این معنی که «مقدار پیش‌فرض» تنها در صورت عدم وجود «مقدار اولیه» استفاده می‌شود.

اساساً فقط چهار عملیات مربوط به “مقدارها” وجود دارد که خواندن و نوشتن “مقدار فعلی” با آن است getValue() و setValue()، انتقال “مقدار فعلی” به بیرون/بالا با submit()، و بازیابی “مقدار فعلی” به “مقدار اولیه” یا “مقدار پیش فرض” با reset().

بر این اساس، چهار “رویداد” برای همگام سازی داده های خارجی در زمان های مختلف وجود دارد-the ready رویدادی که نشان می دهد داده ها آماده هستند. را change رویدادی که با هر تغییر “مقدار فعلی” ایجاد می شود. و مربوطه submit و reset رویدادهایی که هنگام تماس فعال می شوند submit() یا reset().

در رابطه با ready رویداد، یک مورد استفاده وجود دارد: پس از بارگیری صفحه وب، داده‌های فهرست باید منتظر باشند تا شرایط فیلتر قبل از درخواست برای دریافت آن جمع‌آوری شود، اما شرایط فیلتر باید ابتدا از پارامترهای پرس و جو URL بازیابی شود. برای گوش دادن به آن، به نمای لیست نیاز دارد ready رویداد زمینه جستجو را برای دریافت درخواست درخواست کنید.

اعتبارسنجی “ارزش”

برای اطمینان از ایمنی و خلوص داده‌ها، انجام بررسی‌های قانونی یا اعتبار قبل از پردازش داده‌ها یک عملیات اساسی است، بنابراین هنگام تماس، یک بررسی داخلی وجود خواهد داشت. setValue().

اعتبارسنجی «ارزش‌ها» اساساً اجرای محدودیت‌های مختلف بر اساس اولویت است. این بدان معناست که محدودیت ها را می توان به صراحت تعریف کرد و قابل توسعه هستند.

محدودیت‌های «ارزش‌ها» را می‌توان به محدودیت‌های طبیعی از انواع داده‌ها و ساختارها، و محدودیت‌های غیرطبیعی که از روابط مدل و قوانین تجاری منشأ می‌گیرد، تقسیم کرد. اصطلاح “طبیعی” در اینجا صرفاً از منظر ویژگی های داده است.

خلاصه

وقتی اصطلاح “کاربرد” به میان می آید، اولین واکنش بسیاری از مردم این است: “این چیز بسیار سنگین و عظیم است!” در ذهن آنها مانند سنگ بزرگ کوه پنج عنصر است که بر روی سان ووکانگ فشار آورده است.

با این حال، دیدگاه بهتر این است که «کاربرد» را ترکیبی از «رابط» و «پیاده‌سازی» ببینیم. به‌طور دقیق‌تر، ممکن است یک «خط تولید» و «مواد» باشد – بخش‌هایی را که احتمال تغییر کمتری دارند و دارای روابط و قوانین نسبتاً ثابتی هستند، تعمیم داده و به هم متصل می‌کند و آنها را به هم متصل می‌کند تا یک «خط تولید» را تشکیل دهد. قطعاتی که احتمال تغییر آنها بیشتر است به عنوان “مواد” در “خط تولید” جریان دارند.

همانطور که در پایان “سیستم اجزای رابط کاربری در پروژه های فرانت اند” گفتم-

در حالت ایده‌آل، مشخص می‌شود که – به جز منطق تجاری، به نظر می‌رسد که تقریباً تمام بخش‌های دیگر رابط (رابط) هستند – پیاده‌سازی خاص را می‌توان خودسرانه حذف کرد و آزادانه جایگزین کرد!

اورای سیستم اجزای رابط کاربری در پروژه‌های فرانت‌اند

بدون توضیح بیشتر، توضیحات بالا ممکن است کمی گیج کننده باشد-

در یک اپلیکیشن frontend میانی، قابل تغییرترین بخش‌ها منطق تجاری و طراحی رابط کاربری است، در حالی که کمترین تغییر، محدودیت‌های طبیعی «ارزش‌ها»، روابط ذاتی بین «نما» و «فیلدها» و ویژگی‌ها و رویدادها هستند. از کنترل ها

سیستمی بسازید که در آن قسمت‌های قابل تغییر تبدیل به ابرداده یا پیکربندی‌هایی شوند که به‌عنوان «مواد» وجود دارند، و زمینه‌های به هم پیوسته به «خط تولید» تبدیل شوند.