اولین کاری را که میتوان پس از نصب Angular CLI انجام داد، ایجاد یک برنامهی جدید است و نمونهای از آنرا در قسمت قبل بررسی کردیم. در ادامه میخواهیم به پارامترهای بیشتر مرتبط با آن و همچنین نحوهی سفارشی سازی ایجاد برنامههای جدید بپردازیم.
ایجاد برنامههای جدید توسط Angular CLI
دستور خط فرمان ابتدایی ایجاد یک برنامهی جدید توسط Angular CLI به صورت ذیل است
در اینجا ng همان Angular CLI است. new عملی است که قرار است رخ دهد و my-app یک نام دلخواه میباشد.
پس از اجرای این دستور، برنامهی جدید ایجاد شده، در پوشهی جدید my-app قرار میگیرد.
گزینهی دیگر این دستور، استفاده از پرچم dry-run است:
کار این پرچم صرفا گزارش دادن جزئیات عملیات ng new است؛ بدون اینکه فایلی را تولید کند. به این ترتیب میتوان برآوردی را از فایلهای تولید شدهی توسط فرامین ng، پیش از تولید واقعی آنها، مشاهده کرد. برای مثال:
همانطور که مشاهده میکنید، در ابتدای کار پیامی را مبنی بر عدم نوشته شدن این فایلها بر روی فایل سیستم، ارائه دادهاست.
گزینهی دیگر دستور ng new را که در قسمت قبل ملاحظه کردید:
کار پرچم skip-install عدم فراخوانی خودکار دستور npm install است که سبب خواهد شد، برنامه بدون نصب وابستگیهای npm آن، با سرعت هرچه بیشتر، ایجاد شود. از این گزینه میتوان جهت مشاهدهی ساختار فایلهای تولیدی استفاده کرد و در نهایت در این حالت باید دستور npm install را به صورت دستی فراخوانی کرد. پرچم dry-run نیز skip-install را به صورت ضمنی به همراه دارد.
برای مشاهدهی سایر پرچمهای مرتبط با دستور ng new میتوان از پرچم help استفاده کرد:
بررسی فایل angular-cli.json.
فایل angular-cli.json. حاوی تنظیمات Angular CLI است.
در ابتدای این فایل، نام برنامهی جدید را مشاهده میکنید. این نام، همانی است که توسط دستور ng new my-app تعیین گردید.
سپس محل پوشهی source برنامه و همچنین خروجی نهایی آن، مشخص میشوند:
یکی از تنظیمات مهم این فایل، مقدار prefix است:
از این مقدار برای تنظیم مقدار prefix تمام کامپوننتها و دایرکتیوهای تولیدی توسط Angular CLI استفاده میشود. برای مثال اگر به فایل src\app\app.component.ts دقت کنید:
نام selector آن با app- شروع شدهاست که این app، از مقدار prefix فایل angular-cli.json. دریافت شدهاست.
تغییر این مقدار صرفا بر روی کامپوننتهای جدید تولید شدهی توسط Angular CLI تاثیرگذار خواهند بود. اگر میخواهید در ابتدای کار تولید یک برنامه، این مقدار را مشخص کنید، میتوان از پرچم prefix استفاده کرد و در صورت عدم ذکر آن، مقدار پیش فرض app برای آن درنظر گرفته میشود:
عدم ایجاد مخزن Git به همراه ng new
با صدور فرمان ng new، کار ایجاد یک مخزن Git نیز به صورت خودکار انجام خواهد شد. برای نمونه اگر خواستید برنامهای را بدون نصب وابستگیها، بدون ایجاد تستها و بدون ایجاد مخزن git آن تولید کنید، میتوان از دستور ذیل استفاده کرد:
استفادهی از sass بجای css توسط Angular CLI
سیستم Build همراه با Angular CLI مبتنی بر webpack است و به خوبی قابلیت پردازش فایلهای sass را نیز دارا است. اگر خواستید حالت پیش فرض تولید فایلهای css این ابزار را که در فایل angular-cli.json. نمونهای از آن ذکر شدهاست، به همراه فایلهایی مانند app.component.css، به sass تغییر دهید:
تنها کافی است پرچم style را با sass مقدار دهی کرد که حالت پیش فرض آن css است:
با ذکر این پرچم، تغییرات فایل angular-cli.json به صورت ذیل خواهند بود:
و حتی کامپوننت src\app\app.component.ts نیز به همراه شیوهنامهای از نوع sass که در حین ارائه نهایی توسط webpack به صورت خودکار پردازش میشود (بدون نیاز به تنظیمات اضافهتری)، مقدار دهی شدهاست:
و یا حتی اگر علاقمند به استفادهی از less باشید نیز میتوان پرچم style less-- را استفاده نمود.
انجام تنظیمات مسیریابی پیش فرض پروژه جدید توسط Angular CLI
حالت پیش فرض تولید برنامههای جدید Angular CLI به همراه تنظیمات مسیریابی آن نیست. اگر علاقمند هستید تا مبحث مسیریابی را خلاصه کرده و به سرعت تنظیمات ابتدایی مسیریابی را توسط این ابزار تولید کنید، میتوان پرچم routing را نیز در اینجا ذکر کرد:
در این حالت اگر به پوشهی src\app مراجعه کنید، فایل جدید app-routing.module.ts را نیز مشاهده خواهید کرد که AppRoutingModule پیش فرضی در آن تنظیم شدهاست و آمادهی استفاده میباشد.
همچنین فایل app.module.ts را نیز اندکی تغییر داده و این AppRoutingModule جدید را نیز به آن معرفی کردهاست.
به این ترتیب ارتباطات ابتدایی مورد نیاز سیستم مسیریابی برقرار شده و قابل استفادهاست. بنابراین ذکر پرچم routing میتواند یکی از پرچمهای اصلی ایجاد برنامههای جدید مبتنی بر Angular CLI باشد.
اجرای ابتدایی یک برنامهی مبتنی بر Angular CLI
پس از انتخاب پرچمهای مناسب جهت ایجاد یک پروژهی جدید مبتنی بر Angular CLI و همچنین نصب وابستگیهای آنها و یا عدم ذکر پرچم skip-install، اکنون نوبت به اجرای این پروژهاست. به همین جهت از طریق خط فرمان به ریشهی پوشهی برنامهی جدید ایجاد شده، وارد شوید. سپس دستور ذیل را صادر کنید:
در اینجا o- به معنای open است؛ یا گشودن آن در یک مرورگر. به این ترتیب کار کامپایل برنامه صورت گرفته و توسط مرورگر پیشفرض سیستم به صورت خودکار باز خواهد شد. آدرس پیش فرض آن نیز به صورت ذیل است:
نکتهی جالب این وب سرور در این است که تغییرات شما را به صورت خودکار دنبال کرده و بلافاصله ارائه میدهد. برای مثال فایل src\app\app.component.html را گشوده و به صورت ذیل تغییر دهید:
پس از ذخیرهی آن، بلافاصله خروجی نهایی را در مرورگر خواهید دید.
تغییر پیش فرضهای عمومی Angular CLI
تا اینجا مشاهده کردیم که اگر بخواهیم مقدار prefix پیش فرض را که به app تنظیم شدهاست به myCompany تغییر دهیم، یا میتوان از پرچم prefix در ابتدای کار فراخوانی دستور ng new استفاده کرد و یا میتوان فایل angular-cli.json. را نیز دستی ویرایش نمود. برای تغییر عمومی و سراسری مقدار پیش فرض app میتوان از دستور ng set استفاده کرد:
دستور اول فایل angular-cli.json. پروژهی جاری را ویرایش میکند و دستور دوم، فایل angular-cli.json سراسری Angular CLI را مقدار دهی خواهد کرد (با توجه به سوئیچ g- آن). البته بدیهی است ویرایشگرهای امروزی به خوبی قابلیت ویرایش فایلهای json را ارائه میدهند و شاید نیازی به استفادهی از این دستورات،حداقل برای اعمال تغییرات محلی نباشد.
و یا اگر بخواهید نوع شیوهنامهی مورد استفاده را ویرایش کنید، میتوان از یکی از دو دستور ذیل استفاده کرد (اولی محلی است و دومی عمومی):
اجرای امکانات Linting پروژههای مبتنی بر Angular CLI
برای بررسی کیفیت کدهای نوشته شده، میتوان از امکانات Linting استفاده کرد. برای این منظور تنها کافی است دستور ذیل را در ریشهی پروژه اجرا نمود:
برای مشاهدهی تمام گزینههای آن دستور زیر را صادر کنید:
اگر علاقمند هستید تا خروجی این ابزار، با رنگهای بهتری نمایش داده شوند، میتوان از دستور ذیل استفاده کرد:
به علاوه این ابزار قابلیت رفع مشکلات را با اعمال تغییراتی در کدهای موجود نیز به همراه دارد:
برای این منظور میتوان از پرچم fix آن استفاده کرد.
یک مثال: فایل src\app\app.component.ts را باز کنید و به عمد تعدادی مشکل را در آن ایجاد نمائید. برای نمونه دو سطر ابتدایی آنرا به صورت ذیل تغییر دهید:
اکنون اگر ng lint را اجرا کنیم، به خروجی ذیل خواهیم رسید:
عنوان میکند که بهتر است number به صورت یک const تعریف شود و همچنین یک سمیکالن در سطر اول فراموش شدهاست.
اکنون اگر دستور ng lint --fix را فراخوانی کنیم، تغییرات ذیل به فایل src\app\app.component.ts اعمال خواهند شد:
به صورت خودکار، به سطر اول، یک سمیکالن را اضافه کرده و همچنین سطر دوم را نیز به const تبدیل کردهاست.
ایجاد برنامههای جدید توسط Angular CLI
دستور خط فرمان ابتدایی ایجاد یک برنامهی جدید توسط Angular CLI به صورت ذیل است
> ng new my-app
پس از اجرای این دستور، برنامهی جدید ایجاد شده، در پوشهی جدید my-app قرار میگیرد.
گزینهی دیگر این دستور، استفاده از پرچم dry-run است:
> ng new my-app --dry-run
>ng new my-app --dry-run installing ng You specified the dry-run flag, so no changes will be written. create .editorconfig create README.md create src\app\app.component.css create src\app\app.component.html . . . Project 'my-app' successfully created.
گزینهی دیگر دستور ng new را که در قسمت قبل ملاحظه کردید:
> ng new my-app --skip-install
برای مشاهدهی سایر پرچمهای مرتبط با دستور ng new میتوان از پرچم help استفاده کرد:
> ng new --help
بررسی فایل angular-cli.json.
فایل angular-cli.json. حاوی تنظیمات Angular CLI است.
در ابتدای این فایل، نام برنامهی جدید را مشاهده میکنید. این نام، همانی است که توسط دستور ng new my-app تعیین گردید.
"project": { "name": "my-app" },
"apps": [ { "root": "src", "outDir": "dist",
یکی از تنظیمات مهم این فایل، مقدار prefix است:
"prefix": "app",
@Component({ selector: 'app-root',
تغییر این مقدار صرفا بر روی کامپوننتهای جدید تولید شدهی توسط Angular CLI تاثیرگذار خواهند بود. اگر میخواهید در ابتدای کار تولید یک برنامه، این مقدار را مشخص کنید، میتوان از پرچم prefix استفاده کرد و در صورت عدم ذکر آن، مقدار پیش فرض app برای آن درنظر گرفته میشود:
> ng new my-project --skip-install --prefix myCompany
عدم ایجاد مخزن Git به همراه ng new
با صدور فرمان ng new، کار ایجاد یک مخزن Git نیز به صورت خودکار انجام خواهد شد. برای نمونه اگر خواستید برنامهای را بدون نصب وابستگیها، بدون ایجاد تستها و بدون ایجاد مخزن git آن تولید کنید، میتوان از دستور ذیل استفاده کرد:
> ng new my-project --skip-install --skip-git --skip-tests --skip-commit
استفادهی از sass بجای css توسط Angular CLI
سیستم Build همراه با Angular CLI مبتنی بر webpack است و به خوبی قابلیت پردازش فایلهای sass را نیز دارا است. اگر خواستید حالت پیش فرض تولید فایلهای css این ابزار را که در فایل angular-cli.json. نمونهای از آن ذکر شدهاست، به همراه فایلهایی مانند app.component.css، به sass تغییر دهید:
"styles": [ "styles.css" ], "defaults": { "styleExt": "css", "component": {} }
> ng new my-project --skip-install --style sass
"styles": [ "styles.sass" ], "defaults": { "styleExt": "sass", "component": {} }
@Component({ selector: 'app-root', templateUrl: './app.component.html', styleUrls: ['./app.component.sass'] })
انجام تنظیمات مسیریابی پیش فرض پروژه جدید توسط Angular CLI
حالت پیش فرض تولید برنامههای جدید Angular CLI به همراه تنظیمات مسیریابی آن نیست. اگر علاقمند هستید تا مبحث مسیریابی را خلاصه کرده و به سرعت تنظیمات ابتدایی مسیریابی را توسط این ابزار تولید کنید، میتوان پرچم routing را نیز در اینجا ذکر کرد:
> ng new my-project --skip-install --routing
const routes: Routes = [ { path: '', children: [] } ];
imports: [ BrowserModule, FormsModule, HttpModule, AppRoutingModule ],
اجرای ابتدایی یک برنامهی مبتنی بر Angular CLI
پس از انتخاب پرچمهای مناسب جهت ایجاد یک پروژهی جدید مبتنی بر Angular CLI و همچنین نصب وابستگیهای آنها و یا عدم ذکر پرچم skip-install، اکنون نوبت به اجرای این پروژهاست. به همین جهت از طریق خط فرمان به ریشهی پوشهی برنامهی جدید ایجاد شده، وارد شوید. سپس دستور ذیل را صادر کنید:
>ng serve -o
http://localhost:4200/
نکتهی جالب این وب سرور در این است که تغییرات شما را به صورت خودکار دنبال کرده و بلافاصله ارائه میدهد. برای مثال فایل src\app\app.component.html را گشوده و به صورت ذیل تغییر دهید:
<h1> Test {{title}} </h1>
تغییر پیش فرضهای عمومی Angular CLI
تا اینجا مشاهده کردیم که اگر بخواهیم مقدار prefix پیش فرض را که به app تنظیم شدهاست به myCompany تغییر دهیم، یا میتوان از پرچم prefix در ابتدای کار فراخوانی دستور ng new استفاده کرد و یا میتوان فایل angular-cli.json. را نیز دستی ویرایش نمود. برای تغییر عمومی و سراسری مقدار پیش فرض app میتوان از دستور ng set استفاده کرد:
>ng set apps.prefix myCompany >ng set apps.prefix myCompany -g
و یا اگر بخواهید نوع شیوهنامهی مورد استفاده را ویرایش کنید، میتوان از یکی از دو دستور ذیل استفاده کرد (اولی محلی است و دومی عمومی):
>ng set defaults.styleExt sass >ng set defaults.styleExt sass -g
اجرای امکانات Linting پروژههای مبتنی بر Angular CLI
برای بررسی کیفیت کدهای نوشته شده، میتوان از امکانات Linting استفاده کرد. برای این منظور تنها کافی است دستور ذیل را در ریشهی پروژه اجرا نمود:
> ng lint
> ng lint --help
> ng lint --format stylish
>ng lint --fix
یک مثال: فایل src\app\app.component.ts را باز کنید و به عمد تعدادی مشکل را در آن ایجاد نمائید. برای نمونه دو سطر ابتدایی آنرا به صورت ذیل تغییر دهید:
import { Component } from '@angular/core' let number = 10;
>ng lint --format stylish /src/app/app.component.ts[3, 5]: Identifier 'number' is never reassigned; use 'const' instead of 'let'. /src/app/app.component.ts[1, 42]: Missing semicolon Lint errors found in the listed files.
اکنون اگر دستور ng lint --fix را فراخوانی کنیم، تغییرات ذیل به فایل src\app\app.component.ts اعمال خواهند شد:
import { Component } from '@angular/core'; const number = 10;
اولین مرحلهی ارتقاء به Angular 6، به روز رسانی Angular CLI 1.x به نگارش 6 آن است. این شماره نگارش نیز با شماره نگارش Angular یکی شدهاست و دیگر 1x نیست. CLI 6.0 فقط پروژههای Angular 5.x و 6x را پشتیبانی میکند و برای نصب آن نیاز به حداقل NodeJS 8.9 و NPM 5.5 را خواهید داشت. بنابراین ابتدا دستورات زیر را صادر کرده و اگر هنوز از نگارشهای قدیمی این ابزارها استفاده میکنید، قبل از هر کاری باید آنها را به روز رسانی کنید:
این نگارش از CLI در پشت صحنه از Webpack 4 استفاده میکند که نسبت به نگارشهای پیشین آن بسیار سریعتر است، tree-shaking بهتری را انجام میدهد و در نهایت سبب تولید برنامههایی با حجم کمتر و با سرعت build بیشتری خواهد شد.
فایل پیشین angular-cli.json حذف و فایل جدید angular.json بجای آن معرفی شدهاست
یکی از مهمترین تغییرات CLI 6.0 نسبت به نگارشهای قبلی آن، پشتیبانی از چندین پروژه است و به همین منظور ساختار فایل تنظیمات آنرا به طور کامل تغییر دادهاند و اگر دستور ng new project1 را صادر کنید، دیگر از فایل پیشین angular-cli.json خبری نبوده و بجای آن فایل جدید angular.json قابل مشاهدهاست:
در اینجا ساختار ابتدای فایل angular.json را مشاهده میکنید که در آن مفهوم projects (و یا workspace در اینجا) به همراه project1 جدیدی که ایجاد کردیم، به عنوان زیر مجموعهی آن قابل مشاهدهاست.
مزیت مهم این قابلیت، امکان ایجاد libraries است که به صورت توکار از این نگارش پشتیبانی میشود و میتوان اجزایی مانند components ،directives ،pipes و services اشتراکی را در یک یا چندین کتابخانه قرار داد و سپس از آنها در پروژهی اصلی و یا چندین پروژهی متصل استفاده کرد.
نگارش 6 در پشت صحنه، پروژهی موفق ng-packagr را به مجموعهی CLI اضافه کردهاست و از این پس توسط خود CLI میتوان کتابخانههای استاندارد Angular را تولید کرد. این مورد، مزیت استاندارد سازی کتابخانههای npm حاصل را نیز به همراه دارد؛ مشکلی که گاهی از اوقات به علت عدم رعایت این ساختار، با بستههای فعلی npm مخصوص Angular وجود دارند. برای مثال بدون استفادهی از این ابزار، نیاز است مستندات 13 صفحهای ساخت کتابخانههای Angular را سطر به سطر پیاده سازی کنید که توسط CLI 6.0، به صورت خودکار ایجاد و مدیریت میشود.
بنابراین اکنون سؤال مهمی که مطرح میشود این است: آیا باید فایل angular-cli.json پیشین را به صورت دستی به این فایل جدید به روز رسانی کرد و چگونه؟
به روز رسانی تمام بستههای سراسری سیستم
در ادامه پیش از هر کاری نیاز است تمام بستههای سراسری npm ایی را که هر از چندگاهی به سیستم خود اضافه کردهاید، به روز رسانی کنید. برای مشاهدهی لیست موارد تاریخ مصرف گذشتهی آنها، دستور زیر را صادر کنید:
و برای به روز رسانی یکجای آنها نیاز است دستور زیر اجرا شود:
به روز رسانی خودکار ساختار فایل angular-cli.json
این به روز رسانی توسط CLI 6.0 به صورت خودکار پشتیبانی میشود و شامل این مراحل است:
ابتدا نیاز است بستهی سراسری آنرا به روز رسانی کرد:
سپس وارد پوشهی اصلی پروژهی خود شده و این دستور را به صورت محلی نیز وارد کنید:
با اینکار بستهی CLI محلی پروژه به روز شده و اکنون میتوانیم از قابلیت جدید آن که ng update نام دارد، استفاده کنیم. برای این منظور دستورات ذیل را به ترتیب اجرا کنید:
دستور اول کار تبدیل خودکار فایل angular-cli.json قدیمی را به ساختار جدید آن انجام میدهد؛ با این لاگ:
دستور دوم بستههای هستهی angular را به روز رسانی میکند و دستور سوم کار به روز رسانی کتابخانهی rxjs را انجام میدهد.
لیست سایر بستههایی را که میتوان توسط این دستور به روز رسانی کرد، با اجرا دستور ng update میتوانید مشاهده کنید. برای مثال اگر از Angular Material نیز استفاده میکنید، دستور به روز رسانی آن به صورت زیر است:
مشکل! دستور ng update کار نمیکند!
اگر پروژهی شما صرفا مبتنی بر بستههای اصلی Angular باشد، مراحل یاد شدهی فوق را با موفقیت به پایان خواهید رساند. اما اگر از کتابخانههای ثالثی استفاده کرده باشید، منهای دستور «ng update @angular/cli» که کار تولید فایل جدید angular.json را انجام میدهد، مابقی با خطاهایی مانند «incompatible peer dependency» و یا «Invalid range:>=2.3.1 <3.0.0||>=4.0.0» متوقف میشوند.
در یک چنین حالتی نیاز است ابتدا وابستگیهای محلی پروژه را به روز کرد و سپس دستورات ng update را تکرار نمود. برای این منظور ابتدا بستهی npm-check-updates را نصب کنید:
کار آن به روز رسانی خودکار بستههای npm یک پروژه است. پس از آن دستورات زیر را صادر نمائید:
دستور اول تمام شماره نگارشهای بستههای موجود در فایل package.json را به صورت خودکار به آخرین نگارش آنها روز رسانی میکند و دستور دوم این بستههای جدید را دریافت و نصب خواهد کرد.
اکنون تمام وابستگیهای محلی پروژهی شما به صورت خودکار به آخرین نگارش آنها به روز رسانی شدهاند و اینبار اگر دستورات ذیل را اجرا کنید، با خطاهای یاد شده مواجه نخواهید شد:
البته اگر در این حالت برنامه را کامپایل کنید، کار نخواهد کرد. علت اصلی آن به بهروز رسانی rxjs به نگارش 6 آن مرتبط میشود که در مطلب بعدی پیگیری خواهد شد و این نگارش شامل حذفیات بسیاری است در جهت کاهش حجم آن، یکپارچکی و یک دست شدن syntax آن و همچنین بهبود قابل ملاحظهی کارآیی آن. البته پیشنیاز الزامی آن آشنایی با pipe-able operators است. علت دیگر کامپایل نشدن برنامه هم میتواند عدم استفاده از HttpClient نگارش 4.3 به بعد باشد.
خاموش کردن اخطار «TypeScript version mismatch»
اگر نگارش TypeScript نصب شدهی در سیستم به صورت سراسری، با نگارش محلی پروژهی شما یکی نباشد، اخطار «TypeScript version mismatch» را دریافت میکنید. روش خاموش کردن آن در CLI جدید با اجرای دستور زیر است:
البته نگارش 6 نیاز به TypeScript 2.7.2 ذکر شدهی در package.json پروژهی محلی را دارد؛ وگرنه اصلا شروع به کامپایل برنامه نمیکند:
بهترین راه برای یافتن این شماره، اجرای دستور ng new projet1 در یک پوشهی خالی است و سپس مقایسهی محتوای فایل package.json آن با فایل پروژهی موجود.
تغییرات ng build در نگارش 6
در نگارش 6، مفهوم پیشین environments به configurations تغییر یافتهاست و اینبار در فایل جدید angular.json تنظیم میشوند:
و پیشتر اگر برای تنظیم محیط build از سوئیچ env استفاده میشد:
اکنون این سوئیچ به configuration تغییر یافتهاست و نام آن از مداخل configurations فایل angular.json، مانند مثال فوق که «production» نام دارد، باید دریافت و تنظیم شود:
و یا برای مثال دستور «ng build --env=prod» دیگر اجرا نمیشود و env=prod حذف شدهاست و اکنون اجرای ng build --prod مانند اجرای دستور ng build --configuration=prod است.
تغییرات نامهای نهایی تولیدی
در CLI 6.0، نامهای نهایی تولیدی دیگر به همراه bundle و یا chunk نیستند. برای مثال دستور ng build یک چنین خروجی را تولید میکند:
و هشهای حالت prod به صورت زیر تولید و به نام فایل اضافه میشوند:
ساده شدن افزودن وابستگیهای ثالث به پروژههای CLI
برای نصب یک کتابخانهی ثالث، پیشتر میبایستی ابتدا بستهی npm آن جداگانه نصب و سپس فایل config برنامه، جهت معرفی مداخل آن، ویرایش میشد. اکنون دستور جدید ng add تمام این مراحل را به صورت خودکار انجام میدهد:
برای نمونه دستور فوق نه تنها فایلهای Angular Material را دریافت میکند، بلکه فایلهای CSS و ماژولهای مرتبط با آنرا نیز import خواهد کرد. البته این مورد از کلید ng-add فایل package.json بستهی در حال نصب دریافت و تنظیم میشود و کتابخانههای جدید باید خود را بر این اساس وفق دهند.
node -v npm -v
فایل پیشین angular-cli.json حذف و فایل جدید angular.json بجای آن معرفی شدهاست
یکی از مهمترین تغییرات CLI 6.0 نسبت به نگارشهای قبلی آن، پشتیبانی از چندین پروژه است و به همین منظور ساختار فایل تنظیمات آنرا به طور کامل تغییر دادهاند و اگر دستور ng new project1 را صادر کنید، دیگر از فایل پیشین angular-cli.json خبری نبوده و بجای آن فایل جدید angular.json قابل مشاهدهاست:
{ "$schema": "./node_modules/@angular/cli/lib/config/schema.json", "version": 1, "newProjectRoot": "projects", "projects": { "project1": {
مزیت مهم این قابلیت، امکان ایجاد libraries است که به صورت توکار از این نگارش پشتیبانی میشود و میتوان اجزایی مانند components ،directives ،pipes و services اشتراکی را در یک یا چندین کتابخانه قرار داد و سپس از آنها در پروژهی اصلی و یا چندین پروژهی متصل استفاده کرد.
نگارش 6 در پشت صحنه، پروژهی موفق ng-packagr را به مجموعهی CLI اضافه کردهاست و از این پس توسط خود CLI میتوان کتابخانههای استاندارد Angular را تولید کرد. این مورد، مزیت استاندارد سازی کتابخانههای npm حاصل را نیز به همراه دارد؛ مشکلی که گاهی از اوقات به علت عدم رعایت این ساختار، با بستههای فعلی npm مخصوص Angular وجود دارند. برای مثال بدون استفادهی از این ابزار، نیاز است مستندات 13 صفحهای ساخت کتابخانههای Angular را سطر به سطر پیاده سازی کنید که توسط CLI 6.0، به صورت خودکار ایجاد و مدیریت میشود.
بنابراین اکنون سؤال مهمی که مطرح میشود این است: آیا باید فایل angular-cli.json پیشین را به صورت دستی به این فایل جدید به روز رسانی کرد و چگونه؟
به روز رسانی تمام بستههای سراسری سیستم
در ادامه پیش از هر کاری نیاز است تمام بستههای سراسری npm ایی را که هر از چندگاهی به سیستم خود اضافه کردهاید، به روز رسانی کنید. برای مشاهدهی لیست موارد تاریخ مصرف گذشتهی آنها، دستور زیر را صادر کنید:
npm outdated -g --depth=0
npm update -g
به روز رسانی خودکار ساختار فایل angular-cli.json
این به روز رسانی توسط CLI 6.0 به صورت خودکار پشتیبانی میشود و شامل این مراحل است:
ابتدا نیاز است بستهی سراسری آنرا به روز رسانی کرد:
npm i -g @angular/cli
npm install --save-dev @angular/cli@latest
ng update @angular/cli ng update @angular/core ng update rxjs
DELETE .angular-cli.json CREATE angular.json (4273 bytes) UPDATE karma.conf.js (1008 bytes) UPDATE src/tsconfig.spec.json (322 bytes) UPDATE package.json (2076 bytes) UPDATE tslint.json (3217 bytes)
لیست سایر بستههایی را که میتوان توسط این دستور به روز رسانی کرد، با اجرا دستور ng update میتوانید مشاهده کنید. برای مثال اگر از Angular Material نیز استفاده میکنید، دستور به روز رسانی آن به صورت زیر است:
ng update @angular/material
مشکل! دستور ng update کار نمیکند!
اگر پروژهی شما صرفا مبتنی بر بستههای اصلی Angular باشد، مراحل یاد شدهی فوق را با موفقیت به پایان خواهید رساند. اما اگر از کتابخانههای ثالثی استفاده کرده باشید، منهای دستور «ng update @angular/cli» که کار تولید فایل جدید angular.json را انجام میدهد، مابقی با خطاهایی مانند «incompatible peer dependency» و یا «Invalid range:>=2.3.1 <3.0.0||>=4.0.0» متوقف میشوند.
در یک چنین حالتی نیاز است ابتدا وابستگیهای محلی پروژه را به روز کرد و سپس دستورات ng update را تکرار نمود. برای این منظور ابتدا بستهی npm-check-updates را نصب کنید:
npm install npm-check-updates -g
ncu -u npm install
اکنون تمام وابستگیهای محلی پروژهی شما به صورت خودکار به آخرین نگارش آنها به روز رسانی شدهاند و اینبار اگر دستورات ذیل را اجرا کنید، با خطاهای یاد شده مواجه نخواهید شد:
ng update @angular/core ng update rxjs
البته اگر در این حالت برنامه را کامپایل کنید، کار نخواهد کرد. علت اصلی آن به بهروز رسانی rxjs به نگارش 6 آن مرتبط میشود که در مطلب بعدی پیگیری خواهد شد و این نگارش شامل حذفیات بسیاری است در جهت کاهش حجم آن، یکپارچکی و یک دست شدن syntax آن و همچنین بهبود قابل ملاحظهی کارآیی آن. البته پیشنیاز الزامی آن آشنایی با pipe-able operators است. علت دیگر کامپایل نشدن برنامه هم میتواند عدم استفاده از HttpClient نگارش 4.3 به بعد باشد.
خاموش کردن اخطار «TypeScript version mismatch»
اگر نگارش TypeScript نصب شدهی در سیستم به صورت سراسری، با نگارش محلی پروژهی شما یکی نباشد، اخطار «TypeScript version mismatch» را دریافت میکنید. روش خاموش کردن آن در CLI جدید با اجرای دستور زیر است:
ng config cli.warnings.typescriptMismatch false
{ "devDependencies": { "typescript": "~2.7.2" } }
تغییرات ng build در نگارش 6
در نگارش 6، مفهوم پیشین environments به configurations تغییر یافتهاست و اینبار در فایل جدید angular.json تنظیم میشوند:
{ "$schema": "./node_modules/@angular/cli/lib/config/schema.json", "version": 1, "newProjectRoot": "projects", "projects": { "angular-template-driven-forms-lab": { "configurations": { "production": { "optimization": true, "outputHashing": "all", "sourceMap": false, "extractCss": true, "namedChunks": false, "aot": true, "extractLicenses": true, "vendorChunk": false, "buildOptimizer": true, "fileReplacements": [ { "replace": "src/environments/environment.ts", "with": "src/environments/environment.prod.ts" } ] } } },
ng build --env staging
ng build --configuration staging
تغییرات نامهای نهایی تولیدی
در CLI 6.0، نامهای نهایی تولیدی دیگر به همراه bundle و یا chunk نیستند. برای مثال دستور ng build یک چنین خروجی را تولید میکند:
>ng build --watch Date: 2018-05-05T09:10:50.158Z Hash: a43eab94ff01539b8592 Time: 31733ms chunk {main} main.js, main.js.map (main) 9.38 kB [initial] [rendered] chunk {polyfills} polyfills.js, polyfills.js.map (polyfills) 226 kB [initial] [rendered] chunk {runtime} runtime.js, runtime.js.map (runtime) 5.4 kB [entry] [rendered] chunk {styles} styles.js, styles.js.map (styles) 15.6 kB [initial] [rendered] chunk {vendor} vendor.js, vendor.js.map (vendor) 3.05 MB [initial] [rendered]
و هشهای حالت prod به صورت زیر تولید و به نام فایل اضافه میشوند:
>ng build --prod --watch Date: 2018-05-05T09:17:01.803Z Hash: f25fd6788a4969c52b70 Time: 73279ms chunk {0} runtime.6afe30102d8fe7337431.js (runtime) 1.05 kB [entry] [rendered] chunk {1} styles.34c57ab7888ec1573f9c.css (styles) 0 bytes [initial] [rendered] chunk {2} polyfills.6c08419970f9e4781b69.js (polyfills) 59.4 kB [initial] [rendered]
ساده شدن افزودن وابستگیهای ثالث به پروژههای CLI
برای نصب یک کتابخانهی ثالث، پیشتر میبایستی ابتدا بستهی npm آن جداگانه نصب و سپس فایل config برنامه، جهت معرفی مداخل آن، ویرایش میشد. اکنون دستور جدید ng add تمام این مراحل را به صورت خودکار انجام میدهد:
ng add @angular/material
FluentValidation یک کتابخانهی اعتبارسنجی اطلاعات سمت سرور است و راهکاری را برای اعتبارسنجیهای سمت کلاینت ارائه نمیدهد؛ اما میتواند متادیتای مورد نیاز unobtrusive java script validation را تولید کند و به این ترتیب بسیاری از قواعد آن دقیقا همانند روشهای توکار اعتبارسنجی ASP.NET Core در سمت کلاینت نیز کار میکنند؛ مانند:
• NotNull/NotEmpty
• Matches (regex)
• InclusiveBetween (range)
• CreditCard
• Email
• EqualTo (cross-property equality comparison)
• MaxLength
• MinLength
• Length
اما باید دقت داشت که سایر قابلیتهای این کتابخانه، قابلیت ترجمهی به قواعد unobtrusive java script validation ندارند؛ مانند:
- استفادهی از شرطها توسط متدهای When و یا Unless (برای مثال اگر خاصیت A دارای مقدار 5 بود، آنگاه ورود اطلاعات خاصیت B باید اجباری شود)
- تعریف قواعد اعتبارسنجی سفارشی، برای مثال توسط متد Must
- تعریف RuleSetها (برای مثال تعیین کنید که از یک مدل، فقط تعدادی از خواص آن اعتبارسنجی شوند و نه تمام آنها)
در یک چنین حالتهایی باید کاربر اطلاعات کامل فرم را به سمت سرور ارسال کند و در post-back صورت گرفته، نتایج اعتبارسنجی را دریافت کند.
روش توسعهی اعتبارسنجی سمت کلاینت کتابخانهی FluentValidation جهت سازگاری آن با unobtrusive java script validation
باتوجه به اینکه قواعد سفارشی کتابخانهی FluentValidation، معادل unobtrusive java script validation ای ندارند، در ادامه مثالی را جهت تدارک آنها بررسی میکنیم. برای این منظور، معادل مطلب «ایجاد ویژگیهای اعتبارسنجی سفارشی در ASP.NET Core 3.1 به همراه اعتبارسنجی سمت کلاینت آنها» را بر اساس ویژگیهای کتابخانهی FluentValidation پیاده سازی میکنیم.
1) ایجاد اعتبارسنج سمت سرور
میخواهیم اگر مقدار عددی خاصیتی بیشتر از مقدار عددی خاصیت دیگری بود، اعتبارسنجی آن با شکست مواجه شود. به همین منظور با پیاده سازی یک PropertyValidator سفارشی، LowerThanValidator را به صورت زیر تعریف میکنیم:
- در اینجا dependentProperty همان خاصیت دیگری است که باید مقایسه با آن صورت گیرد. در متد بازنویسی شدهی IsValid، میتوان مقدار آنرا از context.Instance استخراج کرده و سپس با مقدار جاری context.PropertyValue مقایسه کرد.
- همچنین جهت سهولت کار فراخوانی آن، یک متد الحاقی جدید به نام LowerThan نیز در اینجا تعریف شدهاست.
- البته اگر قصد اعتبارسنجی سمت سرور را ندارید، میتوان در متد IsValid، مقدار true را بازگشت داد.
2) ایجاد متادیتای مورد نیاز جهت unobtrusive java script validation در سمت سرور
در ادامه نیاز است ویژگیهای data-val خاص unobtrusive java script validation را توسط FluentValidation ایجاد کنیم:
در این کدها، تنها قسمت مهم آن، متد AddValidation است که کار تعریف و افزودن متادیتاهای unobtrusive java script validation را انجام میدهد و برای مثال سبب رندر یک چنین تگ HTML ای میشود که در آن پیام اعتبارسنجی و خاصیت دیگر مدنظر ذکر شدهاند:
3) تعریف مدل کاربران و اعتبارسنجی آن
مدلی که در این مثال از آن استفاده شده، یک چنین تعریفی را دارد و در قسمت اعتبارسنجی خاصیت Experience آن، از متد الحاقی جدید LowerThan استفاده شدهاست:
4) افزودن اعتبارسنجهای تعریف شده به تنظیمات برنامه
پس از تعریف LowerThanValidator و LowerThanClientValidator، روش افزودن آنها به تنظیمات FluentValidation به صورت زیر است:
5) تعریف کدهای جاوا اسکریپتی مورد نیاز
پیش از هرکاری، اسکریپتهای فایل layout برنامه باید چنین تعریفی را داشته باشند:
در اینجا مداخل jquery، سپس jquery.validate و بعد از آن jquery.validate.unobtrusive را مشاهده میکنید. در ادامه فایل js/site.js را به صورت زیر تکمیل خواهیم کرد:
در اینجا یکبار اعتبارسنج LowerThan را به validator.unobtrusive معرفی میکنیم. سپس منطق پیاده سازی آنرا که بر اساس یافتن مقدار خاصیت دیگر و مقایسهی آن با مقدار خاصیت جاری است، به اعتبارسنجهای jQuery Validator اضافه خواهیم کرد.
6) آزمایش برنامه
در صورتیکه سابقهی کار را بیشتر از سن وارد کنیم، به یک چنین خروجی سمت کلاینتی (بدون نیاز به post-back کامل به سمت سرور) خواهیم رسید:
• NotNull/NotEmpty
• Matches (regex)
• InclusiveBetween (range)
• CreditCard
• EqualTo (cross-property equality comparison)
• MaxLength
• MinLength
• Length
اما باید دقت داشت که سایر قابلیتهای این کتابخانه، قابلیت ترجمهی به قواعد unobtrusive java script validation ندارند؛ مانند:
- استفادهی از شرطها توسط متدهای When و یا Unless (برای مثال اگر خاصیت A دارای مقدار 5 بود، آنگاه ورود اطلاعات خاصیت B باید اجباری شود)
- تعریف قواعد اعتبارسنجی سفارشی، برای مثال توسط متد Must
- تعریف RuleSetها (برای مثال تعیین کنید که از یک مدل، فقط تعدادی از خواص آن اعتبارسنجی شوند و نه تمام آنها)
در یک چنین حالتهایی باید کاربر اطلاعات کامل فرم را به سمت سرور ارسال کند و در post-back صورت گرفته، نتایج اعتبارسنجی را دریافت کند.
روش توسعهی اعتبارسنجی سمت کلاینت کتابخانهی FluentValidation جهت سازگاری آن با unobtrusive java script validation
باتوجه به اینکه قواعد سفارشی کتابخانهی FluentValidation، معادل unobtrusive java script validation ای ندارند، در ادامه مثالی را جهت تدارک آنها بررسی میکنیم. برای این منظور، معادل مطلب «ایجاد ویژگیهای اعتبارسنجی سفارشی در ASP.NET Core 3.1 به همراه اعتبارسنجی سمت کلاینت آنها» را بر اساس ویژگیهای کتابخانهی FluentValidation پیاده سازی میکنیم.
1) ایجاد اعتبارسنج سمت سرور
میخواهیم اگر مقدار عددی خاصیتی بیشتر از مقدار عددی خاصیت دیگری بود، اعتبارسنجی آن با شکست مواجه شود. به همین منظور با پیاده سازی یک PropertyValidator سفارشی، LowerThanValidator را به صورت زیر تعریف میکنیم:
using System; using FluentValidation; using FluentValidation.Validators; namespace FluentValidationSample.Models { public class LowerThanValidator : PropertyValidator { public string DependentProperty { get; set; } public LowerThanValidator(string dependentProperty) : base($"باید کمتر از {dependentProperty} باشد") { DependentProperty = dependentProperty; } protected override bool IsValid(PropertyValidatorContext context) { if (context.PropertyValue == null) { return false; } var typeInfo = context.Instance.GetType(); var dependentPropertyValue = Convert.ToInt32(typeInfo.GetProperty(DependentProperty).GetValue(context.Instance, null)); return int.Parse(context.PropertyValue.ToString()) < dependentPropertyValue; } } public static class CustomFluentValidationExtensions { public static IRuleBuilderOptions<T, int> LowerThan<T>( this IRuleBuilder<T, int> ruleBuilder, string dependentProperty) { return ruleBuilder.SetValidator(new LowerThanValidator(dependentProperty)); } } }
- همچنین جهت سهولت کار فراخوانی آن، یک متد الحاقی جدید به نام LowerThan نیز در اینجا تعریف شدهاست.
- البته اگر قصد اعتبارسنجی سمت سرور را ندارید، میتوان در متد IsValid، مقدار true را بازگشت داد.
2) ایجاد متادیتای مورد نیاز جهت unobtrusive java script validation در سمت سرور
در ادامه نیاز است ویژگیهای data-val خاص unobtrusive java script validation را توسط FluentValidation ایجاد کنیم:
using FluentValidation; using FluentValidation.AspNetCore; using FluentValidation.Internal; using FluentValidation.Resources; using FluentValidation.Validators; using Microsoft.AspNetCore.Mvc.ModelBinding.Validation; namespace FluentValidationSample.Models { public class LowerThanClientValidator : ClientValidatorBase { private LowerThanValidator LowerThanValidator { get { return (LowerThanValidator)Validator; } } public LowerThanClientValidator(PropertyRule rule, IPropertyValidator validator) : base(rule, validator) { } public override void AddValidation(ClientModelValidationContext context) { MergeAttribute(context.Attributes, "data-val", "true"); MergeAttribute(context.Attributes, "data-val-LowerThan", GetErrorMessage(context)); MergeAttribute(context.Attributes, "data-val-LowerThan-dependentproperty", LowerThanValidator.DependentProperty); } private string GetErrorMessage(ClientModelValidationContext context) { var formatter = ValidatorOptions.MessageFormatterFactory().AppendPropertyName(Rule.GetDisplayName()); string messageTemplate; try { messageTemplate = Validator.Options.ErrorMessageSource.GetString(null); } catch (FluentValidationMessageFormatException) { messageTemplate = ValidatorOptions.LanguageManager.GetStringForValidator<NotEmptyValidator>(); } return formatter.BuildMessage(messageTemplate); } } }
<input dir="rtl" type="number" data-val="true" data-val-lowerthan="باید کمتر از Age باشد" data-val-lowerthan-dependentproperty="Age" data-val-required="'سابقه کار' must not be empty." id="Experience" name="Experience" value="">
3) تعریف مدل کاربران و اعتبارسنجی آن
مدلی که در این مثال از آن استفاده شده، یک چنین تعریفی را دارد و در قسمت اعتبارسنجی خاصیت Experience آن، از متد الحاقی جدید LowerThan استفاده شدهاست:
public class UserModel { [Display(Name = "نام کاربری")] public string Username { get; set; } [Display(Name = "سن")] public int Age { get; set; } [Display(Name = "سابقه کار")] public int Experience { get; set; } } public class UserValidator : AbstractValidator<UserModel> { public UserValidator() { RuleFor(x => x.Username).NotNull(); RuleFor(x => x.Age).NotNull(); RuleFor(x => x.Experience).LowerThan(nameof(UserModel.Age)).NotNull(); } }
4) افزودن اعتبارسنجهای تعریف شده به تنظیمات برنامه
پس از تعریف LowerThanValidator و LowerThanClientValidator، روش افزودن آنها به تنظیمات FluentValidation به صورت زیر است:
namespace FluentValidationSample.Web { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddControllersWithViews().AddFluentValidation( fv => { fv.RegisterValidatorsFromAssembly(Assembly.GetExecutingAssembly()); fv.RegisterValidatorsFromAssemblyContaining<RegisterModelValidator>(); fv.RunDefaultMvcValidationAfterFluentValidationExecutes = false; fv.ConfigureClientsideValidation(clientSideValidation => { clientSideValidation.Add( validatorType: typeof(LowerThanValidator), factory: (context, rule, validator) => new LowerThanClientValidator(rule, validator)); }); } ); }
5) تعریف کدهای جاوا اسکریپتی مورد نیاز
پیش از هرکاری، اسکریپتهای فایل layout برنامه باید چنین تعریفی را داشته باشند:
<script src="~/lib/jquery/dist/jquery.min.js"></script> <script src="~/lib/bootstrap/dist/js/bootstrap.bundle.min.js"></script> <script src="~/lib/jquery-validation/dist/jquery.validate.js"></script> <script src="~/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.js"></script> <script src="~/js/site.js" asp-append-version="true"></script>
$.validator.unobtrusive.adapters.add('LowerThan', ['dependentproperty'], function (options) { options.rules['LowerThan'] = { dependentproperty: options.params['dependentproperty'] }; options.messages['LowerThan'] = options.message; }); $.validator.addMethod('LowerThan', function (value, element, parameters) { var dependentProperty = '#' + parameters['dependentproperty']; var dependentControl = $(dependentProperty); if (dependentControl) { var targetvalue = dependentControl.val(); if (parseInt(targetvalue) > parseInt(value)) { return true; } return false; } return true; });
6) آزمایش برنامه
پس از این تنظیمات، اگر Viewما چنین تعریفی را داشته باشد:
@using FluentValidationSample.Models @model UserModel @{ ViewData["Title"] = "Home Page"; } <div dir="rtl"> <form asp-controller="Home" asp-action="RegisterUser" method="post"> <fieldset class="form-group"> <legend>ثبت نام</legend> <div class="form-group row"> <label asp-for="Username" class="col-md-2 col-form-label text-md-left"></label> <div class="col-md-10"> <input dir="rtl" asp-for="Username" class="form-control" /> <span asp-validation-for="Username" class="text-danger"></span> </div> </div> <div class="form-group row"> <label asp-for="Age" class="col-md-2 col-form-label text-md-left"></label> <div class="col-md-10"> <input dir="rtl" asp-for="Age" class="form-control" /> <span asp-validation-for="Age" class="text-danger"></span> </div> </div> <div class="form-group row"> <label asp-for="Experience" class="col-md-2 col-form-label text-md-left"></label> <div class="col-md-10"> <input dir="rtl" asp-for="Experience" class="form-control" /> <span asp-validation-for="Experience" class="text-danger"></span> </div> </div> <div class="form-group row"> <label class="col-md-2 col-form-label text-md-left"></label> <div class="col-md-10 text-md-right"> <button type="submit" class="btn btn-info col-md-2">ارسال</button> </div> </div> </fieldset> </form> </div>
ویرایش سوم JavaScript Step by Step بر اساس دو ویرایش قبلی نگارش شده است. با این که معماری اصلی زبان جاوا اسکریپت تغییر آن چنانی نکرده است، استفاده از جاوا اسکریپت هر روزه بیشتر میشود و در طی چند سال اخیر اهمیت آن برای توسعه دهندگان بسیار افزایش یافته است. با این اوصاف ساختار و کلیات کتاب پیش رو تغییری نکرده به جز چند تغییر قابل توجه. بخش Event Handling مورد تاکید بیشتری قرار گرفته است و برای افزایش سرعت توسعه از jQuery استفاده شده است. همچنین در فصل آخر، بخشی برای توسعه برنامههای Windows 8 با استفاده از جاوا اسکریپت در نظر گرفته شده است. با این حال، محتویات این کتاب کاملا در انحصار مایکروسافت نیست!
سلام؛ نحوه کار با ConcurrentDictionary در Asp.Net Core دقیقا چطوری هستش؟ لطف کنید نحوه پیاده سازی همین ماژول Online Visitors رو با ConcurrentDictionary داخل Asp.Net Core بگید.
اشتراکها
شروع به کار با Angular 7.0
فرض کنید قصد داریم خاصیت htmlContent زیر را در قالب این کامپوننت نمایش دهیم:
اگر از روش متداول binding استفاده شود:
چنین خروجی حاصل خواهد شد:
همچنین اگر به کنسول developer tools مرورگر مراجعه کنیم، چنین اخطاری نیز درج شده است:
به این معنا که Angular به صورت توکار تمام خروجیها را به صورت encode شده نمایش میدهد و در مقابل حملات XSS مقاوم است. Sanitizing نیز در اینجا به معنای تغییر ورودی و تبدیل آن به مقداری است که جهت درج در DOM امن است.
روش نمایش HTML در برنامههای Angular
اما اگر خواستیم اطلاعات HTML ایی را به همان صورتی که هستند نمایش دهیم چطور؟ در این حالت باید از روش ویژهی ذیل استفاده کرد:
برای نمایش HTML نیاز است آنرا به ویژگی innerHTML متصل کرد؛ با این خروجی:
همانطور که مشاهده میکنید، هنوز هم عملیات پاکسازی قسمتهایی که ممکن است مخرب باشند صورت میگیرد (برای مثال تگ script حذف شدهاست). اما مابقی تگهای امن به همان حالتی که هستند نمایش داده خواهند شد.
روش دیگر کار با innerHTML، تعریف یک template reference variable در قالب کامپوننت است:
و سپس دسترسی به آن از طریق یک ViewChild و انتساب مقداری بهinnerHTML آن به صورت ذیل:
با این خروجی:
که اینبار قسمت script آن به طور کامل حذف شدهاست.
حالات مختلفی که Angular برنامه را از حملات XSS محافظت میکند
در ذیل، لیست مواردی را مشاهده میکنید که به صورت پیشفرض توسط Angular در مقابل حملات XSS محافظت میشوند و اطلاعات انتساب داده شدهی به آنها تمیزسازی خواهند شد:
تبدیل کردن یک HTML نا امن ورودی به یک HTML امن در Angular
بهتر است اطلاعات دریافتی از کاربران پیش از ارسال به سرور تمیز شوند. برای این منظور میتوان از سرویس ویژهای به نام DomSanitizer کمک گرفت. کار این سرویس، امن سازی اطلاعات نمایش داده شدهی در برنامههای Angular است.
در این حالت سرویس DomSanitizer به سازندهی کلاس تزریق شده و سپس میتوان از متدهای مختلف آن مانند sanitize استفاده کرد. خروجی آن صرفا حذف تگ اسکریپت و نگهداری کدهای درون آن است.
در این حالت میتوان موارد ذیل را کنترل کرد. برای مثال اگر مقدار دریافتی CSS است، میتوان از SecurityContext.STYLE استفاده کرد و سایر حالات آن مانند امن سازی HTML، اسکریپت و آدرسهای اینترنتی به شرح ذیل هستند:
غیرفعال کردن سیستم امنیتی Angular جهت نمایش کامل یک مقدار HTML ایی
اگر خواستیم اطلاعات HTML ایی را با فرض امن بودن آن، به همان نحوی که هست نمایش دهیم چطور؟
سرویس DomSanitizer شامل متدهای ذیل نیز میباشد:
اولین متد آن sanitize است که در مورد آن توضیح داده شد. سایر متدها، کار غیرفعال سازی سیستم امنیتی توکار Angular را انجام میدهند.
برای کار با آنها همانند مثال استفادهی از متد sanitize میتوان سرویس DomSanitizer را به سازندهی یک کامپوننت تزریق کرد و یا میتوان این عملیات تکراری فرمت اطلاعات ورودی را تبدیل به یک Pipe جدید کرد:
کار این Pipe غیرفعال کردن سیستم امنیتی Angular و نمایش html، style و غیره به همان صورتی که هستند، میباشد.
برای استفادهی از آن، ابتدا این Pipe به قسمت declarations ماژول مدنظر اضافه خواهد شد:
و سپس در قالب کامپوننت به نحو ذیل میتوان با آن کار کرد:
در این حالت متد bypassSecurityTrustHtml بر روی htmlContent، فراخوانی شده و نتیجهی نهایی نمایش داده خواهد شد.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.
export class ShowHtmlComponent { htmlContent = "Template <script>alert(\"Hello!\")</script> <b>Syntax</b>"; }
<h3>Binding innerHTML</h3> <p>Bound value:</p> <p>{{htmlContent}}</p>
همچنین اگر به کنسول developer tools مرورگر مراجعه کنیم، چنین اخطاری نیز درج شده است:
WARNING: sanitizing HTML stripped some content (see http://g.co/ng/security#xss).
روش نمایش HTML در برنامههای Angular
اما اگر خواستیم اطلاعات HTML ایی را به همان صورتی که هستند نمایش دهیم چطور؟ در این حالت باید از روش ویژهی ذیل استفاده کرد:
<p>Result of binding to innerHTML:</p> <p [innerHTML]="htmlContent"></p>
همانطور که مشاهده میکنید، هنوز هم عملیات پاکسازی قسمتهایی که ممکن است مخرب باشند صورت میگیرد (برای مثال تگ script حذف شدهاست). اما مابقی تگهای امن به همان حالتی که هستند نمایش داده خواهند شد.
روش دیگر کار با innerHTML، تعریف یک template reference variable در قالب کامپوننت است:
<p #dataContainer></p>
export class ShowHtmlComponent implements OnInit { @ViewChild("dataContainer") dataContainer: ElementRef; ngOnInit() { this.dataContainer.nativeElement.innerHTML = "nativeElement <script>alert(\"Hello!\")</script> <b>Syntax</b>"; } }
که اینبار قسمت script آن به طور کامل حذف شدهاست.
حالات مختلفی که Angular برنامه را از حملات XSS محافظت میکند
در ذیل، لیست مواردی را مشاهده میکنید که به صورت پیشفرض توسط Angular در مقابل حملات XSS محافظت میشوند و اطلاعات انتساب داده شدهی به آنها تمیزسازی خواهند شد:
HTML Attributes – <div [innerHTML]="UNTRUSTED"></div> OR <input value="UNTRUSTED"> Style— <div [style]="height:UNTRUSTED"></div> URL — <a [href]="UNTRUSTED-URL"></a> OR <script [src]="UNTRUSTED-URL"></script> OR <iframe src="UNTRUSTED-URL" /> GET Parameter – <a href="/user?id=UNTRUSTED">link</a> JavaScript Variable – <script> var value='UNTRUSTED';</script>
تبدیل کردن یک HTML نا امن ورودی به یک HTML امن در Angular
بهتر است اطلاعات دریافتی از کاربران پیش از ارسال به سرور تمیز شوند. برای این منظور میتوان از سرویس ویژهای به نام DomSanitizer کمک گرفت. کار این سرویس، امن سازی اطلاعات نمایش داده شدهی در برنامههای Angular است.
export class ShowHtmlComponent implements OnInit { sanitizedHtml: string; constructor(private sanitizer: DomSanitizer) { } ngOnInit() { this.sanitizedHtml = this.sanitizer.sanitize(SecurityContext.HTML, "<b>Sanitize</b><script>attackerCode()</script>"); } }
در این حالت میتوان موارد ذیل را کنترل کرد. برای مثال اگر مقدار دریافتی CSS است، میتوان از SecurityContext.STYLE استفاده کرد و سایر حالات آن مانند امن سازی HTML، اسکریپت و آدرسهای اینترنتی به شرح ذیل هستند:
SecurityContext.NONE SecurityContext.HTML SecurityContext.STYLE SecurityContext.SCRIPT SecurityContext.URL SecurityContext.RESOURCE_URL
غیرفعال کردن سیستم امنیتی Angular جهت نمایش کامل یک مقدار HTML ایی
اگر خواستیم اطلاعات HTML ایی را با فرض امن بودن آن، به همان نحوی که هست نمایش دهیم چطور؟
سرویس DomSanitizer شامل متدهای ذیل نیز میباشد:
export enum SecurityContext { NONE, HTML, STYLE, SCRIPT, URL, RESOURCE_URL } export abstract class DomSanitizer implements Sanitizer { abstract sanitize(context: SecurityContext, value: SafeValue|string|null): string|null; abstract bypassSecurityTrustHtml(value: string): SafeHtml; abstract bypassSecurityTrustStyle(value: string): SafeStyle; abstract bypassSecurityTrustScript(value: string): SafeScript; abstract bypassSecurityTrustUrl(value: string): SafeUrl; abstract bypassSecurityTrustResourceUrl(value: string): SafeResourceUrl; }
برای کار با آنها همانند مثال استفادهی از متد sanitize میتوان سرویس DomSanitizer را به سازندهی یک کامپوننت تزریق کرد و یا میتوان این عملیات تکراری فرمت اطلاعات ورودی را تبدیل به یک Pipe جدید کرد:
import { Pipe, PipeTransform } from "@angular/core"; import { DomSanitizer, SafeHtml, SafeResourceUrl, SafeScript, SafeStyle, SafeUrl } from "@angular/platform-browser"; @Pipe({ name: "safe" }) export class SafePipe implements PipeTransform { constructor(protected sanitizer: DomSanitizer) { } public transform(value: any, type: string): SafeHtml | SafeStyle | SafeScript | SafeUrl | SafeResourceUrl { switch (type) { case "html": return this.sanitizer.bypassSecurityTrustHtml(value); case "style": return this.sanitizer.bypassSecurityTrustStyle(value); case "script": return this.sanitizer.bypassSecurityTrustScript(value); case "url": return this.sanitizer.bypassSecurityTrustUrl(value); case "resourceUrl": return this.sanitizer.bypassSecurityTrustResourceUrl(value); default: throw new Error(`Invalid safe type specified: ${type}`); } } }
برای استفادهی از آن، ابتدا این Pipe به قسمت declarations ماژول مدنظر اضافه خواهد شد:
@NgModule({ imports: [ // ... ], declarations: [ SafePipe] })
<p [innerHTML]="htmlContent | safe: 'html'"></p>
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید.