پس از ایجاد ساختار اولیهی یک برنامهی Angular توسط Angular CLI، امکان تولید کدهای کامپوننتها، ماژولها، سرویسها و ... نیز در این ابزار پیش بینی شدهاست. کدهای تولید شدهی آن بر اساس یک سری blueprint (و یا همان مفهوم قالبهای از پیش آماده در سایر ابزارهای مشابه) ایجاد میشوند و فرمت کلی آن نیز به صورت ذیل است:
ایجاد کامپوننتهای جدید توسط Angular CLI
دستور ایجاد یک کامپوننت جدید توسط Angular CLI به نحو زیر است:
این دستور اندکی طولانی به نظر میرسد. به همین جهت برای خلاصه نویسی آن میتوان از مفهومی به نام Alias استفاده کرد. میانبر generate در اینجا g است و میانبر component، معادل c میباشد. به این صورت میتوان دستور فوق را به این شکل، خلاصه و بازنویسی کرد:
گزینههای ایجاد کدهای جدید در Angular CLI
اگر به اولین دستور بحث جاری دقت کنید، قسمت <options> نیز برای آن درنظر گرفته شدهاست. تعدادی از مهمترین گزینههایی را که در اینجا میتوان ذکر کرد به شرح زیر هستند:
برای مثال اگر خواستیم کامپوننتی را به همراه قالبها و شیوهنامههای inline (قرار گرفتهی داخل فایل ts. آن) تولید کنیم، میتوان از دستور ذیل کمک گرفت:
که خلاصه شدهی آن با توجه به Aliasهای ذکر شده به صورت ذیل است:
اگر صرفا دستور ng generate component customer را اجرا کنیم (بدون هیچ گزینهی اضافهتری)، فایلهای ts (کلاس کامپوننت)، css (فایل شیوه نامه)، html (فایل قالب) و spec (فایل آزمون واحد کامپوننت) به صورت خودکار تولید خواهند شد.
همانطور که پیشتر نیز عنوان شد، اگر مطمئن نیستید که دستور درحال فراخوانی، چه فایلها و پوشههایی را ایجاد میکند، با ذکر پرچم dry-run-- و یا به صورت خلاصه d-، دستور مدنظر را شبیه سازی کنید تا صرفا گزارشی را از فایلهایی که قرار است تولید شوند، ارائه دهد.
نکتهی مهم دیگری که به همراه دستورات Angular CLI هستند، به روز رسانی خودکار فایل app.module.ts است:
برای نمونه زمانیکه دستور تولید یک کامپوننت را به نحوی که ملاحظه میکنید صادر کنیم، علاوه بر ایجاد 4 فایل مرتبط با آن کامپوننت، سطر به روز رسانی فایل app.module.ts را نیز در انتها ذکر کردهاست. در اینجا تغییرات صورت گرفته را ملاحظه میکنید:
ابتدا به صورت خودکار سطر import این کامپوننت جدید ذکر شدهاست و سپس قسمت declarations ماژول را نیز با تعریف CustomerComponent به روز رسانی کردهاست. بنابراین کار با Angular CLI فراتر است از صرفا کار با تعدادی قالب از پیش آمادهی کامپوننتها و سرویسها.
مشاهدهی تغییرات انجام شدهی توسط Angular CLI به کمک سورس کنترل
همانطور که در قسمت قبل نیز عنوان شد، دستور ng new، کار آغاز یک مخزن Git را نیز به صورت خودکار انجام میدهد. در اینجا هر دستوری که توسط Angular CLI اجرا شود، به این مخزن کد commit خواهد شد.
برای مثال اگر کل پوشهی برنامه را توسط VSCode باز کنیم (کلیک راست در داخل ریشهی اصلی پروژه و انتخاب گزینهی Open With Code)، با مراجعهی به لیست تغییرات و بررسی diff آنها، به سادگی میتوان تشخیص داد که چه تغییراتی بر روی فایلها اعمال شدهاند.
ایجاد سایر اجزای جدید برنامه توسط Angular CLI
نکات تکمیلی
- در حین ایجاد یک directive جدید، پوشهای را برای آن ایجاد نمیکند. اگر میخواهید اینکار به صورت flat (بدون پوشه در اینجا) انجام نشود، گزینهی flat false-- را نیز قید کنید.
- در حین ایجاد یک سرویس جدید، اخطار «WARNING Service is generated but not provided, it must be provided to be used» را دریافت خواهید کرد. علت اینجا است که Angular CLI نمیداند که این سرویس را باید به کامپوننت خاصی اضافه کند یا به ماژول برنامه. به همین جهت یا باید به صورت دستی فایل src\app\app.module.ts را ویرایش و قسمت providers آنرا بر اساس نام این سرویس جدید تکمیل کرد و یا توسط سوئیچ m میتوان ماژول مدنظر را دقیقا ذکر کرد:
در اینجا عنوان شدهاست که پس از ایجاد سرویس جدید sales، قسمت providers ماژول src\app\app.module.ts نیز به روز رسانی شود.
این نکته در مورد تمام اجزایی که فایل app.module را به روز رسانی میکنند نیز صادق است. اگر برای مثال کامپوننتی قرار است ماژول جدید دیگری را به روز رسانی کند، میتوانید به صورت صریح نام ماژول آنرا قید کنید؛ در غیراینصورت از همان app.module پیش فرض استفاده خواهد شد.
- همانطور که مشاهده میکنید امکان تولید کلاس، اینترفیس و enum تایپاسکریپتی نیز در اینجا پیش بینی شدهاست. اگر خواستید کلاسی را درون پوشهی خاصی قرار دهید میتوانید محل پوشهی آنرا دقیقا ذکر کنید (در مورد اینترفیسها و enums و سایر اجزاء نیز به همین صورت):
به این ترتیب فایل کلاس customer.ts درون پوشهی arc/app/models تشکیل میشود. پوشهی models نیز در صورت عدم وجود به صورت خودکار ایجاد خواهد شد.
تغییر تنظیمات پیش فرض تولید کد پروژهی جاری
در قسمت قبل «تغییر پیش فرضهای عمومی Angular CLI» را بررسی کردیم. در اینجا نیز میتوان یکسری از خواص فایل angular-cli.json. را بازنویسی کرد؛ در قسمت defaults آن:
یا از طریق خط فرمان
و یا با ویرایش فایل json تنظیمات cli به صورت مستقیم:
به این ترتیب دیگر نیازی نخواهد بود تا هربار به ازای ایجاد یک دایرکتیو جدید، پرچم flat نبودن آنرا مقدار دهی کرد؛ چون از فایل angular-cli.json. تنظیمات خودش را دریافت میکند.
و اگر VSCode استفاده میکنید، به همراه intellisense کاملی در مورد اجزای مختلف این فایل json است (این intellisense را به صورت خودکار بر اساس اسکیمای این فایل و سرویس زبان Angular تهیه میکند).
> ng generate <blueprint> <options>
ایجاد کامپوننتهای جدید توسط Angular CLI
دستور ایجاد یک کامپوننت جدید توسط Angular CLI به نحو زیر است:
> ng generate component customer
> ng g c customer
گزینههای ایجاد کدهای جدید در Angular CLI
اگر به اولین دستور بحث جاری دقت کنید، قسمت <options> نیز برای آن درنظر گرفته شدهاست. تعدادی از مهمترین گزینههایی را که در اینجا میتوان ذکر کرد به شرح زیر هستند:
گزینه | Alias (میانبر/نام مستعار) | توضیح |
flat-- | آیا باید برای آن پوشهای ایجاد نشود؟ (flat = بدون پوشه در اینجا) (پیش فرض آن ایجاد یک پوشهی جدید است). اگر میخواهیم ایجاد نشود، باید flat true-- را ذکر کرد. | |
inline-template-- | it- | آیا قالب کامپوننت، درون فایل ts. آن قرار گیرد؟ (پیش فرض آن، false است) |
inline-style-- | is- | آیا شیوه نامهی کامپوننت، داخل فایل ts. آن قرار گیرد؟ (پیش فرض آن، false است) |
spec-- | آیا فایل spec نیز تولید شود؟ (پیش فرض آن true است) اگر میخواهیم این فایل ایجاد نشود باید spec false-- را ذکر کرد. | |
view-encapsulation-- | ve- | تعیین نوع استراتژی view encapsulation مورد استفاده (مانند Emulated). |
change-detection-- | cd- | تعیین استراتژی change detection مورد استفاده (مانند OnPush). |
dry-run-- | d- | گزارش فایلهای تولیدی، بدون نوشتن و تولید آنها (پیش فرض آن false است) |
prefix-- | تعیین صریح prefix مورد استفادهی در حین مقدار دهی selectorها که در قسمت قبل در مورد آن بحث شد. |
برای مثال اگر خواستیم کامپوننتی را به همراه قالبها و شیوهنامههای inline (قرار گرفتهی داخل فایل ts. آن) تولید کنیم، میتوان از دستور ذیل کمک گرفت:
>ng generate component customer --inline-template --inline-style
>ng g c customer –it -is
اگر صرفا دستور ng generate component customer را اجرا کنیم (بدون هیچ گزینهی اضافهتری)، فایلهای ts (کلاس کامپوننت)، css (فایل شیوه نامه)، html (فایل قالب) و spec (فایل آزمون واحد کامپوننت) به صورت خودکار تولید خواهند شد.
همانطور که پیشتر نیز عنوان شد، اگر مطمئن نیستید که دستور درحال فراخوانی، چه فایلها و پوشههایی را ایجاد میکند، با ذکر پرچم dry-run-- و یا به صورت خلاصه d-، دستور مدنظر را شبیه سازی کنید تا صرفا گزارشی را از فایلهایی که قرار است تولید شوند، ارائه دهد.
نکتهی مهم دیگری که به همراه دستورات Angular CLI هستند، به روز رسانی خودکار فایل app.module.ts است:
>ng g c customer installing component create src\app\customer\customer.component.css create src\app\customer\customer.component.html create src\app\customer\customer.component.spec.ts create src\app\customer\customer.component.ts update src\app\app.module.ts
import { CustomerComponent } from './customer/customer.component'; @NgModule({ declarations: [ AppComponent, CustomerComponent ]})
مشاهدهی تغییرات انجام شدهی توسط Angular CLI به کمک سورس کنترل
همانطور که در قسمت قبل نیز عنوان شد، دستور ng new، کار آغاز یک مخزن Git را نیز به صورت خودکار انجام میدهد. در اینجا هر دستوری که توسط Angular CLI اجرا شود، به این مخزن کد commit خواهد شد.
برای مثال اگر کل پوشهی برنامه را توسط VSCode باز کنیم (کلیک راست در داخل ریشهی اصلی پروژه و انتخاب گزینهی Open With Code)، با مراجعهی به لیست تغییرات و بررسی diff آنها، به سادگی میتوان تشخیص داد که چه تغییراتی بر روی فایلها اعمال شدهاند.
ایجاد سایر اجزای جدید برنامه توسط Angular CLI
نام جزء | Alias | دستور |
service | s | ng g service customer-data |
pipe | p | ng g pipe init-caps |
class | cl | ng g class customer-model |
directive | d | ng g directive search |
interface | i | ng g interface orders |
enum | e | ng g enum gender |
module | m | ng generate module sales |
نکات تکمیلی
- در حین ایجاد یک directive جدید، پوشهای را برای آن ایجاد نمیکند. اگر میخواهید اینکار به صورت flat (بدون پوشه در اینجا) انجام نشود، گزینهی flat false-- را نیز قید کنید.
- در حین ایجاد یک سرویس جدید، اخطار «WARNING Service is generated but not provided, it must be provided to be used» را دریافت خواهید کرد. علت اینجا است که Angular CLI نمیداند که این سرویس را باید به کامپوننت خاصی اضافه کند یا به ماژول برنامه. به همین جهت یا باید به صورت دستی فایل src\app\app.module.ts را ویرایش و قسمت providers آنرا بر اساس نام این سرویس جدید تکمیل کرد و یا توسط سوئیچ m میتوان ماژول مدنظر را دقیقا ذکر کرد:
> ng g s sales -m app.module
این نکته در مورد تمام اجزایی که فایل app.module را به روز رسانی میکنند نیز صادق است. اگر برای مثال کامپوننتی قرار است ماژول جدید دیگری را به روز رسانی کند، میتوانید به صورت صریح نام ماژول آنرا قید کنید؛ در غیراینصورت از همان app.module پیش فرض استفاده خواهد شد.
- همانطور که مشاهده میکنید امکان تولید کلاس، اینترفیس و enum تایپاسکریپتی نیز در اینجا پیش بینی شدهاست. اگر خواستید کلاسی را درون پوشهی خاصی قرار دهید میتوانید محل پوشهی آنرا دقیقا ذکر کنید (در مورد اینترفیسها و enums و سایر اجزاء نیز به همین صورت):
> ng g cl models/customer
تغییر تنظیمات پیش فرض تولید کد پروژهی جاری
در قسمت قبل «تغییر پیش فرضهای عمومی Angular CLI» را بررسی کردیم. در اینجا نیز میتوان یکسری از خواص فایل angular-cli.json. را بازنویسی کرد؛ در قسمت defaults آن:
"defaults": { "styleExt": "css", "component": {} }
> ng set defaults.component.flat false > ng set defaults.directive.flat false > ng set defaults.styleExt sass
"defaults": { "styleExt": "sass", "component": { "flat": false }, "directive": { "flat": false } }
و اگر VSCode استفاده میکنید، به همراه intellisense کاملی در مورد اجزای مختلف این فایل json است (این intellisense را به صورت خودکار بر اساس اسکیمای این فایل و سرویس زبان Angular تهیه میکند).
- TypeScript نگارش 2.0.3 منتشر شد
- اطلاعات بیشتر
پس از نصب TypeScript 2.0 برای ویژوال استودیو و همچنین NodeJS
- ابتدا شماره نگارش ابزارهای آن در فایل csproj باید اصلاح شود:
- سپس در Resharper هم نیاز است این نگارش جدید را انتخاب کنید:
- اطلاعات بیشتر
پس از نصب TypeScript 2.0 برای ویژوال استودیو و همچنین NodeJS
npm install -g typescript@2.0
<TypeScriptToolsVersion>2.0</TypeScriptToolsVersion>
اشتراکها
مقایسه AngularJS و React
C# 9.0 به همراه قابلیت جدیدی است به نام «module initializer» که در اصل متدی است که در زمان بارگذاری اولیهی یک اسمبلی، به صورت خودکار اجرا میشود. عملکرد آن شبیه به سازندههای static کلاسها است؛ اما بجای اعمال به یک کلاس، اینبار به کل اسمبلی اعمال میشود. این قابلیت از روزهای ابتدایی طراحی CLR وجود خارجی داشته، اما در C# 9.0، امکان استفادهی عمومی از آن فراهم شدهاست.
روش تعریف یک module initializer
در مثال زیر، قالب ابتدایی یک ModuleInitializer را مشاهده میکنید:
متدی که قرار است به عنوان module initializer معرفی شود، باید مزین به ویژگی [ModuleInitializer] باشد و همچنین این متد باید دارای ویژگیهای زیر نیز باشد:
- باید استاتیک باشد.
- باید بدون پارامتر باشد.
- باید خروجی آن void باشد.
- نباید به صورت جنریک تعریف شود.
- این متد باید در همان اسمبلی، قابل دسترسی باشد؛ یعنی سطح دسترسی آن باید یا public و یا internal باشد.
- نباید local function باشد.
میتوان بیش از یک ModuleInitializer را در یک اسمبلی تعریف کرد
به مثال زیر دقت کنید:
در اینجا بیش از یک متد ModuleInitializer تعریف شدهاند. اگر بر روی ابتدای هر کدام از این متدها یک break-point را قرار دهید، مشاهده خواهید کرد که کدهای آنها پیش از شروع متد Main برنامه اجرا میشوند. همچنین نحوهی اجرای این متدها همواره مشخص و ترتیبی است؛ از بالا به پایین.
این مورد یکی از مهمترین تفاوتهای module initializerها با سازندههای static است. ترتیب اجرای سازندههای static مشخص نیست و بر اساس کدهای کلاینت و زمان دسترسی به کلاسهای مختلف، سازندهی استاتیک کلاس A میتواند پس از سازندهی استاتیک کلاس B اجرا شود و یا برعکس. اما همواره نحوهی اجرای module initializerها مشخص و ترتیبی است و همچنین نیازی به فراخوانی آنها توسط هیچ کلاینتی نیست.
موارد کاربرد module initializerها
نمونهی بسیار پرکاربرد module initializer ها، اجرای کدهایی پیش از شروع به اجرای آزمونهای خودکار یک برنامهاست؛ مانند کدهایی که یک بانک اطلاعاتی را ایجاد و مقدار دهی اولیه میکنند و پس از آن قرار است آزمایشهای برنامه بر روی این بانک اطلاعاتی مشخص، اجرا شوند.
روش تعریف یک module initializer
در مثال زیر، قالب ابتدایی یک ModuleInitializer را مشاهده میکنید:
namespace CS9Features { using System.Runtime.CompilerServices; internal static class TestModuleInitializer { [ModuleInitializer] public static void MyModuleInitializer() { // put your module initializer here } } }
- باید استاتیک باشد.
- باید بدون پارامتر باشد.
- باید خروجی آن void باشد.
- نباید به صورت جنریک تعریف شود.
- این متد باید در همان اسمبلی، قابل دسترسی باشد؛ یعنی سطح دسترسی آن باید یا public و یا internal باشد.
- نباید local function باشد.
میتوان بیش از یک ModuleInitializer را در یک اسمبلی تعریف کرد
به مثال زیر دقت کنید:
namespace CS9Features { using System.Runtime.CompilerServices; internal static class TestModuleInitializer { [ModuleInitializer] public static void MyModuleInitializer1() { // put your module initializer here } [ModuleInitializer] public static void MyModuleInitializer2() { // put your module initializer here } } }
این مورد یکی از مهمترین تفاوتهای module initializerها با سازندههای static است. ترتیب اجرای سازندههای static مشخص نیست و بر اساس کدهای کلاینت و زمان دسترسی به کلاسهای مختلف، سازندهی استاتیک کلاس A میتواند پس از سازندهی استاتیک کلاس B اجرا شود و یا برعکس. اما همواره نحوهی اجرای module initializerها مشخص و ترتیبی است و همچنین نیازی به فراخوانی آنها توسط هیچ کلاینتی نیست.
موارد کاربرد module initializerها
نمونهی بسیار پرکاربرد module initializer ها، اجرای کدهایی پیش از شروع به اجرای آزمونهای خودکار یک برنامهاست؛ مانند کدهایی که یک بانک اطلاعاتی را ایجاد و مقدار دهی اولیه میکنند و پس از آن قرار است آزمایشهای برنامه بر روی این بانک اطلاعاتی مشخص، اجرا شوند.