آشنایی با تازه های انگولار ۱۰ — راهنمای کاربردی

۱۲۳ بازدید
آخرین به‌روزرسانی: ۱۱ شهریور ۱۴۰۲
زمان مطالعه: ۷ دقیقه
آشنایی با تازه های انگولار ۱۰ — راهنمای کاربردی

نسخه جدید انگولار (Angular) یعنی نسخه 10 به تازگی منتشر شده است. با این که به نظر می‌رسد این نسخه و تغییراتش چندان تأثیرگذار نیستند، اما این انتشار نشان می‌دهد که تیم انگولار متعهد است که این فریمورک را به‌روز و آماده نگهداری کند. در این مطلب با تازه های انگولار 10 آشنا خواهیم شد. به این منظور در ادامه به توضیح تغییرهای عمده، تغییرهای ناسازگار و همچنین موارد منسوخ و حذف شده از انگولار می‌پردازیم.

ابتدا و در این بخش مواردی را که در نسخه جدید انگولار دچار تغییرهای عمده شده‌ا‌ند، مورد بررسی قرار می‌دهیم.

پشتیبانی از تایپ اسکریپت 3.9 (تغییر ناسازگار)

انگولار 9 به همراه پشتیبانی از تایپ اسکریپت 3.7 انتشار یافته است. در ادامه تایپ اسکریپت 3.8 انتشار یافت که انگولار 9.1 از آن پشتیبانی می‌کرد. طولی نکشید که نسخه دیگری از تایپ اسکریپت یعنی نسخه 3.9 معرفی شد و اینک انگولار 10 نه تنها از این نسخه از تایپ اسکریپت، بلکه از TSLib و TSLint نیز پشتیبانی می‌کند.

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

نسخه‌های قبلی تایپ اسکریپت دیگر در انگولار پشتیبانی نمی‌شوند، از این رو باید نسخه 3.9 را در پروژه خود نصب کنید. احتمالاً دلیل این موضوع چیزی است که در ادامه توضیح خواهیم داد.

فایل‌‌های tsconfig.json استایل Solution

فایل tsconfig.json استایل Solution با نسخه 3.9 تایپ اسکریپت معرفی شده است تا بتوانیم بر مشکلات حضور فایل tsconfig.json صرفاً برای ارجاع به فایل‌های دیگر tsconfig.json که به نام solution خوانده می‌شود، غلبه کنیم. انگولار 10 از این مفهوم بهره گرفته و پشتیبانی IDE را بهبود داده است. در نتیجه تجربه کاربری توسعه‌دهندگان نیز ارتقا یافته است.

یک فایل جدید به نام tsconfig.base.json معرفی شده است که شامل محتوای فایل tsconfig.json روت پیش از انتقال به فایل جدید است. برای کسب اطلاعات بیشتر در مورد پیکربندی soloution به این صفحه (+) مراجعه کنید، اما به طور خلاصه باید گفت که tsconfig.json جدید در سطح ریشه، پیش و پس از افزودن یک کتابخانه به پروژه به صورت‌های زیر است:

پیش از اضافه کردن کتابخانه

1{
2  "files": [],
3  "references": [
4    {
5      "path": "./tsconfig.app.json"
6    },
7    {
8      "path": "./tsconfig.spec.json"
9    },
10    {
11      "path": "./e2e/tsconfig.json"
12    }
13  ]
14}

پس از اضافه کردن کتابخانه

1{
2  "files": [],
3  "references": [
4    {
5      "path": "./tsconfig.app.json"
6    },
7    {
8      "path": "./tsconfig.spec.json"
9    },
10    {
11      "path": "./e2e/tsconfig.json"
12    },
13    {
14      "path": "./projects/core/tsconfig.lib.json"
15    },
16    {
17      "path": "./projects/core/tsconfig.spec.json"
18    }
19  ]
20}

اگر با استفاده از دستور ng update به انگولار 10 آپدیت کرده باشید، CLI فضای کاری شما را به این ساختار انتقال می‌دهد و نسخه‌های قبلی تایپ اسکریپت از استایل soloution پشتیبانی نمی‌کردند، از این رو این احتمالاً پاسخ تغییر ناسازگاری است که در بخش قبلی اشاره کردیم.

تغییرهای فرمت پکیج انگولار و esm5/fesm5

فرمت پکیج انگولار در نسخه 10 تغییر یافته است و فرمت جدید دیگر شامل توزیع‌های esm5 و fesm5 نیست. پکیج‌های انگولار آن‌ها را شامل نمی‌شوند. از آنجا که انگولار کد ES5 را از ES2015 تولید می‌کند و ES2015 سطح زبان پیش‌فرض مورد استفاده ابزارهای انگولار است، این توزیع‌های کد دیگر منسوخ شده‌اند. تغییرهای فرمت به شرح زیر است.

پیش از انگولار 10

1{
2  ...
3  "main": "bundles/abp-ng.core.umd.js",
4  "module": "fesm5/abp-ng.core.js",
5  "es2015": "fesm2015/abp-ng.core.js",
6  "esm5": "esm5/abp-ng.core.js",
7  "esm2015": "esm2015/abp-ng.core.js",
8  "fesm5": "fesm5/abp-ng.core.js",
9  "fesm2015": "fesm2015/abp-ng.core.js",
10  ...
11}
12{
13  ...
14  "main": "bundles/abp-ng.core.umd.js",
15  "module": "fesm2015/abp-ng.core.js",
16  "es2015": "fesm2015/abp-ng.core.js",
17  "esm2015": "esm2015/abp-ng.core.js",
18  "fesm2015": "fesm2015/abp-ng.core.js",
19  ...
20}

پس از انگولار 10

1{
2  ...
3  "main": "bundles/abp-ng.core.umd.js",
4  "module": "fesm2015/abp-ng.core.js",
5  "es2015": "fesm2015/abp-ng.core.js",
6  "esm2015": "esm2015/abp-ng.core.js",
7  "fesm2015": "fesm2015/abp-ng.core.js",
8  ...
9}

اگر اپلیکیشن شما به esm5/fesm5 وابسته است، جای نگرانی نیست، زیرا سیستم بیلد همچنان می‌تواند آن‌ها را مورد استفاده قرار دهد. به طور مشابه لازم نیست در مورد این که آیا کتابخانه انگولار شما به همراه esm2015 یا fesm2015 عرضه نمی‌شود، نگران باشید، زیرا CLI از گزینه‌های دیگر بهره می‌گیرد. با این حال به منظور بهینه‌سازی باندل و سرعت بیلد بهتر است خروجی‌های ES2015 عرضه کنید.

Browserlist

انگولار باندل‌ها را بر مبنای پیکربندی Browserlist ارائه می‌کند که در پوشه ریشه اپلیکیشن قرار دارد. انگولار 10 به دنبال فایلی به نام ‎.browserlistrc در اپلیکیشن شما می‌گردد، اما در صورتی که پیدا نکند از browserlist استفاده خواهد کرد. دستور ng update نام فایل را برای شما تغییر می‌دهد.

 تازه های انگولار 10

تغییرهای ناسازگار

در این بخش برخی تغییرهای که در انگولار 10 ایجاد شده و موجب ایجاد ناسازگاری با نسخه‌های قبل شده‌اند را معرفی می‌کنیم.

  • Resolver-هایی که مقدار EMPTY بازگشت می‌دهند موجب لغو ناوبری می‌شوند. برای این که به روتر امکان بدهیم تا به ناوبری روی مسیر ادامه بدهد، باید برخی مقادیر از قبیل of(null) صادر کنیم.
  • لاگ کردن اتصال‌های مشخصه‌های ناشناس یا نام‌های عناصر در قابل‌ها به سطح Error افزایش یافته است. تا پیش از این در سطح Warning قرار داشت. این تغییر ممکن است روی ابزارهایی که انتظار لاگ Error را ندارند، تأثیر بگذارد.
  • بازگشت دادن مقدار Null از UrlMatcher سابق بر این ممکن بود خطای زیر را تولید کند:
Type 'null' is not assignable to type 'UrlMatchResult'
  • اینک این مورد اصلاح شده است، اما نوع بازگشتی اکنون می‌تواند null نیز باشد.
  • فرم‌های واکنشی یک باگ دارند که موجب می‌شوند valueChanges که به فیلدهای ورودی با نوع number اتصال یافته‌اند، دو بار اجرا شوند. برای اصلاح این مشکل در نسخه 10 انگولار رویداد شنونده از change به input تغییر یافته است.
  • اعتبارسنج‌های minLength و maxLength تنها در صورتی تأیید می‌شوند که مقدار مورد نظر دارای مشخصه length عددی باشد.
  • در نسخه‌های قبلی در زمان تشخیص گستره روز با استفاده از ()formatDate یا DatePipe و کد فرمت b یا B یک باگ وجود داشت. اکنون این باگ اصلاح شده است و خروجی برای نمونه اینک به جای AM به صورت at night است.
  • نماهای جاسازی‌شده (یعنی نماهایی که در یک کامپوننت اعلان و در دیگری درج شده‌اند) سابقاً دارای مشکلات تشخیص بودند، اما اکنون این باگ رفع شده است. اینک از تشخیص و جداسازی و تشخیص مجدد جلوگیری می‌شود.

 تازه های انگولار 10

موارد منسوخ و حذف شده در انگولار ۱۰

در این بخش برخی مواردی که در نسخه 10 انگولار منسوخ و یا به کلی حذف شده‌اند را معرفی می‌کنیم.

ModuleWithProviders بدون یک نوع ژنریک (حذف شده)

نسخه‌های قبلی انگولار امکان کامپایل متد‌های استاتیک با بازگشتی از نوع ModuleWithProviders را بدون استفاده از نوع ژنریک یعنی ModuleWithProviders<SomeModule>‎ داشتند، زیرا فایل‌های metadata.json تولید شده، اطلاعات مورد نیاز برای کامپایل را داشتند. پس از Ivy از آنجا که metadata.json لازم نیست، انگولار نوع ژنریک را برای اعتبارسنجی نوع بررسی می‌کند.

پیش از نسخه 10

1@NgModule({...})
2export class SomeModule {
3  static forRoot(): ModuleWithProviders {
4    return {
5      ngModule: SomeModule,
6      providers: [...]
7    };
8  }
9}

پس از نسخه 10

1@NgModule({...})
2export class SomeModule {
3  static forRoot(): ModuleWithProviders<SomeModule> {
4    return {
5      ngModule: SomeModule,
6      providers: [...]
7    };
8  }
9}

ModuleWithProviders بدون نوع ژنریک قبل از نسخه 10 منسوخ شده بود و اینک به کلی حذف شده است.

کلاس‌های مبنای غیر تزیینی (حذف شده)

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

تزریق وابستگی

1@Directive()
2export abstract class AbstractSome {
3  constructor(@Inject(LOCALE_ID) public locale: string) {}
4}
56@Component({
7  selector: 'app-some',
8  template: 'Locale: {{ locale }}',
9})
10export class SomeComponent extends AbstractSome {}

در کد فوق، کامپایلر انگولار 10 در صورت فقدان دکوراتور Directive خطایی به صورت زیر صادر می‌کند:

The component SomeComponent inherits its constructor from AbstractSome, but the latter does not have an Angular decorator of its own. Dependency injection will not be able to resolve the parameters of AbstractSome's constructor. Either add a @Directive decorator to AbstractSome, or add an explicit constructor to SomeComponent.

دکوراتور

1@Directive()
2export abstract class AbstractSome {
3  @Input() x: number;
4}
56@Component({
7  selector: 'app-some',
8  template: 'Value of X: {{ x }}',
9})
10export class SomeComponent extends AbstractSome {}

کامپایلر انگولار 10 این بار خطایی مفصلی صادر می‌کند:

Class is using Angular features but is not decorated. Please add an explicit Angular decorator.

بدیهی است که این کار معقولی نیست، اما اگر یک دکوراتور Component را روی والد قرار داده باشید و دکوراتور را در فرزند حذف کنید، مطابق انتظار کامپایلر انگولار 10 خطای زیر را صادر می‌کند:

The class 'SomeComponent' is listed in the declarations of the NgModule 'AppModule', but is not a directive, a component, or a pipe. Either remove it from the NgModule's declarations, or add an appropriate Angular decorator.

WrappedValue (منسوخ شده)

WrappedValue اینک منسوخ شده است و احتمالاً در نسخه 12 انگولار حذف خواهد شد. اگر تاکنون در مورد آن اطلاعاتی نداشتید، پیشنهاد می‌کنیم این صفحه (+)‌ و این صفحه (+) را مطالعه کنید.

تحریک شناسایی تغییر در زمانی که همان وهله شیء تولید/صادر می‌شود، ‌کاری مفید است. زمانی که WrappedValue استفاده می‌شود، این کار یک هزینه عملکردی دارد و مواردی هم که این کار به ما کمک می‌کند نسبتاً نادر است، از این رو تیم انگولار تصمیم گرفته است که این امکان را منسوخ کند.

یکی از عوارض جانبی این منسوخ شدن آن است که خطاهای ExpressionChangedAfterItHasBeenChecked را اینک بیش از پیش خواهید دید، زیرا انگولار در مواردی که WrappedValues به صورت برابر ارزیابی شود، خطایی صادر نمی‌کند.

در مواردی که با مشکلات شناسایی مواجه شدید، تلاش کنید شیء را کلون کرده و یا شناسایی تغییر را به صورت دستی از طریق متدهای markForCheck یا detectChanges از ChangeDetectorRef اجرا کنید.

موارد دیگر منسوخ و حذف شده در انگولار ۱۰

  • پشتیبانی از IE9، IE10 و IE Mobile منسوخ شده است و در ادامه حذف خواهد شد. دلیل اصلی این مسئله افزایش اندازه باندل و پیچیدگی آن است. با در نظر گرفتن این که حتی مایکروسافت نیز پشتیبانی از مرورگرها را حذف کرده است، ‌این کار معنی بیشتری می‌یابد.
  • انگولار پاکسازی اتصال‌های مشخصه استایل را متوقف کرده است. دلیل این مسئله عدم پشتیبانی از مرورگرهای قدیمی (مانند IE6 و IE7) و هزینه عملکردی داشتن این کارکرد بوده است.
  • شماتیک‌های بیلد Bazel ادامه نخواهند یافت. تیم انگولار دلایل این مسئله را در این صفحه (+) توضیح داده است و در صورتی که علاقه‌مند به ساخت انگولار با Bazel باشید پیشنهاد کرده‌اند این ریپازیتوری (+) را دنبال کنید.

سخن پایانی

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

بر اساس رای ۱ نفر
آیا این مطلب برای شما مفید بود؟
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.
منابع:
volosoft
نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *