بررسی برخی تغییرات در Angular 8
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: یک دقیقه

تغییر loadChildren در نسخه 8
در نسخه 8، استفاده از syntax رشته‌ای برای loadChildren  در lazy loading، منسوخ شده‌است:
const routes: Routes = [{
  path: 'lazy',
  // The following string syntax for loadChildren is deprecated
  loadChildren: './lazy/lazy.module#LazyModule'
}];
و بجای آن  از syntax جدید `()import` استفاده می‌شود:
const routes: Routes = [{
  path: 'lazy',
  // The new import() syntax
  loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule)
}];
در زمان بروزرسانی به نسخه 8، دستور ng update، عمل تبدیل مسیرهای loadChildren به syntax جدید را به طور خودکار انجام می‌دهد.

import مجزای component‌‌های Material
اگر ازAngular Material استفاده می‌کنید باید Component ‌های مورد استفاده را بطور مجزا import کنید. به عنوان مثال اگر از button استفاده کرده‌اید، باید @angular/material/button را import  کنید . البته در اینجا نیز دستور ng update این کار را بطور خودکار انجام می‌دهد.

بهبود CLI با تولید بسته‌های متفاوت ES 5 و ES 6
در نسخه 8، دستور build ارائه شده توسط CLI می‌تواند دو خروجی متفاوت با  ES2015 مخصوص مرورگرهای جدید را با حداقل polyfills و ES5 سازگار با مرورگرهای قدیمی را بدهد. در صورتی که بخواهیم build سازگاری با نسخه‌های  قدیمی داشته باشیم، می‌توانیم گزینه target در فایل tsconfig.json را به ES5 تغییر دهیم. 
برای بروزرسانی پروژه‌های جاری خود می‌توانید از ابزار کمکی ارائه شده توسط تیم angular استفاده کنید. 
 
روش فعالسازی کامپایلر جدید Angular
برای ساخت پروژه‌ای با قابلیت استفاده از ivy compiler می‌توانیم از دستور زیر استفاده کنیم:
ng new angularProjectName --enable-ivy
توجه داشته باشید نیاز است nodejs نسخه 10.9 یا 10.9 به بعد نصب باشد. 
پس از ساخت پروژه قسمتی با نام angularCompilerOptions  در فایل tsconfig.json مشاهد می‌شودکه نشان دهنده‌ی فعال بودن کامپایلر ivy است:
"angularCompilerOptions": {
    "enableIvy": true
  }
  • #
    ‫۵ سال و ۲ ماه قبل، یکشنبه ۲ تیر ۱۳۹۸، ساعت ۲۲:۲۲
    TypeScript 3.4.x Support
    انگیولار 8، از (3.4) typescript و نگارش‌های بالاتر پشتیبانی می‌کند. اگر می‌خواهیم از انگیولار 8 برای App ‌های جدید استفاده کنیم، نیاز است typescript را به نگارش 3.4 و یا بالاتر ارتقاء دهیم.

    Ivy Rendering Engine
    یکی از مهمترین و مورد انتظارترین ویژگی‌های انگیولار 8، موتور IVY می‌باشد. IVY یک Angular Compiler جدید می‌باشد و هم چنین یک ابزار که به عنوان یک rendering pipeline جدید عمل می‌کند. مزیت Ivy این است که به طور قابل توجهی bundle‌های کوچکی را تولید می‌کند (سایز bundle‌ها را کاهش میدهد)  و همچنین به آسانی می‌تواند کامپایل سریعی را انجام دهد. بنابراین Ivy، اساس نوآوری در دنیای انگیولار می‌باشد. Ivy در انگیولار 8 به صورت پیش نمایشی می‌باشد. هدف اصلی این نسخه این است که بازخورد‌ها را از جامعه توسعه دهندگان انگیولار، مرتبط با Ivy دریافت کند. پیشنهاد شده است که در این روزها از Ivy برای حالت ارائه‌ی نهایی (Production) استفاده نشود.


    در ngconf  سال  2019، (Brad Green)، هدایت کننده فنی تیم انگیولار گفت که در صورت استفاده از Ivy، از مزایای زیر برخوردار هستیم: 

    • کامپایل سریعتری را فراهم می‌کند (انتشار در انگیولار  9) 
    • بررسی type  در قالب‌ها، خیلی بیشتر بهبود یافته است؛ به‌گونه‌ای که می‌توان خطاهای بیشتری را در زمان build گرفت که باعث می‌شود کاربران در زمان runtime به آن خطاها برخورد نکنند (انتشار در انگیولار 9). 
    • bundle‌های با سایز کوچکتری در مقایسه با سایز bundle‌های کامپایل شده‌ی جاری 
    • کد‌های تولید شده توسط  Angular compiler، بسیار آسان‌تر، برای خواندن و درک انسان است. 
    • آخرین و مهمترین ویژگی مورد علاقه من این است که می‌توان قالب‌ها (templates) را debug کرد. من یقین دارم که این ویژگی توسط تعداد زیادی از توسعه دهندگان مورد توجه قرار خواهد گرفت .
    همانطور که در متن بالا گفته شده است اگر بخواهید در یک پروژه‌ی انگیولار، Ivy  را شامل کنید، علاوه بر حالت گفته شده‌ی در متن‌، می‌توانید به صورت دستی تنظیم بالا را به پروژه‌ی انگیولار اضافه کنید (بعد از ارتقاء به انگیولار 8). پیشنهاد شده‌است که اگر می‌خواهیم از Ivy  در Application ‌ها استفاده کنیم، Application را در حالت debug، همراه با AOT compilation اجرا کنید:
    ng serve --aot

    Bye Bye @angular/http
    از نگارش 8 انگیولار، پشتیبانی از angular/http@ متوقف می‌شود. تا نگارش 7 انگیولار، امکان استفاده‌ی از angular/http@ برای ما فراهم بود؛ اما استفاده‌ی از angular/http@ منسوخ شده بود و در نگارش 4 انگیولار یک فراخوانی امن و کارآمد HTTP را با استفاده از  angular/common/http@  فراهم کردند. 

    PNPM Support
    در نگارش 8 انگیولار، پشتیبانی از یک package manager جدید به نام PNPM وجود دارد که شامل NPM و Yarn می‌باشد.

    Support for New Builders/Architect API
    نگارش جدید Angular CLI  این اجازه را به ما می‌دهد که از نسخه‌ی جدید Builders که به عنوان Architect API شناخته می‌شود، استفاده کنیم. انگیولار از Builders API برای اجرای  عملیاتی مثل server, build, test, lint و e2e استفاده می‌کند. در ضمن می‌توانیم از builders در فایل angular.json استفاده کنیم: 
    "projects": {  
      "app-name": {  
        "architect": {  
          "build": {  
            "builder": "@angular-devkit/build-angular:browser",  
          },  
          "serve": {  
            "builder": "@angular-devkit/build-angular:dev-server",  
          },  
          "test": {  
            "builder": "@angular-devkit/build-angular:karma",  
          },  
          "lint": {  
            "builder": "@angular-devkit/build-angular:tslint",  
          },  
          "e2e": {  
            "builder": "@angular-devkit/build-angular:protractor",  
          }  
        }  
      }  
    }
  • #
    ‫۵ سال و ۲ ماه قبل، دوشنبه ۳ تیر ۱۳۹۸، ساعت ۲۰:۴۳
    در نگارش 8 انگیولار، در زمان تعریف ViewChild@ و ContentChild@، اجبار است که یک static flag را مشخص کنیم. در صورتیکه مقدارش true باشد، انگیولار تلاش خواهد کرد که در زمان initialization کامپوننت، آن را پیدا کند (مثلا ngOnInit) و زمانیکه مقدار آن false باشد، انگیولار بعد از initialization مربوط به View، آن را پیدا خواهد کرد.  
    قبل از نگارش 8 انگیولار:
    @ViewChild(‘input1’) demoInput:ElementRef;
    
    getValueOfElement(){  
       Console.log(this.demoInput.nativeElement.value);  
    }
      نگارش 8 انگیولار:
    @ViewChild(‘input1’,{ static : false }) demoInput:ElementRef; 
    getValueOfElement(){  
       Console.log(this.demoInput.nativeElement.value);  
    }
    برای  ViewChildren@ و ContentChildren@  نیازی به تعریف static flag نیست.  
    همانطور که در متن هم ذکر شده‌است، دستور ng update، عمل تبدیل مسیرهای loadChildren را به syntax جدید، به طور خودکار انجام می‌دهد؛ ولی برای ViewChild@ و ContentChild@ تغیری صورت نمی‌گیرد و باید به صورت دستی انجام گیرد.