مدیریت پیچیدگی

ساده نگه داشتن یک برنامه وب می تواند به طرز شگفت آوری پیچیده باشد. در این ماژول، شما یاد خواهید گرفت که چگونه API های وب با threading کار می کنند و چگونه می توانید از آن برای الگوهای رایج PWA مانند مدیریت حالت استفاده کنید.

ریچ هیکی در سخنرانی خود Simple Made Easy کیفیت چیزهای ساده در مقابل پیچیده را مورد بحث قرار می دهد. او چیزهای ساده را اینگونه توصیف می کند:

"یک نقش، یک وظیفه، یک مفهوم یا یک بعد."

اما تأکید می کند که سادگی به این معنا نیست:

"داشتن یک نمونه یا انجام یک عملیات."

ساده بودن یا نبودن چیزی به ارتباط آن بستگی دارد.

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

سادگی در توسعه نرم افزار ضروری است زیرا درک و نگهداری کد ساده آسان تر است. سادگی برای برنامه های وب نیز ضروری است، زیرا ممکن است به سریع و در دسترس بودن برنامه ما در هر زمینه ممکن کمک کند.

مدیریت پیچیدگی PWA

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

موضوع اصلی این است:

  • مسئول ترسیم صفحه است که خود یک فرآیند پیچیده و چند مرحله ای است که شامل محاسبه سبک ها، به روز رسانی و ترکیب لایه ها و رنگ آمیزی به صفحه است.
  • مسئول گوش دادن و واکنش به رویدادها، از جمله رویدادهایی مانند اسکرول.
  • مسئول بارگذاری و تخلیه صفحه.
  • مدیریت رسانه، امنیت و هویت. این همه قبل از اجرای هر کدی است که می نویسید در آن رشته، مانند:
  • دستکاری DOM
  • دسترسی به APIهای حساس، برای مثال، قابلیت‌های دستگاه، یا رسانه/امنیت/هویت.

همانطور که سورما در سخنرانی خود در اجلاس Chrome Dev Summit در سال 2019 بیان کرد، موضوع اصلی بیش از حد کار شده و دستمزد کمتری دریافت می‌کند.

و با این حال، اکثر کدهای برنامه در موضوع اصلی نیز زندگی می کنند.

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

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

خبر بد؟ افزودن پیچیدگی به موضوع اصلی یک راه تقریباً مطمئن برای دشوار کردن رسیدن به این اهداف است. خبر خوب؟ زیرا آنچه موضوع اصلی باید انجام دهد واضح است: می توان از آن به عنوان راهنمایی برای کمک به کاهش اتکا به آن برای بقیه برنامه استفاده کرد.

جداسازی نگرانی ها

انواع مختلفی از کارها وجود دارد که برنامه های کاربردی وب انجام می دهند، اما به طور کلی، می توانید آن را به کارهایی تقسیم کنید که مستقیماً رابط کاربری را لمس می کنند و کارهایی که انجام نمی دهند. کار رابط کاربری کاری است که:

  • مستقیماً DOM را لمس می کند.
  • از APIهایی استفاده می کند که قابلیت های دستگاه، به عنوان مثال، اعلان ها یا دسترسی به سیستم فایل را لمس می کنند.
  • هویت، به عنوان مثال، کوکی‌های کاربر، محلی یا ذخیره‌سازی جلسه را لمس می‌کند.
  • رسانه ها، به عنوان مثال، تصاویر، صدا، یا ویدئو را مدیریت می کند.
  • دارای پیامدهای امنیتی است که برای تایید آنها نیاز به مداخله کاربر دارد، مانند API سریال وب.

کارهای غیر UI می تواند شامل موارد زیر باشد:

  • محاسبات محض
  • دسترسی به داده ها (fetch، IndexedDB، و غیره).
  • رمزنگاری.
  • پیام رسانی.
  • ایجاد لکه یا جریان، یا دستکاری.

کارهای غیر UI اغلب توسط کار UI رزرو می شود: کاربر روی دکمه ای کلیک می کند که یک درخواست شبکه برای یک API ایجاد می کند که نتایج تجزیه شده را برمی گرداند و سپس برای به روز رسانی DOM استفاده می شود. هنگام نوشتن کد، این تجربه انتها به انتها اغلب در نظر گرفته می شود، اما جایی که هر بخش از آن جریان معمولاً در آن زندگی نمی کند. مرزهای بین کار UI و کار غیر UI به اندازه تجربیات انتها به انتها مهم هستند، زیرا اولین جایی هستند که می توانید پیچیدگی رشته اصلی را کاهش دهید.

روی یک کار واحد تمرکز کنید

یکی از ساده‌ترین راه‌ها برای ساده‌سازی کد، شکستن توابع است تا هر کدام بر روی یک کار واحد تمرکز کنند. وظایف را می توان با مرزهای شناسایی شده با قدم زدن در تجربه انتها به انتها تعیین کرد:

  • ابتدا به ورودی کاربر پاسخ دهید. این کار رابط کاربری است.
  • بعد، یک درخواست API ایجاد کنید. این کار غیر UI است.
  • سپس درخواست API را تجزیه کنید. این دوباره کار غیر UI است.
  • سپس، تغییرات DOM را تعیین کنید. این ممکن است کار UI باشد، یا اگر از چیزی مانند پیاده سازی DOM مجازی استفاده می کنید، ممکن است کار UI نباشد.
  • در نهایت تغییراتی در DOM ایجاد کنید. این کار رابط کاربری است.

اولین مرزهای مشخص بین کار UI و کار غیر UI است. سپس فراخوانی قضاوتی وجود دارد که باید انجام شود: آیا ساختن و تجزیه درخواست API یک یا دو کار است؟ اگر تغییرات DOM کارهای غیر UI هستند، آیا با کار API همراه هستند؟ در همین تاپیک؟ در یک تاپیک متفاوت؟ سطح مناسب تفکیک در اینجا برای ساده‌سازی پایگاه کد شما و همچنین امکان انتقال موفقیت‌آمیز تکه‌هایی از آن به خارج از رشته اصلی کلیدی است.

ترکیب پذیری

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

  • دسته بندی انواع کارهایی که اپلیکیشن شما انجام می دهد.
  • ایجاد رابط های ورودی و خروجی مشترک برای آنها.

به عنوان مثال، تمام وظایف بازیابی API در نقطه پایانی API قرار می گیرند و آرایه ای از اشیاء استاندارد را برمی گردانند، و همه توابع پردازش داده آرایه ای از اشیاء استاندارد را دریافت کرده و برمی گرداند.

جاوا اسکریپت دارای یک الگوریتم کلون ساخت یافته برای کپی کردن اشیاء پیچیده جاوا اسکریپت است. کارگران وب هنگام ارسال پیام از آن استفاده می کنند و IndexedDB از آن برای ذخیره اشیا استفاده می کند. انتخاب رابط‌هایی که می‌توانید با الگوریتم شبیه‌سازی ساختاریافته استفاده کنید، آنها را برای اجرا انعطاف‌پذیرتر می‌کند.

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

با در دست داشتن کدهای قابل ترکیب، زمان آن رسیده است که بخشی از آن را از موضوع اصلی حذف کنید.

استفاده از وب کارگران برای کاهش پیچیدگی

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

کارگران وب به یک PWA اجازه می دهند (برخی) جاوا اسکریپت را خارج از رشته اصلی اجرا کنند.

سه نوع کارگر وجود دارد.

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

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

برای مثال، یک کارگر اشتراکی می‌تواند دسترسی و تراکنش‌ها را برای IndexedDB یک PWA مدیریت کند و نتایج تراکنش‌ها را در تمام اسکریپت‌های فراخوانی پخش کند تا به آنها اجازه دهد به تغییرات واکنش نشان دهند.

وب کارگر نهایی یکی از مواردی است که به طور گسترده در این دوره پوشش داده شده است: کارگران خدمات ، که به عنوان یک پروکسی برای درخواست های شبکه عمل می کنند و بین تمام نمونه های یک PWA به اشتراک گذاشته می شوند.

خودت آن را امتحان کن

زمان کد است! بر اساس همه چیزهایی که در این ماژول آموخته اید یک PWA از ابتدا بسازید.

منابع