اشتراکها
AngularJS یک فریم ورک جاوا اسکریپتی، برای ساخت برنامههای تک صفحهای سمت کاربر، توسط HTML ،CSS و جاوا اسکریپت است. این فریم ورک، حاوی اجزایی برای data binding، طراحی ماژولار، کار با سرویسهای سمت سرور وب و امثال آن است. Angular 2 بازنویسی کامل نگارش 1 آن است و اهداف زیر را دنبال میکند:
- سرعت بالاتر بارگذاری و اجرای کدها
- استفاده از آخرین فناوریهای وب مانند ES 6 و وب کامپوننتها با پشتیبانی تا IE 9.
- سطح API آن با طراحی جدید آن، به شدت کاهش یافته و خلاصه شدهاست. همین امر یادگیری آنرا نیز سادهتر میکند.
برای یادگیری Angular 2 نیازی به فراگیری Angular 1 نیست. در اینجا با آشنایی با TypeScript، به این نتیجه خواهید رسید که برنامههای Angular 2 چیزی بیشتر از یک مثال عملی TypeScript نیستند. زبان TypeScript، زبان اول و توصیه شدهی کار با Angular 2 است و مزیت آن دسترسی به تمام قابلیتهای ES 6 است؛ با این تفاوت که کامپایلر TypeScript قادر است آنها را به ES 5 یا نگارش فعلی جاوا اسکریپت که توسط تمام مرورگرها پشتیبانی میشود، ترجمه و تبدیل کند. به این نحو به یک طراحی شیءگرا، مدرن و با قابلیت نگهداری بالا خواهید رسید که با تمام مرورگرهای جدید نیز سازگار است.
بنابراین پیشنیازهای اصلی کار با Angular 2، فراگیری ES 6 و TypeScript هستند که دو سری ویژه و مختص به آنها در سایت جاری تهیه شدهاند:
«مبانی ES 6»
«مبانی TypeScript»
در این قسمت قصد داریم پیشنیازهای دریافت و نصب اجزاء و وابستگیهای AngularJS 2 را به همراه TypeScript، در ویژوال استودیو 2015 بررسی کنیم. البته استفاده از ویژوال استودیو در اینجا ضروری نیست و اساسا AngularJS وابستگی به ویژوال استودیو ندارد. اگر به دنبال پشتیبانی بهتری از TypeScript هستید، VSCode رایگان، سورس باز و چند سکویی، گزینهی بسیار بهتری است نسبت به ویژوال استودیوی کامل. البته این مورد تعجبی هم ندارد؛ از این جهت که VSCode با TypeScript نوشته شدهاست.
اهمیت آشنایی با npm
اگر در طی سالهای اخیر با ویژوال استودیو کار کرده باشید، به طور قطع با NuGet نیز آشنا هستید. NuGet به عنوان یک package manager دات نتی شناخته میشود و کار آن دریافت وابستگیهای یک پروژه، از مخزنی مشخص و نصب و به روز رسانی خودکار آنها است. اما این روزها خارج از محیط توسعهی مایکروسافت، مدیرهای بستههای دیگری مانند Bower نیز برای نصب و به روز رسانی بستههای front end مانند کتابخانههای CSS ایی و جاوا اسکریپتی، بسیار رواج پیدا کردهاند. Bower یکی از ابزارهای NodeJS است که توسط NPM یا NodeJS Package Manager نصب میشود. به این معنا که استفاده از Bower به معنای استفاده از NPM است. پیش از این از NPM صرفا جهت نصب بستههای مرتبط با NodeJS استفاده میشد، اما در طی یکسال اخیر، استفاده از NPM نیز برای مدیریت بستههای front end رواج پیدا کردهاست و در صدر مدیر بستههای نصب کتابخانههای front end قرار دارد. همچنین در این حالت شما تنها نیاز به یک ابزار و یک فایل تنظیمات آن خواهید داشت، بجای استفاده از چندین ابزار و چندین فایل تنظیمات جداگانه. به علاوه این روزها انجام کارهای جدی جاوا اسکریپتی بدون دانش NPM دیگر میسر نیست. بهترین ابزارها، کامپایلرها، فشرده کنندههای front end و امثال آنها، تحت NodeJS اجرا میشوند. برای کار با AngularJS 2.0 و دریافت وابستگیهای آن نیز استفاده از npm، روش پیش فرض و توصیه شدهاست.
کار با npm جهت دریافت وابستگیهای کتابخانههای front end
برای کار با npm یا میتوان از دستورات خط فرمان آن به صورت مستقیم استفاده کرد و یا از امکانات یکپارچگی آن با ویژوال استودیو نیز بهره گرفت که ما در ادامه از این روش استفاده خواهیم کرد. البته توانمندیهای خط فرمان npm فراتر است از امکانات توکار VS.NET، اما در اینجا نیازی به آنها نیست و هدف صرفا دریافت و به روز رسانی وابستگیهای مرتبط است.
ویژوال استودیوی 2015 به همراه ابزارهای NodeJS ارائه میشود. اما مشکل اینجا است که این ابزارها هم اکنون قدیمی شدهاند و تطابقی با آخرین نگارش ابزارهای NodeJS ندارند. برای نمونه حین نصب وابستگیهای AngularJS 2.0 که یکی از آنها RxJS است، یک چنین خروجی را در پنجرهی output ویژوال استودیو مشاهده میکنید:
به این معنا که نگارشهای اخیر RxJS نیاز به npm با نگارشی بیشتر از 2 را دارند؛ اما نگارش npm پیش فرض ویژوال استودیو 1.4.9 است (البته باید دقت داشت که من به روز رسانی دوم VS 2015 را هم نصب کردهام). برای رهایی از این مشکل، تنها کافی است تا به ویژوال استودیو اعلام کنیم از نسخهی اصلی خط فرمان npm، بجای نسخهی پیش فرض خودش استفاده کند:
همانطور که در تصویر نیز ملاحظه میکنید، به مسیر Tools->Options->Projects and Solutions->External Web Tools مراجعه کرده و متغیر محیطی PATH ویندوز را به ابتدای لیست منتقل کنید. به این صورت ابزارهای به روز شدهی خط فرمان، مقدم خواهند شد بر ابزارهای قدیمی به همراه نگارش فعلی ویژوال استودیو.
البته فرض بر این است که آخرین نگارش nodejs را از آدرس https://nodejs.org/en دریافت و نصب کردهاید. با نصب آن، برنامه npm، در خط فرمان ویندوز به صورت مستقیم قابل استفاده خواهد بود؛ از این جهت که مسیر آن به PATH ویندوز اضافه شدهاست:
افزودن فایل project.json به پروژه
تا اینجا فرض بر این است که nodejs را از سایت آن دریافت و نصب کردهاید. همچنین متغیر PATH را در External Web Tools ویژوال استودیو به ابتدای لیست آن منتقل کردهاید تا همواره از آخرین نگارش npm نصب شدهی در سیستم، استفاده شود.
پس از آن همانند نیوگت که از فایل xml ایی به نام packages.config برای ثبت آخرین تغییرات خودش استفاده میکند، npm نیز از فایلی به نام package.json برای ذکر وابستگیهای مورد نیاز پروژه بهره میبرد. برای افزودن آن، از منوی Project گزینهی Add new item را انتخاب کرده و سپس npm را در آن جستجو کنید:
در اینجا نام پیش فرض package.json را پذیرفته و این فایل را به پروژه و ریشهی آن اضافه کنید.
اگر گزینهی فوق را در لیست Add new item مشاهده نمیکنید، مهم نیست. یک فایل متنی را به نام package.json به ریشهی پروژهی جاری اضافه کنید.
در ادامه محتوای این فایل را به نحو ذیل تغییر دهید:
این فایل تنظیمات، سبب بارگذاری خودکار وابستگیهای مورد نیاز AngularJS 2.0 در ویژوال استودیو میشود.
چند نکته:
- هر زمانیکه این فایل را ذخیره کنید، بلافاصله کار دریافت این بستهها از اینترنت آغاز خواهد شد. جزئیات آنرا میتوان در پنجرهی output ویژوال استودیو مشاهده کرد (و حتما اینکار را جهت دیباگ کار انجام دهید. بسیاری از مشکلات و خطاها، در اینجا لاگ میشوند). بنابراین اگر قصد دارید کار همگام سازی تغییرات را انجام دهید، فقط کافی است دکمههای ctrl+s یا save را بر روی این فایل اعمال کنید.
- کاری که دکمهی ctrl+s در این فایل انجام میدهد، اعمال خودکار دستور npm install بر روی پوشهای است که package.json در آن قرار دارد. بنابراین برای دریافت این بستهها، روش خط فرمان آن، ابتدا وارد شدن به ریشهی پروژهی جاری و سپس صدور دستور npm install است (که نیازی به آن نیست و ویژوال استودیو اینکار را به صورت خودکار انجام میدهد).
- بستههای دریافت شده، در پوشهای به نام node_modules در ریشهی پروژه ذخیره میشوند:
برای مشاهدهی آنها میتوان بر روی دکمهی show all files در solution explorer کلیک نمائید.
- درون فایل package.json، پشتیبانی کاملی از intellisense وجود دارد. برای مثال اگر علاقمند بودید تا آخرین نگارش AngularJS را مشاهده کنید، پس از خاصیت angular2 در تنظیمات فوق، " را تایپ کنید تا منوی تکمیل کنندهای ظاهر شود:
بدیهی است این منو جهت دریافت آخرین اطلاعات، نیاز به اتصال به اینترنت را دارد.
البته همیشه آخرین شماره نگارش AngularJS 2.0 را در این آدرس نیز میتوانید مشاهده کنید: CHANGELOG.md
- در این فایل شماره نگارش آغاز شدهای با ^ مانند "3.1.2^" به این معنا است که اجازهی نصب نگارشهای جدیدتری از 3.1.2 نیز داده شدهاست.
به روز رسانی کامپایلر TypeScript
نیاز است یکبار مطلب «مبانی TypeScript؛ تنظیمات TypeScript در ویژوال استودیو» را جهت آشنایی با نحوهی به روز رسانی اجزای مرتبط با TypeScript مطالعه کنید.
افزودن فایل tsconfig.json به پروژه
مرحلهی بعد شروع به کار با AngularJS و TypeScript، انجام تنظیمات کامپایلر TypeScript است. برای این منظور از منوی پروژه، گزینهی Add new item، عبارت typescript را جستجو کرده و در لیست ظاهر شده، گزینهی TypeScript JSON Configuration File را با نام پیش فرض آن انتخاب کنید:
اگر این گزینهی ویژه را در لیست add new items ندارید، مهم نیست. یک فایل متنی را به نام tsconfig.json به ریشهی پروژهی جاری اضافه کنید.
پس از افزودن فایل tsconfig.json به ریشهی سایت، تنظیمات آنرا به نحو ذیل تغییر دهید:
در مورد جزئیات این تنظیمات در سری «مبانی TypeScript» و «تنظیمات کامپایلر TypeScript» بیشتر بحث شدهاست. فایل ویژهی tsconfig.json تنظیمات پیش فرض ویژوال استودیو را جهت کار با TypeScript بازنویسی میکند. بنابراین زمانیکه از این فایل استفاده میشود، دیگر نیازی نیست به گزینهی مختلف پروژه، جهت تنظیم TypeScript مراجعه کرد.
برای نمونه خاصیت compileOnSave سبب خواهد شد تا پس از ذخیره سازی یک فایل ts، بلافاصله فایل js معادل آْن تولید شود. نوع ماژولها در اینجا به system.js تنظیم شدهاست و خروجی کدهای js آن از نوع ES 5 درنظر گرفته شدهاست. همچنین فعال سازی decorators نیز در اینجا صورت گرفتهاست. از این جهت که AngularJS2 استفادهی گستردهای را از این مفهوم، انجام میدهد.
در قسمت excludes به کامپایلر TypeScript اعلام شدهاست تا از یک سری از مسیرها مانند پوشهی node_modules که پیشتر آنرا تنظیم و دریافت کردیم، صرفنظر کند.
خلاصهی بحث
تا اینجا با نحوهی نصب پیشنیازهای AngularJS 2 و همچنین TypeScript آشنا شدیم. به صورت خلاصه:
- nmp اصلی را از سایت nodejs دریافت و نصب کنید.
- متغیر PATH را در ویژوال استودیو، به ابتدای لیست ابزارهای خارجی وب آن منتقل کنید تا از npm اصلی استفاده کند.
- فایل project.json را با محتوای ذکر شده، به ریشهی پروژه اضافه کنید. سپس یکبار آنرا save کنید تا وابستگیها را از اینترنت دریافت کند.
- اطمینان حاصل کنید که آخرین کامپایلر TypeScript را نصب کردهاید.
- فایل tsconfig.json را با محتوای ذکر شده، به ریشهی پروژه اضافه کنید.
- سرعت بالاتر بارگذاری و اجرای کدها
- استفاده از آخرین فناوریهای وب مانند ES 6 و وب کامپوننتها با پشتیبانی تا IE 9.
- سطح API آن با طراحی جدید آن، به شدت کاهش یافته و خلاصه شدهاست. همین امر یادگیری آنرا نیز سادهتر میکند.
برای یادگیری Angular 2 نیازی به فراگیری Angular 1 نیست. در اینجا با آشنایی با TypeScript، به این نتیجه خواهید رسید که برنامههای Angular 2 چیزی بیشتر از یک مثال عملی TypeScript نیستند. زبان TypeScript، زبان اول و توصیه شدهی کار با Angular 2 است و مزیت آن دسترسی به تمام قابلیتهای ES 6 است؛ با این تفاوت که کامپایلر TypeScript قادر است آنها را به ES 5 یا نگارش فعلی جاوا اسکریپت که توسط تمام مرورگرها پشتیبانی میشود، ترجمه و تبدیل کند. به این نحو به یک طراحی شیءگرا، مدرن و با قابلیت نگهداری بالا خواهید رسید که با تمام مرورگرهای جدید نیز سازگار است.
بنابراین پیشنیازهای اصلی کار با Angular 2، فراگیری ES 6 و TypeScript هستند که دو سری ویژه و مختص به آنها در سایت جاری تهیه شدهاند:
«مبانی ES 6»
«مبانی TypeScript»
در این قسمت قصد داریم پیشنیازهای دریافت و نصب اجزاء و وابستگیهای AngularJS 2 را به همراه TypeScript، در ویژوال استودیو 2015 بررسی کنیم. البته استفاده از ویژوال استودیو در اینجا ضروری نیست و اساسا AngularJS وابستگی به ویژوال استودیو ندارد. اگر به دنبال پشتیبانی بهتری از TypeScript هستید، VSCode رایگان، سورس باز و چند سکویی، گزینهی بسیار بهتری است نسبت به ویژوال استودیوی کامل. البته این مورد تعجبی هم ندارد؛ از این جهت که VSCode با TypeScript نوشته شدهاست.
اهمیت آشنایی با npm
اگر در طی سالهای اخیر با ویژوال استودیو کار کرده باشید، به طور قطع با NuGet نیز آشنا هستید. NuGet به عنوان یک package manager دات نتی شناخته میشود و کار آن دریافت وابستگیهای یک پروژه، از مخزنی مشخص و نصب و به روز رسانی خودکار آنها است. اما این روزها خارج از محیط توسعهی مایکروسافت، مدیرهای بستههای دیگری مانند Bower نیز برای نصب و به روز رسانی بستههای front end مانند کتابخانههای CSS ایی و جاوا اسکریپتی، بسیار رواج پیدا کردهاند. Bower یکی از ابزارهای NodeJS است که توسط NPM یا NodeJS Package Manager نصب میشود. به این معنا که استفاده از Bower به معنای استفاده از NPM است. پیش از این از NPM صرفا جهت نصب بستههای مرتبط با NodeJS استفاده میشد، اما در طی یکسال اخیر، استفاده از NPM نیز برای مدیریت بستههای front end رواج پیدا کردهاست و در صدر مدیر بستههای نصب کتابخانههای front end قرار دارد. همچنین در این حالت شما تنها نیاز به یک ابزار و یک فایل تنظیمات آن خواهید داشت، بجای استفاده از چندین ابزار و چندین فایل تنظیمات جداگانه. به علاوه این روزها انجام کارهای جدی جاوا اسکریپتی بدون دانش NPM دیگر میسر نیست. بهترین ابزارها، کامپایلرها، فشرده کنندههای front end و امثال آنها، تحت NodeJS اجرا میشوند. برای کار با AngularJS 2.0 و دریافت وابستگیهای آن نیز استفاده از npm، روش پیش فرض و توصیه شدهاست.
کار با npm جهت دریافت وابستگیهای کتابخانههای front end
برای کار با npm یا میتوان از دستورات خط فرمان آن به صورت مستقیم استفاده کرد و یا از امکانات یکپارچگی آن با ویژوال استودیو نیز بهره گرفت که ما در ادامه از این روش استفاده خواهیم کرد. البته توانمندیهای خط فرمان npm فراتر است از امکانات توکار VS.NET، اما در اینجا نیازی به آنها نیست و هدف صرفا دریافت و به روز رسانی وابستگیهای مرتبط است.
ویژوال استودیوی 2015 به همراه ابزارهای NodeJS ارائه میشود. اما مشکل اینجا است که این ابزارها هم اکنون قدیمی شدهاند و تطابقی با آخرین نگارش ابزارهای NodeJS ندارند. برای نمونه حین نصب وابستگیهای AngularJS 2.0 که یکی از آنها RxJS است، یک چنین خروجی را در پنجرهی output ویژوال استودیو مشاهده میکنید:
npm WARN engine rxjs@5.0.0-beta.6: wanted: {"npm":">=2.0.0"} (current: {"node":"v0.10.31","npm":"1.4.9"})
همانطور که در تصویر نیز ملاحظه میکنید، به مسیر Tools->Options->Projects and Solutions->External Web Tools مراجعه کرده و متغیر محیطی PATH ویندوز را به ابتدای لیست منتقل کنید. به این صورت ابزارهای به روز شدهی خط فرمان، مقدم خواهند شد بر ابزارهای قدیمی به همراه نگارش فعلی ویژوال استودیو.
البته فرض بر این است که آخرین نگارش nodejs را از آدرس https://nodejs.org/en دریافت و نصب کردهاید. با نصب آن، برنامه npm، در خط فرمان ویندوز به صورت مستقیم قابل استفاده خواهد بود؛ از این جهت که مسیر آن به PATH ویندوز اضافه شدهاست:
افزودن فایل project.json به پروژه
تا اینجا فرض بر این است که nodejs را از سایت آن دریافت و نصب کردهاید. همچنین متغیر PATH را در External Web Tools ویژوال استودیو به ابتدای لیست آن منتقل کردهاید تا همواره از آخرین نگارش npm نصب شدهی در سیستم، استفاده شود.
پس از آن همانند نیوگت که از فایل xml ایی به نام packages.config برای ثبت آخرین تغییرات خودش استفاده میکند، npm نیز از فایلی به نام package.json برای ذکر وابستگیهای مورد نیاز پروژه بهره میبرد. برای افزودن آن، از منوی Project گزینهی Add new item را انتخاب کرده و سپس npm را در آن جستجو کنید:
در اینجا نام پیش فرض package.json را پذیرفته و این فایل را به پروژه و ریشهی آن اضافه کنید.
اگر گزینهی فوق را در لیست Add new item مشاهده نمیکنید، مهم نیست. یک فایل متنی را به نام package.json به ریشهی پروژهی جاری اضافه کنید.
در ادامه محتوای این فایل را به نحو ذیل تغییر دهید:
{ "name": "asp-net-mvc5x-angular2x", "version": "1.0.0", "author": "DNT", "description": "", "scripts": {}, "license": "Apache-2.0", "dependencies": { "jquery": "2.2.3", "angular2": "2.0.0-beta.15", "systemjs": "^0.19.26", "es6-promise": "^3.1.2", "es6-shim": "^0.35.0", "reflect-metadata": "0.1.2", "rxjs": "5.0.0-beta.2", "zone.js": "^0.6.12", "bootstrap": "^3.3.6" }, "devDependencies": { "typescript": "^1.8.9", "typings": "^0.8.1" }, "repository": { } }
چند نکته:
- هر زمانیکه این فایل را ذخیره کنید، بلافاصله کار دریافت این بستهها از اینترنت آغاز خواهد شد. جزئیات آنرا میتوان در پنجرهی output ویژوال استودیو مشاهده کرد (و حتما اینکار را جهت دیباگ کار انجام دهید. بسیاری از مشکلات و خطاها، در اینجا لاگ میشوند). بنابراین اگر قصد دارید کار همگام سازی تغییرات را انجام دهید، فقط کافی است دکمههای ctrl+s یا save را بر روی این فایل اعمال کنید.
- کاری که دکمهی ctrl+s در این فایل انجام میدهد، اعمال خودکار دستور npm install بر روی پوشهای است که package.json در آن قرار دارد. بنابراین برای دریافت این بستهها، روش خط فرمان آن، ابتدا وارد شدن به ریشهی پروژهی جاری و سپس صدور دستور npm install است (که نیازی به آن نیست و ویژوال استودیو اینکار را به صورت خودکار انجام میدهد).
- بستههای دریافت شده، در پوشهای به نام node_modules در ریشهی پروژه ذخیره میشوند:
برای مشاهدهی آنها میتوان بر روی دکمهی show all files در solution explorer کلیک نمائید.
- درون فایل package.json، پشتیبانی کاملی از intellisense وجود دارد. برای مثال اگر علاقمند بودید تا آخرین نگارش AngularJS را مشاهده کنید، پس از خاصیت angular2 در تنظیمات فوق، " را تایپ کنید تا منوی تکمیل کنندهای ظاهر شود:
بدیهی است این منو جهت دریافت آخرین اطلاعات، نیاز به اتصال به اینترنت را دارد.
البته همیشه آخرین شماره نگارش AngularJS 2.0 را در این آدرس نیز میتوانید مشاهده کنید: CHANGELOG.md
- در این فایل شماره نگارش آغاز شدهای با ^ مانند "3.1.2^" به این معنا است که اجازهی نصب نگارشهای جدیدتری از 3.1.2 نیز داده شدهاست.
به روز رسانی کامپایلر TypeScript
نیاز است یکبار مطلب «مبانی TypeScript؛ تنظیمات TypeScript در ویژوال استودیو» را جهت آشنایی با نحوهی به روز رسانی اجزای مرتبط با TypeScript مطالعه کنید.
افزودن فایل tsconfig.json به پروژه
مرحلهی بعد شروع به کار با AngularJS و TypeScript، انجام تنظیمات کامپایلر TypeScript است. برای این منظور از منوی پروژه، گزینهی Add new item، عبارت typescript را جستجو کرده و در لیست ظاهر شده، گزینهی TypeScript JSON Configuration File را با نام پیش فرض آن انتخاب کنید:
اگر این گزینهی ویژه را در لیست add new items ندارید، مهم نیست. یک فایل متنی را به نام tsconfig.json به ریشهی پروژهی جاری اضافه کنید.
پس از افزودن فایل tsconfig.json به ریشهی سایت، تنظیمات آنرا به نحو ذیل تغییر دهید:
{ "compileOnSave": true, "compilerOptions": { "target": "es5", "module": "system", "moduleResolution": "node", "noImplicitAny": false, "noEmitOnError": true, "removeComments": false, "sourceMap": true, "emitDecoratorMetadata": true, "experimentalDecorators": true }, "exclude": [ "node_modules", "wwwroot", "typings/main", "typings/main.d.ts" ] }
برای نمونه خاصیت compileOnSave سبب خواهد شد تا پس از ذخیره سازی یک فایل ts، بلافاصله فایل js معادل آْن تولید شود. نوع ماژولها در اینجا به system.js تنظیم شدهاست و خروجی کدهای js آن از نوع ES 5 درنظر گرفته شدهاست. همچنین فعال سازی decorators نیز در اینجا صورت گرفتهاست. از این جهت که AngularJS2 استفادهی گستردهای را از این مفهوم، انجام میدهد.
در قسمت excludes به کامپایلر TypeScript اعلام شدهاست تا از یک سری از مسیرها مانند پوشهی node_modules که پیشتر آنرا تنظیم و دریافت کردیم، صرفنظر کند.
خلاصهی بحث
تا اینجا با نحوهی نصب پیشنیازهای AngularJS 2 و همچنین TypeScript آشنا شدیم. به صورت خلاصه:
- nmp اصلی را از سایت nodejs دریافت و نصب کنید.
- متغیر PATH را در ویژوال استودیو، به ابتدای لیست ابزارهای خارجی وب آن منتقل کنید تا از npm اصلی استفاده کند.
- فایل project.json را با محتوای ذکر شده، به ریشهی پروژه اضافه کنید. سپس یکبار آنرا save کنید تا وابستگیها را از اینترنت دریافت کند.
- اطمینان حاصل کنید که آخرین کامپایلر TypeScript را نصب کردهاید.
- فایل tsconfig.json را با محتوای ذکر شده، به ریشهی پروژه اضافه کنید.
در حین import ماژولهای TypeScript ایی پس از مدتی به یک چنین کدهایی خواهیم رسید:
در این حالت، در یک پوشه برای import ماژولی مشخص، چنین import ایی را خواهیم داشت:
و در پوشهی تو در توی دیگری، این تعریف به صورت زیر تغییر میکند:
و در آخر برنامه پر میشود از مسیرهای نسبی ‘../../../..’ مانند. به این ترتیب جابجا کردن فایلها و Refactoring آنها، مشکل میشود.
خوشبختانه کامپایلر TypeScript به همراه تنظیمات baseUrl و paths است که توسط آنها میتوان این مسیرهای نسبی را به مسیرهای مطلق تبدیل کرد و در این حالت اهمیتی ندارد که ماژول مدنظر از چه سطحی و درون چه پوشهی تو در تویی فراخوانی میشود، این مسیر import همواره ثابت خواهد بود.
تنظیمات فایل tsconfig.json برای معرفی مسیرهای مطلق ماژولها
فرض کنید میخواهید از یکی از سرویسهای Core Module استفاده کنید:
بسته به عمق پوشهی استفاده کننده، به یک چنین تعریفی خواهید رسید:
برای بهبود این وضعیت، فایل tsconfig.json و یا همان تنظیمات کامپایلر TypeScript را به نحو ذیل تکمیل میکنیم:
در اینجا baseUrl به پوشهی src برنامه اشاره میکند و مسیرهای بعدی بر این اساس محاسبه میشوند. در ادامه در قسمت paths، ابتدا یک نام مستعار ذکر میشود و سپس مسیری که ارائه دهندهی آن است. ذکر @ در اینجا اختیاری است؛ اما ذکر */ها اجباری است.
پس از این تغییرات، اکنون افزونهی پیشنهاد دهندهی imports، هر دو حالت استفادهی از مسیر مطلق بر اساس نام مستعار تعریف شده:
و یا استفادهی از مسیر نسبی را نیز پیشنهاد میدهد:
برای مثال اگر دقت کرده باشید، روش import اجزای خود Angular به صورت زیر است:
علت اینجا است که Angular از تعریف مشابهی به صورت زیر برای نگاشت پوشهی node_modules آن به angular@ استفاده میکند:
و ذکر @ اختیاری هم از اینجا اقتباس شدهاست.
یک نکتهی مهم: تنظیمات فوق بدون تنظیمات معادل webpack ناقص هستند
اگر از برنامهی Angular CLI استفاده میکنید، تنظیمات ذکر شده، تا همینجا به پایان میرسند؛ چون webpack جزئی از Angular CLI است و تنظیمات پیش فرض آن، قسمت baseUrl و paths فایل tsconfig.json را به صورت خودکار پردازش میکند. اما اگر از TypeScript در محیطهای دیگری استفاده میکنید که از webpack به صورت مجزایی استفاده میکنند، نیاز است قسمت resolve.alias فایل webpack.config.js را نیز جهت معرفی این تغییرات، اصلاح کنید. از این جهت که کامپایلر TypeScript این مسیرهای مطلق را در حین تولید فایلهای نهایی JavaScript ایی معادل، به مسیرهای نسبی بازنویسی نمیکند و در این حالت webpack نمیداند که چطور باید این ماژولها را یافته و یکی کند.
کوتاه کردن مسیرهای مطلق با معرفی فایل ویژهی index.ts
تا اینجا بجای ذکر مسیر
به مسیر مطلق زیر رسیدیم (صرفنظر از محل قرارگیری ماژولی که قرار است آنرا import کند):
این را هم میخواهیم به صورت زیر کوتاهتر کنیم:
یعنی فقط app/core@ را ذکر کنیم.
برای اینکار نیاز است فایل ویژهای را به نام index.ts، در ریشهی پوشهی core ایجاد کنیم (src\app\core\index.ts)، با این محتوا:
در اینجا تمام ماژولهایی که توسط Core Module ارائه میشوند را یکبار export میکنیم.
برای نمونه اگر به پوشهی node_modules\@angular خود مجموعهی Angular هم مراجعه کنید، هر پوشهی src آن به همراه یک فایل index.d.ts شبیه تعاریف فوق نیز هست.
پس از افزودن فایل index.ts به ریشهی پوشهی مدنظر، اکنون در لیست پیشنهادات، ذکر app/core@ تنها نیز ظاهر شده و استفادهی از آن مجاز است:
import { SpecialCollection } from "../../special"; import { LoginComponent } from "../login"; import { TextUtils } from ".../../utils/text"; import { Router } from "../../../core/router";
import { Data } from '../data';
import { Data } from '../../../data';
خوشبختانه کامپایلر TypeScript به همراه تنظیمات baseUrl و paths است که توسط آنها میتوان این مسیرهای نسبی را به مسیرهای مطلق تبدیل کرد و در این حالت اهمیتی ندارد که ماژول مدنظر از چه سطحی و درون چه پوشهی تو در تویی فراخوانی میشود، این مسیر import همواره ثابت خواهد بود.
تنظیمات فایل tsconfig.json برای معرفی مسیرهای مطلق ماژولها
فرض کنید میخواهید از یکی از سرویسهای Core Module استفاده کنید:
بسته به عمق پوشهی استفاده کننده، به یک چنین تعریفی خواهید رسید:
import { BrowserStorageService } from "./../../core/browser-storage.service";
{ "compilerOptions": { "baseUrl": "src", "paths": { "@app/*": [ "app/*" ], "@app/core/*": [ "app/core/*" ], "@app/shared/*": [ "app/shared/*" ], "@env/*": [ "environments/*" ] } } }
پس از این تغییرات، اکنون افزونهی پیشنهاد دهندهی imports، هر دو حالت استفادهی از مسیر مطلق بر اساس نام مستعار تعریف شده:
import { BrowserStorageService } from "@app/core/browser-storage.service";
import { BrowserStorageService } from "./../../core/browser-storage.service";
برای مثال اگر دقت کرده باشید، روش import اجزای خود Angular به صورت زیر است:
import { Component } from '@angular/core';
"paths": { "@angular/*": ["node_modules/@angular/*"] },
یک نکتهی مهم: تنظیمات فوق بدون تنظیمات معادل webpack ناقص هستند
اگر از برنامهی Angular CLI استفاده میکنید، تنظیمات ذکر شده، تا همینجا به پایان میرسند؛ چون webpack جزئی از Angular CLI است و تنظیمات پیش فرض آن، قسمت baseUrl و paths فایل tsconfig.json را به صورت خودکار پردازش میکند. اما اگر از TypeScript در محیطهای دیگری استفاده میکنید که از webpack به صورت مجزایی استفاده میکنند، نیاز است قسمت resolve.alias فایل webpack.config.js را نیز جهت معرفی این تغییرات، اصلاح کنید. از این جهت که کامپایلر TypeScript این مسیرهای مطلق را در حین تولید فایلهای نهایی JavaScript ایی معادل، به مسیرهای نسبی بازنویسی نمیکند و در این حالت webpack نمیداند که چطور باید این ماژولها را یافته و یکی کند.
resolve: { extensions: ['*', '.js', '.ts'], modules: [ rootDir, path.join(rootDir, 'node_modules') ], alias: { '@app': 'src/app' } },
کوتاه کردن مسیرهای مطلق با معرفی فایل ویژهی index.ts
تا اینجا بجای ذکر مسیر
import { BrowserStorageService } from "./../../core/browser-storage.service";
import { BrowserStorageService } from "@app/core/browser-storage.service";
import { BrowserStorageService } from "@app/core";
برای اینکار نیاز است فایل ویژهای را به نام index.ts، در ریشهی پوشهی core ایجاد کنیم (src\app\core\index.ts)، با این محتوا:
export * from "./browser-storage.service"; export * from "./app-config.service"; export * from "./seo-service";
برای نمونه اگر به پوشهی node_modules\@angular خود مجموعهی Angular هم مراجعه کنید، هر پوشهی src آن به همراه یک فایل index.d.ts شبیه تعاریف فوق نیز هست.
پس از افزودن فایل index.ts به ریشهی پوشهی مدنظر، اکنون در لیست پیشنهادات، ذکر app/core@ تنها نیز ظاهر شده و استفادهی از آن مجاز است:
قطعا ASP.NET MVC 5.x به عنوان یک فریم ورک بالغ و با امکانات فراوان شناخته میشود که در این مساله هیچ بحثی نیست. اما آیا در همهی پروژهها حتما باید از این فریم ورک استفاده شود؟ امروزه اکثر وب اپلیکیشنها از فریم ورکهای SPA استفاده میکنند و بنده به وفور در پروژههای مختلف شاهد این بودهام که ASP.NET MVCی که در کنار آن استفاده میشود، عملا چیزی بیشتر از یک کنترلر Home و یک متد Index و حداکثر یک Layout، نیستند و معمولا در کنار آن از Web Api استفاده میکنند که حداقل در ASP.NET MVC 5.x چیزی کاملا مجزای از آن به حساب میآید. با این حال آیا واقعا از امکانات MVC 5.x استفاده شده است؟! یا فقط اینگونه پروژهها محدودیتهای MVC را به دوش میکشند؟
اکنون عملا تمام پکیجهای لازم را برای شروع به کار، در اختیار داریم (اگر از dotNetFrameWork نسخهی پایینتری بطور مثال 4.6.1 استفاده میکنید، بعد از اجرای دستور فوق، targetFramework شما به 461 اصلاح خواهد شد).
1) AppSettings برای کانفیگ Owin startup خواهد بود (در ادامهی مقاله آن را مینویسیم).
بعد از build کردن پروژه، در صورت خطا داشتن از Referencesها، System.Reflection و System.Runtime.Extensions را حذف کنید.
و همچنین یک پوشه دیگر را به نام ApiControllers به نام ProductsController با محتوای زیر:
حالا میتوانیم یه پروژهی یونیت تست نوشته و کلیات مراحل فوق را تست نماییم. unit test را به پروژه اضافه کنید و reference پروژهی اصلی خود را بدان اضافه کنید.
update-package فراموش نشود
در ادامه تست خود را اینگونه مینویسیم
بعد از اجرای تستها، باید تیک سبز کنارشان ایجاد شود.
در ASP.NET 4.x به صورت معمول ارسال درخواستها بدین صورت است که از سمت کلاینت به IIS و بعد از آن بر روی ISAPI نگاشت میشوند (یا Static File برای فایلهای استاتیک). پس عملا وابستگی شدیدی به IIS ایجاد شدهاست و اینکه مشکلات این وابستگی چیست در این مقاله نمیگنجد. اگر قرار باشد همین امروز پروژهای شروع شود قطعا ASP.NET 4.x گزینهی معقولی به نظر میرسد؛ اما در پروژههای حجیم بیزینسی که باید ماهها و شاید چندین سال بر روی نرم افزار آن کار شود، آیا آن موقع نیز ASP.NET مانند حال گزینهی معقولی است یا بطور مثال ASP.NET Core با امکانات منحصر به فردش جایگزین خواهد شد؟ در نگاه اول وقتی دو پروژهی ASP.NET 4.x و ASP.NET Core را در کنار هم میگذاریم، شاید اختلافات زیاد باشند و ارتقاء نرم افزار به ASP.NET Core سخت و یا حتی غیر ممکن به نظر برسد. اما آیا واقعا هیچ راهی وجود ندارد که هم اکنون نرم افزار خود را با ASP.NET 4.x که کاملا بالغ هم شده شروع کرده و بعدها به ASP.NET Core به روز رسانی شود؟
اینها سوالهایی است که قطعا قبل از شروع یک پروژهی بزرگ نرم افزاری باید از خود بپرسیم. شاید با نگاه عمیقتری بر روی این سوالها بتوان پاسخی مناسب را برای آنها داد. یکی از این راهحلها استفاده از استاندارد Owin و پیاده سازی آن به نام Katana است.
برای شروع پروژه ابتدا یک پروژهی ASP.NET 4.x از نوع empty را بسازید.
برای راحت شدن کار، ابتدا packages.config را باز کرده و کدهای زیر را جایگزین آن نمایید:
<?xml version="1.0" encoding="utf-8"?> <packages> <package id="Microsoft.AspNet.OData" version="6.0.0" targetFramework="net462" /> <package id="Microsoft.AspNet.SignalR.Core" version="2.2.1" targetFramework="net462" /> <package id="Microsoft.AspNet.SignalR.Owin" version="1.2.2" targetFramework="net462" /> <package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net462" /> <package id="Microsoft.AspNet.WebApi.Core" version="5.2.3" targetFramework="net462" /> <package id="Microsoft.AspNet.WebApi.Owin" version="5.2.3" targetFramework="net462" /> <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.2" targetFramework="net462" /> <package id="Microsoft.Extensions.DependencyInjection" version="1.0.0" targetFramework="net462" /> <package id="Microsoft.Extensions.DependencyInjection.Abstractions" version="1.0.0" targetFramework="net462" /> <package id="Microsoft.Net.Compilers" version="1.3.2" targetFramework="net462" developmentDependency="true" /> <package id="Microsoft.OData.Core" version="7.0.0" targetFramework="net462" /> <package id="Microsoft.OData.Edm" version="7.0.0" targetFramework="net462" /> <package id="Microsoft.Owin" version="3.0.1" targetFramework="net462" /> <package id="Microsoft.Owin.FileSystems" version="3.0.1" targetFramework="net462" /> <package id="Microsoft.Owin.Host.SystemWeb" version="3.0.1" targetFramework="net462" /> <package id="Microsoft.Owin.Security" version="3.0.1" targetFramework="net462" /> <package id="Microsoft.Owin.StaticFiles" version="3.0.1" targetFramework="net462" /> <package id="Microsoft.Spatial" version="7.0.0" targetFramework="net462" /> <package id="Newtonsoft.Json" version="9.0.1" targetFramework="net462" /> <package id="Owin" version="1.0" targetFramework="net462" /> <package id="System.Collections" version="4.0.11" targetFramework="net462" /> <package id="System.Collections.Concurrent" version="4.0.12" targetFramework="net462" /> <package id="System.ComponentModel" version="4.0.1" targetFramework="net462" /> <package id="System.Diagnostics.Debug" version="4.0.11" targetFramework="net462" /> <package id="System.Globalization" version="4.0.11" targetFramework="net462" /> <package id="System.Linq" version="4.1.0" targetFramework="net462" /> <package id="System.Linq.Expressions" version="4.1.0" targetFramework="net462" /> <package id="System.Reflection" version="4.1.0" targetFramework="net462" /> <package id="System.Resources.ResourceManager" version="4.0.1" targetFramework="net462" /> <package id="System.Runtime.Extensions" version="4.1.0" targetFramework="net462" /> <package id="System.Threading" version="4.0.11" targetFramework="net462" /> <package id="System.Threading.Tasks" version="4.0.11" targetFramework="net462" /> </packages>
ما پکیجهای OData و SignlarR , WebApi, Owin را اضافه نمودهایم و دستور زیر را برای اضافه شدن ارجاعات اجرا میکنیم:
PM>Update-Package -reinstall -Project YourProjectName
حال میخواهیم کمی کار اختیاری را نیز بر روی وب کانفیگ انجام دهیم که به performance نرم افزار شما بهبود قابل ملاحظهای را میافزاید. کدهای زیر را در وب کانفیگ جایگزین نمایید:
<?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="owin:AppStartup" value="OwinKatanaTest.OwinAppStartup, OwinKatanaTest" /> <!-- Owin App Startup Class --> <add key="webpages:Enabled" value="false" /> <!-- Disable asp.net web pages. Note that based on our current configuration, asp.net web forms, mvc and web pages won't work. This configuration is for owin stuffs only, for example asp.net web api & odata, signalr, etc. --> </appSettings> <system.web> <compilation debug="true" defaultLanguage="c#" enablePrefetchOptimization="true" optimizeCompilations="true" targetFramework="4.6.2"> <assemblies> <remove assembly="*" /> <!-- To improve app startup performance, our app will continue its work without this compilations, these are required for asp.net web forms, mvc and web pages. --> <add assembly="OwinKatanaTest" /> </assemblies> </compilation> <httpRuntime targetFramework="4.6.2" /> <httpModules> <!-- No need to these modules and handlers, owin handler itself will do everything for us --> <clear /> </httpModules> <httpHandlers> <clear /> </httpHandlers> <sessionState mode="Off" /> </system.web> <system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701" /> </compilers> </system.codedom> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Microsoft.AspNet.SignalR.Core" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-2.2.1.0" newVersion="2.2.1.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Reflection" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Runtime.Extensions" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" /> </dependentAssembly> </assemblyBinding> </runtime> <system.webServer> <validation validateIntegratedModeConfiguration="false" /> <modules runAllManagedModulesForAllRequests="false"> <!-- We're not going to remove all modules, some modules such as static & dynamic compression modules are really cool (-: --> <remove name="RewriteModule" /> <remove name="OutputCache" /> <remove name="Session" /> <remove name="WindowsAuthentication" /> <remove name="FormsAuthentication" /> <remove name="DefaultAuthentication" /> <remove name="RoleManager" /> <remove name="FileAuthorization" /> <remove name="UrlAuthorization" /> <remove name="AnonymousIdentification" /> <remove name="Profile" /> <remove name="UrlMappingsModule" /> <remove name="ServiceModel-4.0" /> <remove name="UrlRoutingModule-4.0" /> <remove name="ScriptModule-4.0" /> <remove name="Isapi" /> <remove name="IsapiFilter" /> <remove name="DigestAuthentication" /> <remove name="WindowsAuthentication" /> <remove name="ServerSideInclude" /> <remove name="DirectoryListing" /> <remove name="DefaultDocument" /> <remove name="CustomError" /> <remove name="Cgi" /> </modules> <defaultDocument> <!-- Default docs will be configured using owin static files middleware --> <files> <clear /> </files> </defaultDocument> <handlers> <!-- Only use this handler for all requests --> <clear /> <add name="Owin" verb="*" path="*" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler, Microsoft.Owin.Host.SystemWeb" /> </handlers> <httpProtocol> <customHeaders> <clear /> </customHeaders> </httpProtocol> </system.webServer> </configuration>
2) در تگ compilation اسمبلیهای اضافی را حذف مینماییم (برای بهبود performance از آنجایی که به asp.net web form یا mvc احتیاجی نداریم).
3) حذف http module و http handler در system.web (مربوط به iis 6).
4) در تگ system.codedom کامپایلر مربوط به vb را حذف مینماییم.
5) در تگ system.webserver ماژولها و هندلرهای اضافی را پاک مینماییم.
6) تگ defaultdocument، به دلیل اینکه از static file مربوط به owin استفاده میکنیم.
7) custom headersها را نیز پاک میکنیم.
بعد از build کردن پروژه، در صورت خطا داشتن از Referencesها، System.Reflection و System.Runtime.Extensions را حذف کنید.
یک ریشه جدید را به نام Model ساخته و مدلهای آزمایشی Product و Category را که هر دو فقط حاوی دو پراپرتی Id, Name میباشند، به آن اضافه کنید.
در root پروژه یک کلاس به نام OwinAppStartup را با محتوای زیر بسازید
using Microsoft.AspNet.SignalR; using Microsoft.OData; using Microsoft.OData.Edm; using Owin; using OwinKatanaTest.Model; using OwinKatanaTest.ODataControllers; using System.Collections.Generic; using System.Web.Http; using System.Web.OData.Builder; using System.Web.OData.Extensions; using System.Web.OData.Routing.Conventions; namespace OwinKatanaTest { public class OwinAppStartup { public void Configuration(IAppBuilder owinApp) { owinApp.Map("/odata", innerOwinAppForOData => { HttpConfiguration webApiODataConfig = new HttpConfiguration(); webApiODataConfig.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always; webApiODataConfig.Formatters.Clear(); IEnumerable<IODataRoutingConvention> conventions = ODataRoutingConventions.CreateDefault(); ODataModelBuilder modelBuilder = new ODataConventionModelBuilder(webApiODataConfig); modelBuilder.Namespace = modelBuilder.ContainerName = "Test"; var categoriesSetConfig = modelBuilder.EntitySet<Category>("Categories"); var getBestCategoryFunctionConfig = categoriesSetConfig.EntityType.Collection.Function(nameof(CategoriesController.GetBestCategory)); getBestCategoryFunctionConfig.ReturnsFromEntitySet<Category>("Categories"); IEdmModel edmModel = modelBuilder.GetEdmModel(); webApiODataConfig.MapODataServiceRoute("default", "", builder => { builder.AddService(ServiceLifetime.Singleton, sp => conventions); builder.AddService(ServiceLifetime.Singleton, sp => edmModel); }); innerOwinAppForOData.UseWebApi(webApiODataConfig); }); owinApp.Map("/api", innerOwinAppForWebApi => { HttpConfiguration webApiConfig = new HttpConfiguration(); webApiConfig.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always; webApiConfig.MapHttpAttributeRoutes(); webApiConfig.Routes.MapHttpRoute(name: "default", routeTemplate: "{controller}/{action}", defaults: new { action = RouteParameter.Optional }); innerOwinAppForWebApi.UseWebApi(webApiConfig); }); owinApp.Map("/signalr", innerOwinAppForSignalR => { innerOwinAppForSignalR.RunSignalR(new HubConfiguration { EnableDetailedErrors = true }); }); owinApp.UseStaticFiles(); owinApp.Run(async context => { await context.Response.WriteAsync("owin katana"); }); } } }
در وب کانفیگ، کار مربوط به استارتاپ را انجام دادیم و دیگر نیازی به قید کردن آن نیست. نگاشت اول، کانفیگ OData، دومی برای web api و همچنین سومی کانفیگ SignalR میباشد.
سپس یک پوشهی جدید را به نام ODataControllers حاوی کلاسی با نام CategoriesController بدین گونه بسازید:
using OwinKatanaTest.Model; using System.Web.Http; using System.Web.OData; namespace OwinKatanaTest.ODataControllers { public class CategoriesController : ODataController { [HttpGet] public Category GetBestCategory() { return new Category { Id = 1, Name = "Test" }; } } }
using OwinKatanaTest.Model; using System.Collections.Generic; using System.Web.Http; namespace OwinKatanaTest.ApiControllers { public class ProductsController : ApiController { [HttpGet] [Route("products/{categoryId}")] public List<Product> GetProductsByCategoryId(int categoryId) { return new List<Product> { new Product { Id = 1 , Name = "Test" } }; } } }
مانند پروژهی قبلی، package.config را اضافه کرده و همهی پکیجهای قبلی به علاوه پکیج زیر را اضافه کنید:
<package id="Microsoft.Owin.Testing" version="3.0.1" targetFramework="net462" />
در ادامه تست خود را اینگونه مینویسیم
using Microsoft.Owin.Testing; using Microsoft.VisualStudio.TestTools.UnitTesting; using OwinKatanaTest; using System.Net; using System.Net.Http; using System.Threading.Tasks; namespace Test { [TestClass] public class Test { [TestMethod] public async Task TestWebApi() { using (TestServer server = TestServer.Create<OwinAppStartup>()) { HttpResponseMessage apiResponse = await server.HttpClient.GetAsync("/api/products/1"); apiResponse.EnsureSuccessStatusCode(); Assert.AreEqual(HttpStatusCode.OK, apiResponse.StatusCode); } } [TestMethod] public async Task TestOData() { using (TestServer server = TestServer.Create<OwinAppStartup>()) { HttpResponseMessage odataResponse = await server.HttpClient.GetAsync("odata/Categories/Test.GetBestCategory"); odataResponse.EnsureSuccessStatusCode(); Assert.AreEqual(HttpStatusCode.OK, odataResponse.StatusCode); } } } }
الان باید solution شما چیزی شبیه به این باشد:
بعد از خواندن این مقاله شاید متوجه شده باشید که چقدر pipeline این پروژه شبیه به پروژههای ASP.NET Coreی است؛ یا بهتر است تصحیح کنم به عکس. بلکه ASP.NET Core هست که خیلی شبیه به این میباشد!
عملا سرویسهای شما کاملا مجزا شدهاند و میتوانید به راحتی یک فریم ورک SPA را به پروژهی خود اضافه کرده و برای Authentication هم Single Sign On Identity Server بسیار مناسب میباشد. بدون اینکه حتی برنامه نویسان بیزینسی پروژهی شما متوجه بشوند، با تغییراتی در کانفیگ این پروژه، میتوان آن را بروزرسانی نمود.
لینک دانلود پروژه OwinKatanaTest.zip
سلام
سال نو مبارک! به امید سالی بهتر از پارسال!
این روزها با هزینهای معادل هزینهی تهیهی یک هاست اشتراکی سالیانه برای بالاگذاری یک سایت معمولی در 5 سال قبل، میتوان یک VPS تهیه کرد و به این صورت قفل و کلید یک نیمچه سرور را (با 200 و خردهای مگ رم، 30 گیگ فضا، سرعت CPU نزدیک به 700 MHz و ویندوز سرور 2003 یا 2008) در اختیار شما قرار میدهند (البته به قول معروف هر چقدر پول بدهید همانقدر هم سخت افزار در اختیار شما قرار میدهند) بجای صرفا یک دایرکتوری مجازی محدود با 100 مگ فضای هاست که هر احدی در آن هاست اشتراکی میتواند سر مبارک را اندکی چرخانده و تمام زندگی شما را مرور کند و غیره!
استفادهی مفیدی هم که این VPS برای من داشته، ترنس لود کردن یک سری فایل است (با توجه به سرعتهای نجومی دریافت فایل این سرورها). برای مثال دریافت فایل از یوتیوب و انتقال به یک هاست دیگر برای دریافت سادهتر خودم و یا دیگران.
برای نمونه سایت dotnet-tv.com را در نظر بگیرید. تعدادی از ویدیوهای این سایت در یوتیوب هاست شده و از این دست زیاد هستند. خیلیها برای فرار از مشکلات کمبود پهنای باند از یوتیوب استفاده میکنند. یوتیوب هم که از این طرف بسته است. خوب، من الان میخواهم ویدیوی مربوط به ASP.Net MVC آن را مشاهده کنم، چکار باید کرد؟!
یک برنامهی سادهی کنسول را تهیه کردهام که این کار را برای VPS داران تسهیل میکند.
- دریافت فایل از یوتیوب
- آپلود خودکار آن به رپیدشیر
یک نمونه خروجی آن: (فایلهای یوتیوب سایت ذکر شده که به رپیدشیر منتقل شده)
دریافت
در سورس این برنامه موارد زیر پیاده سازی شده است:
- یافتن لینکهای یوتیوب سایت dotnet-tv.com با استفاده از regular expressions
- یافتن لینک دانلود مستقیم این فایلها از سایت یوتیوب که شامل استفاده از regular expressions برای استخراج قسمتهای مفید از صفحات و همچنین استفاده از امکانات Json دات نت فریم ورک سه و نیم برای parse قسمتهای استخراج شده است.
- ایجاد یک thread pool سفارشی که هر بار 7 لینک مستقیم را به صورت همزمان از یوتیوب دریافت میکند. (thread pool پیش فرض دات نت تمام تردها را به یکباره شروع میکند که برای اینکار مفید نیست. به همین جهت از این thread pool سفارشی شده استفاده شد)
پیش فرض فایلی که از سایت یوتیوب دریافت میشود MP4 با کیفیت بالا است که با fmt=18 در فایل Youtube.cs مشخص شده. فرمتهای دیگر را میتوانید از این فایل ایده بگیرید.
- آپلود فایل دریافتی از یوتیوب به یک اکانت رایگان کالکتور در رپیدشیر. (ماخذ این مورد در سایت code projects)
مشخصات این اکانت رایگان کالکتور در فایل app.config باید ذکر شود.
این سورس میتونه ایدهی ابتدایی بسیاری از کارهای مشابه باشد. برای مثال ایجاد یک وب سرویس، یک وب سایت، یک سرویس ایمیلی و غیره.
پ.ن.
کار انجام شده فعالیت وارز محسوب نمیشود زیرا مجوز ویدیوهای سایت یوتیوب این امکان توزیع (و بسیاری موارد دیگر) را به شما میدهد.
در ادامهی طراحی مبتنی بر مینیمالیسم C# 10.0، پس از پیشفرض شدن «top level programs» و همچنین «کاهش تعداد بار تعاریف usingها»، تغییر سوم صورت گرفتهی در قالبهای پروژههای مبتنی بر دات نت 6، ساده سازی تعاریف فضاهای نام است. برای مثال یک کنترلر، به این صورت تعریف شدهاست:
که به آن «File-Scoped Namespaces» هم گفته میشود.
بررسی مفهوم «File-Scoped Namespaces»
یکی از اهداف مهم C# 10.0، کاهش نویز موجود در فایلهای cs. است. اگر قرار است صدها بار در فایلهای مختلف برنامه، using System نوشته شود، چرا یکبار آنرا به صورت عمومی تعریف نکنیم و یا اگر در 99 درصد موارد، توسعه دهندهها به ازای یک فایل، تنها یک فضای نام را تعریف میکنند، چرا باید یک فضای اضافی خالی، برای تعریف آن اختصاص داده شود و تمام فایلها به همراه یک «tab فاصلهی» اضافی مختص به این فضای نام باشند؟
تعریف فعلی فضاهای نام در #C به صورت زیر است:
در این حالت هر شیءای که داخل {} این فضای نام قرار گیرد، متعلق به آن است.
در C# 10.0، میتوان این تعریف را ساده کرد؛ از آنجائیکه به ندرت چند فضای نام در یک تک فایل تعریف میشوند، میتوان تعریف فضای نام را در یک سطر، در ابتدای فایل ذکر کرد، تا به صورت خودکار به کل فایل و اشیاء موجود در آن اعمال شود:
در این حالت، روش استفادهی از یک چنین اشیایی هیچ تغییری نخواهد کرد؛ فقط یک tab space و فاصله از کنار صفحه، صرفهجویی میشود!
محدویتهای «File-Scoped Namespaces»
- بدیهی است در این حالت دیگر نمیتوان چندین فضای نام را همانند قبل در یک فایل cs. تعریف کرد:
و البته این موردی است که جزو best practices توسعهی برنامههای #C به هیچ عنوان توصیه نمیشود.
- همچنین امکان ترکیب روش قبلی تعریف فضاهای نام، با روش جدید، در یک فایل وجود ندارد.
- به علاوه امکان تعریف فضاهای نام تو در تو که با روش قدیمی وجود دارد:
در این حالت جدید پشتیبانی نمیشود.
namespace mvc.Controllers; public class HomeController : Controller { }
بررسی مفهوم «File-Scoped Namespaces»
یکی از اهداف مهم C# 10.0، کاهش نویز موجود در فایلهای cs. است. اگر قرار است صدها بار در فایلهای مختلف برنامه، using System نوشته شود، چرا یکبار آنرا به صورت عمومی تعریف نکنیم و یا اگر در 99 درصد موارد، توسعه دهندهها به ازای یک فایل، تنها یک فضای نام را تعریف میکنند، چرا باید یک فضای اضافی خالی، برای تعریف آن اختصاص داده شود و تمام فایلها به همراه یک «tab فاصلهی» اضافی مختص به این فضای نام باشند؟
تعریف فعلی فضاهای نام در #C به صورت زیر است:
namespace MyNamespace { public class MyClass { public void MyMethod() { //...Method implementation } } }
در C# 10.0، میتوان این تعریف را ساده کرد؛ از آنجائیکه به ندرت چند فضای نام در یک تک فایل تعریف میشوند، میتوان تعریف فضای نام را در یک سطر، در ابتدای فایل ذکر کرد، تا به صورت خودکار به کل فایل و اشیاء موجود در آن اعمال شود:
namespace MyNamespace; public class MyClass { public void MyMethod() { //...Method implementation } }
محدویتهای «File-Scoped Namespaces»
- بدیهی است در این حالت دیگر نمیتوان چندین فضای نام را همانند قبل در یک فایل cs. تعریف کرد:
namespace Name1 { public class Class1 { } } namespace Name1.Name2 { public class Class2 { } }
- همچنین امکان ترکیب روش قبلی تعریف فضاهای نام، با روش جدید، در یک فایل وجود ندارد.
- به علاوه امکان تعریف فضاهای نام تو در تو که با روش قدیمی وجود دارد:
namespace Name1 { public class Class1 { } namespace Name1.Name2 { public class Class2 { } } }
اشتراکها
اینترنت چگونه کار میکند؟
Auto Render Mode، آخرین حالت رندری است که به Blazor 8x اضافه شدهاست. اگر از Blazor Server استفاده کنیم، به یک آغاز سریع در برنامه خواهیم رسید، به همراه مقداری تاخیر جزئی، برای به روز رسانی UI؛ از این جهت که تعاملات صورت گرفته باید از طریق اتصال وبسوکت SignalR به سرور ارسال شده و منتظر نتیجهی نهایی، برای اعمال آن به صفحه شد و یا باید به مقیاس پذیری این اتصالات همزمان با تعداد کاربران بالا هم اندیشید. اگر از Blazor WASM استفاده کنیم، آغاز آن، اندکی کند خواهد بود تا فایلهای فریمورک و برنامه، به درون مرورگر کاربر منتقل شوند. اما پس از آن همهچیز بسیار سریع است؛ از این جهت که تعاملات با DOM، توسط مرورگر و در همان سمت کاربر مدیریت میشود.
اما ... چقدر خوب میشد که امکان ترکیب هردوی اینها با هم در یک برنامه وجود میداشت؛ یعنی داشتن یک آغاز سریع، به همراه تعاملات سریع با DOM. به همین جهت Auto Render Mode به Blazor 8x اضافه شدهاست.
نحوهی عملکرد حالت رندر تعاملی خودکار در Blazor 8x
زمانیکه از قرار است از Auto Render Mode استفاده شود، یعنی در نهایت به سراغ حالت رندر وباسمبلی رفتن؛ اما به شرطیکه که فریمورک، مطمئن شود میتواند تمام فایلهای مرتبط را خیلی سریع و در کمتر از 100 میلیثانیه تامین کند که عموما یک چنین حالتی به معنای از پیش دریافت کردن این فایلها و کش شده بودن آنها در مرورگر است. اما اگر یک چنین تضمینی وجود نداشته باشد، از همان ابتدای کار تصمیم میگیرد که باید کامپوننت را از طریق نگارش Blazor Server آن ارائه دهد، تا آغاز سریعی را سبب شود. در این بین هم در پشت صحنه (یعنی زمانیکه کاربر مشغول به کار با نگارش Blazor Server کامپوننت است)، شروع به دریافت فایلهای مرتبط با نگارش وباسمبلی کامپوننت و برنامه میشود تا آنها را کش کرده و برای بار بعدی بارگذاری صفحه و نمایش اطلاعات آن، به سرعت از آنها استفاده کند.
یک چنین حالتی برای کاربران به این معنا است که به محض گشودن برنامه و صفحهای، قادر به استفادهی از آن هستند و برای بارهای بعدی استفاده، دیگر نیازی به اتصال دائم SignalR یک جزیرهی تعاملی Blazor Server نداشته و در نتیجه بار کمتری به سرور تحمیل خواهد شد (مقیاس پذیری بیشتر) و همچنین پردازش DOM بسیار سریعتری را نیز شاهد خواهند بود (کار با نگارش Blazor WASM درون مرورگر).
همانطور که در این تصویر هم مشخص است، برای بار اول نمایش یک چنین جزیرههایی، یک اتصال وبسوکت برقرار میشود که به معنای فعال شدن حالت جزیرهای Blazor Server است که در قسمت پنجم بررسی کردیم. در این بین فایلهای Blazor WASM این جزیره هم دریافت و کش میشوند که در کنسول توسعه دهندههای مرورگر، لاگ شدهاست. این اتصال وبسوکت، در بار اول نمایش این کامپوننت، بسته نخواهد شد؛ تا زمانیکه کاربر به صفحهای دیگر مراجعه کند. در دفعهی بعدی که درخواست نمایش این صفحه را داشته باشیم، چون اطلاعات نگارش وباسمبلی آن کش شدهاست، از همان ابتدای کار نگارش وب اسمبلی را بارگذاری و راهاندازی میکند.
تفاوت قالب پروژههای Auto Render Mode با سایر حالتهای رندر در Blazor 8x
برای ایجاد قالب ابتدایی پروژهی یک چنین حالت رندری، از دستور dotnet new blazor --interactivity Auto استفاده میشود که حالت تعاملی آن به Auto تنظیم شدهاست. در نگاه اول، Solution ایجاد شدهی آن، بسیار شبیه به Solution جزیرههای تعاملی Blazor WASM است که در قسمت هفتم به همراه یک مثال کامل بررسی کردیم؛ یعنی از دو پروژهی سمت سرور و سمت کلاینت تشکیل میشود و دارای این تفاوتها است:
در فایل Program.cs پروژهی سمت سرور آن، افزوده شدن هر دو حالت جزایر تعاملی Blazor Server و همچنین Blazor WASM را مشاهده میکنیم:
یک چنین قالبی میتواند تمام موارد زیر را با هم در یک Solution پشتیبانی کند:
الف) امکان تعریف صفحات فقط SSR در پروژهی سمت سرور
ب) امکان داشتن جزیرههای تعاملی فقط Blazor Server در پروژهی سمت سرور
ج) امکان داشتن جزیرههای تعاملی فقط Blazor Wasm در پروژهی سمت کلاینت
د) به همراه امکان تعریف جزیرهای تعاملی Auto Render Mode در پروژهی سمت کلاینت
یک نکته: در این تنظیمات، متد AddAdditionalAssemblies، امکان استفاده از کامپوننتهای قرار گرفتهی در سایر اسمبلیها و پروژهها را میسر میکند.
نحوهی تعریف کامپوننتهایی که قرار است توسط Auto Render Mode ارائه شوند
باتوجه به اینکه این نوع کامپوننتها در نهایت قرار است به صورت وباسمبلی رندر شوند، آنها را باید در پروژهی سمت کلاینت قرار داد و به نکات مرتبط با توسعهی آنها که در قسمت هفتم پرداختیم، توجه داشت.
همچنین مانند سایر حالتهای رندر، به دو طریق میتوان مشخص کرد که یک کامپوننت باید به چه صورتی رندر شود:
الف) استفاده از دایرکتیو حالت رندر با مقدار InteractiveAuto در ابتدای تعریف یک کامپوننت
ب) مشخص کردن حالت رندر، در زمان استفاده از المان کامپوننت
البته به شرطیکه using static زیر را به فایل Imports.razor_ پروژه اضافه کرد:
اما ... چقدر خوب میشد که امکان ترکیب هردوی اینها با هم در یک برنامه وجود میداشت؛ یعنی داشتن یک آغاز سریع، به همراه تعاملات سریع با DOM. به همین جهت Auto Render Mode به Blazor 8x اضافه شدهاست.
نحوهی عملکرد حالت رندر تعاملی خودکار در Blazor 8x
زمانیکه از قرار است از Auto Render Mode استفاده شود، یعنی در نهایت به سراغ حالت رندر وباسمبلی رفتن؛ اما به شرطیکه که فریمورک، مطمئن شود میتواند تمام فایلهای مرتبط را خیلی سریع و در کمتر از 100 میلیثانیه تامین کند که عموما یک چنین حالتی به معنای از پیش دریافت کردن این فایلها و کش شده بودن آنها در مرورگر است. اما اگر یک چنین تضمینی وجود نداشته باشد، از همان ابتدای کار تصمیم میگیرد که باید کامپوننت را از طریق نگارش Blazor Server آن ارائه دهد، تا آغاز سریعی را سبب شود. در این بین هم در پشت صحنه (یعنی زمانیکه کاربر مشغول به کار با نگارش Blazor Server کامپوننت است)، شروع به دریافت فایلهای مرتبط با نگارش وباسمبلی کامپوننت و برنامه میشود تا آنها را کش کرده و برای بار بعدی بارگذاری صفحه و نمایش اطلاعات آن، به سرعت از آنها استفاده کند.
یک چنین حالتی برای کاربران به این معنا است که به محض گشودن برنامه و صفحهای، قادر به استفادهی از آن هستند و برای بارهای بعدی استفاده، دیگر نیازی به اتصال دائم SignalR یک جزیرهی تعاملی Blazor Server نداشته و در نتیجه بار کمتری به سرور تحمیل خواهد شد (مقیاس پذیری بیشتر) و همچنین پردازش DOM بسیار سریعتری را نیز شاهد خواهند بود (کار با نگارش Blazor WASM درون مرورگر).
همانطور که در این تصویر هم مشخص است، برای بار اول نمایش یک چنین جزیرههایی، یک اتصال وبسوکت برقرار میشود که به معنای فعال شدن حالت جزیرهای Blazor Server است که در قسمت پنجم بررسی کردیم. در این بین فایلهای Blazor WASM این جزیره هم دریافت و کش میشوند که در کنسول توسعه دهندههای مرورگر، لاگ شدهاست. این اتصال وبسوکت، در بار اول نمایش این کامپوننت، بسته نخواهد شد؛ تا زمانیکه کاربر به صفحهای دیگر مراجعه کند. در دفعهی بعدی که درخواست نمایش این صفحه را داشته باشیم، چون اطلاعات نگارش وباسمبلی آن کش شدهاست، از همان ابتدای کار نگارش وب اسمبلی را بارگذاری و راهاندازی میکند.
تفاوت قالب پروژههای Auto Render Mode با سایر حالتهای رندر در Blazor 8x
برای ایجاد قالب ابتدایی پروژهی یک چنین حالت رندری، از دستور dotnet new blazor --interactivity Auto استفاده میشود که حالت تعاملی آن به Auto تنظیم شدهاست. در نگاه اول، Solution ایجاد شدهی آن، بسیار شبیه به Solution جزیرههای تعاملی Blazor WASM است که در قسمت هفتم به همراه یک مثال کامل بررسی کردیم؛ یعنی از دو پروژهی سمت سرور و سمت کلاینت تشکیل میشود و دارای این تفاوتها است:
در فایل Program.cs پروژهی سمت سرور آن، افزوده شدن هر دو حالت جزایر تعاملی Blazor Server و همچنین Blazor WASM را مشاهده میکنیم:
// ... builder.Services.AddRazorComponents() .AddInteractiveServerComponents() .AddInteractiveWebAssemblyComponents(); // ... app.MapRazorComponents<App>() .AddInteractiveServerRenderMode() .AddInteractiveWebAssemblyRenderMode() .AddAdditionalAssemblies(typeof(Counter).Assembly);
الف) امکان تعریف صفحات فقط SSR در پروژهی سمت سرور
ب) امکان داشتن جزیرههای تعاملی فقط Blazor Server در پروژهی سمت سرور
ج) امکان داشتن جزیرههای تعاملی فقط Blazor Wasm در پروژهی سمت کلاینت
د) به همراه امکان تعریف جزیرهای تعاملی Auto Render Mode در پروژهی سمت کلاینت
یک نکته: در این تنظیمات، متد AddAdditionalAssemblies، امکان استفاده از کامپوننتهای قرار گرفتهی در سایر اسمبلیها و پروژهها را میسر میکند.
نحوهی تعریف کامپوننتهایی که قرار است توسط Auto Render Mode ارائه شوند
باتوجه به اینکه این نوع کامپوننتها در نهایت قرار است به صورت وباسمبلی رندر شوند، آنها را باید در پروژهی سمت کلاینت قرار داد و به نکات مرتبط با توسعهی آنها که در قسمت هفتم پرداختیم، توجه داشت.
همچنین مانند سایر حالتهای رندر، به دو طریق میتوان مشخص کرد که یک کامپوننت باید به چه صورتی رندر شود:
الف) استفاده از دایرکتیو حالت رندر با مقدار InteractiveAuto در ابتدای تعریف یک کامپوننت
@rendermode InteractiveAuto
<Banner @rendermode="@InteractiveAuto" Text="Hello"/>
@using static Microsoft.AspNetCore.Components.Web.RenderMode
یکی از مواردی که با Angular CLI 6.0 به شدت ساده شدهاست، ایجاد پروژههای «کتابخانه» Angular است. برای مثال شاید در حین استفادهی از بعضی از کتابخانهی ثالث تهیه شدهی برای Angular با خطای ذیل مواجه شده باشید:
این خطا زمانی رخ میدهد که تهیه کنندهی کتابخانه، فرمت بستههای Angular را رعایت نکرده باشد و ... رعایت کردن آن نیز کار بسیار مشکلی است. نگارش 6 در پشت صحنه، پروژهی موفق ng-packagr را به مجموعهی CLI اضافه کردهاست و از این پس توسط خود CLI میتوان کتابخانههای استاندارد Angular را تولید کرد. این مورد، مزیت استاندارد سازی کتابخانههای npm حاصل را نیز به همراه دارد. مشکلی که گاهی از اوقات به علت عدم رعایت این ساختار با بستههای فعلی npm مخصوص Angular وجود دارند؛ مانند خطایی که عنوان شد. برای مثال بدون استفادهی از این ابزار، نیاز است مستندات چند صفحهای ساخت کتابخانههای Angular را سطر به سطر پیاده سازی کنید که توسط CLI 6.0 به صورت خودکار ایجاد و مدیریت میشود.
مراحل ایجاد یک پروژهی «کتابخانه» توسط Angular CLI 6.0
مرحلهی اول ایجاد یک پروژهی کتابخانه، مانند قبل، توسط دستور ng new و ایجاد یک پروژهی دلخواه جدید است:
به همراه Angular CLI 6.0، فرمت تنظیمات آن نیز تغییر کردهاست و مفهوم workspace به آن اضافه شدهاست که در آن میتوان چندین پروژه را تعریف کرد.
پس از ایجاد پروژهی my-lib-test توسط دستور فوق و وارد شدن به پوشهی اصلی آن توسط خط فرمان، میتوان با اجرای دستور زیر، پروژههای دیگری را به پروژهی جاری افزود:
اما اگر در اینجا بجای ذکر application، از نام library استفاده کنیم، یک کتابخانه را بجای یک برنامه، به workspace جاری اضافه میکند:
پس از اجرای این دستور اگر به فایل angular.json دقت کنیم، این پروژه در ذیل projects اضافه شدهاست:
همچنین یک پوشهی جدید به نام projects نیز ایجاد شده و پروژهی my-lib داخل آن قرار گرفتهاست.
فایل جدید public_api.ts
پس از ایجاد کتابخانهی جدید «my-lib»، فایل جدیدی به نام projects\my-lib\src\public_api.ts نیز به آن اضافه شدهاست:
با این محتوا:
هر خروجی که در اینجا ذکر شود توسط استفاده کنندگان از این کتابخانه قابل دسترسی خواهد بود. برای مثال دستور «ng generate library my-lib» مطابق تصویر فوق، یک سرویس جدید را به نام my-lib.service، یک کامپوننت جدید را به نام my-lib.component و یک ماژول جدید را به نام my-lib.module به صورت پیشفرض ایجاد کرده و درون پوشهی lib قرار دادهاست. اکنون آنها را توسط فایل public_api.ts، به نحوی که مشاهده میکنید در معرض دید استفاده کنندگان قرار میدهد.
برای مثال اگر فایل جدید projects\my-lib\src\lib\my-lib.models.ts را به این کتابخانه اضافه کنیم که شامل تعدادی مدل و اینترفیس قابل دسترسی توسط استفاده کنندگان باشد، باید یک سطر زیر را به انتهای فایل public_api.ts اضافه کنیم:
این پروژهی کتابخانه حتی به همراه فایلهای package.json, tsconfig.json, tslint.json مخصوص به خود نیز میباشد تا بتوان آنها را صرفا جهت این پروژه سفارشی سازی کرد.
ساختار my-lib.service پیشفرض یک پروژهی کتابخانه
اگر به فایل projects\my-lib\src\lib\my-lib.service.ts دقت کنیم:
تمام قسمتهای آن مانند قبل است، منهای 'providedIn: 'root آن. این مورد تنظیم جدیدی است که در پروژههای Angular 6 قابل استفادهاست. هدف از آن، ارائهی یک سرویس، بدون نیاز به ثبت صریح آن در قسمت providers یک NgModule است.
شاید بپرسید چرا؟ هدف اصلی از آن، بهبود فرآیند tree-shaking یا حذف کدهای مرده و استفاده نشدهاست. ممکن است سرویسی را تعریف کنید، اما در برنامه استفاده نشود. این حالت خصوصا در پروژههای کتابخانههای ثالث ممکن است زیاد رخ دهد. به همین جهت با ارائهی این قابلیت، امکان حذف سادهتر سرویسهایی که در برنامه استفاده نشدهاند از خروجی نهایی کامپایل شده، وجود خواهد داشت.
چگونه به پروژهی کتابخانهی جدید، یک کامپوننت جدید را اضافه کنیم؟
تمام دستورات Angular CLI، در اینجا نیز کار میکنند. تنها تفاوت آنها، ذکر صریح نام پروژهی مورد استفاده است:
دستور فوق کامپوننت جدید show-data را به پروژهی my-lib اضافه خواهد کرد؛ به همراه به روز رسانی خودکار فایل projects/my-lib/src/lib/my-lib.module.ts این پروژه، جهت ثبت کامپوننت اضافه شده.
البته در اینجا باید فایل my-lib.module.ts را اندکی ویرایش کرد و ShowDataComponent را به قسمت exports نیز افزود:
به صورت پیشفرض، کامپوننت جدید را در قسمت declarations معرفی میکند. یک چنین کامپوننتی فقط داخل همان lib قابل استفادهاست. اگر قرار است خارج از این lib نیز به آن دسترسی داشته باشیم، باید آنرا در قسمت exports نیز قید کنیم.
همچنین قسمت imports آن نیز به صورت پیشفرض خالی است. اگر نیاز است با ngIf کار کنید، باید CommonModule را در اینجا قید کنید و اگر نیاز است تبادلات HTTP وجود داشته باشد، ذکر HttpClientModule نیز ضروری است.
مرحلهی ساخت پروژه
پیش از استفادهی از این پروژهی کتابخانه، باید آنرا build کرد:
در اینجا نیز دستور ng build مانند قبل است، با این تفاوت که نام پروژهی کتابخانه نیز در اینجا ذکر شدهاست.
پس از اجرای این دستور، خروجی ذیل مشاهده میشود:
همانطور که ملاحظه میکنید، پس از طی مراحل خاص تولید یک کتابخانه، خروجی نهایی آنرا در پوشهی dist\my-lib قرار دادهاست.
استفادهی از کتابخانهی تولید شده
پس از پایان موفقیت آمیز مرحلهی Build، اکنون نوبت به استفادهی از این کتابخانه است. استفادهی از آن نیز همانند تمام کتابخانهها و وابستگیهای ثالثی است که تا پیش از این از آنها استفاده کردهایم. برای مثال ماژول آنرا در قسمت imports مربوط به NgModule کلاس AppModule معرفی میکنیم. برای این منظور به فایل src\app\app.module.ts مراجعه کرده و MyLibModule را به نحو ذیل اضافه میکنیم:
نکتهی مهمی که در اینجا باید به آن دقت داشت این است که هرچند در این پروژه، MyLibModule داخل پوشهی projects\my-lib\src\lib قرار دارد، اما نباید مسیر نسبی آنرا در اینجا ذکر کرد و باید صرفا نام پوشهی my-lib واقع در پوشهی node_modules را در اینجا در حین مسیر دهی import آن معرفی کرد (همانند تمام وابستگیهای ثالث دیگر).
اما سؤال اینجا است که آیا این پوشه پس از build، داخل پوشهی node_modules نیز کپی شدهاست؟ پاسخ آن خیر است و برای مدیریت خودکار آن، به صورت زیر عمل شدهاست:
اگر به فایل tsconfig.json اصلی و واقع در ریشهی workspace دقت کنید، پس از اجرای دستور «ng generate library my-lib»، قسمت paths آن نیز به صورت خودکار ویرایش شدهاست:
معنای آن این است که هرگاه import ایی در برنامه به my-lib اشاره کند، کامپایلر TypeScript میداند که باید آنرا از پوشهی dist/my-lib دریافت و پردازش کند. به همین جهت در اینجا دیگر نیازی به کپی دستی این پوشه، به پوشهی node_modules وجود ندارد.
به این ترتیب مسیر این import، چه در این پروژهی محلی و چه برای کسانیکه پوشهی dist/my-lib را به صورت یک بستهی npm جدید دریافت کردهاند، یکی خواهد بود.
در ادامه اگر به فایل app.component.html مراجعه کرده و selector کامپوننت show-data را به آن اضافه کنیم:
میتوان محتویات این کامپوننت دریافت شدهی از کتابخانه را مشاهده کرد.
توزیع کتابخانهی ایجاد شده برای عموم
برای اینکه این کتابخانهی تولیدی را در اختیار عموم، در سایت npm قرار دهیم، ابتدا باید کتابخانه را در حالت production build تولید و سپس آنرا publish کرد:
سطر اول، کتابخانهی my-lib را در حالت production تواید میکند. سپس به پوشهی فایلهای نهایی تولید شده وارد میشویم و دستور npm publish را صادر میکنیم.
البته دستور آخر نیاز به ایجاد یک اکانت در سایت npm و وارد شدن به آنرا دارد. جزئیات بیشتر آن در اینجا.
Please open an issue in the library repository to alert its author and ask them to package the library using the Angular Package Format (https://goo.gl/jB3GVv).
مراحل ایجاد یک پروژهی «کتابخانه» توسط Angular CLI 6.0
مرحلهی اول ایجاد یک پروژهی کتابخانه، مانند قبل، توسط دستور ng new و ایجاد یک پروژهی دلخواه جدید است:
ng new my-lib-test
پس از ایجاد پروژهی my-lib-test توسط دستور فوق و وارد شدن به پوشهی اصلی آن توسط خط فرمان، میتوان با اجرای دستور زیر، پروژههای دیگری را به پروژهی جاری افزود:
ng generate application my-app-name
ng generate library my-lib
همچنین یک پوشهی جدید به نام projects نیز ایجاد شده و پروژهی my-lib داخل آن قرار گرفتهاست.
فایل جدید public_api.ts
پس از ایجاد کتابخانهی جدید «my-lib»، فایل جدیدی به نام projects\my-lib\src\public_api.ts نیز به آن اضافه شدهاست:
با این محتوا:
/* * Public API Surface of my-lib */ export * from './lib/my-lib.service'; export * from './lib/my-lib.component'; export * from './lib/my-lib.module';
برای مثال اگر فایل جدید projects\my-lib\src\lib\my-lib.models.ts را به این کتابخانه اضافه کنیم که شامل تعدادی مدل و اینترفیس قابل دسترسی توسط استفاده کنندگان باشد، باید یک سطر زیر را به انتهای فایل public_api.ts اضافه کنیم:
export * from './lib/my-lib.models';
این پروژهی کتابخانه حتی به همراه فایلهای package.json, tsconfig.json, tslint.json مخصوص به خود نیز میباشد تا بتوان آنها را صرفا جهت این پروژه سفارشی سازی کرد.
ساختار my-lib.service پیشفرض یک پروژهی کتابخانه
اگر به فایل projects\my-lib\src\lib\my-lib.service.ts دقت کنیم:
import { Injectable } from '@angular/core'; @Injectable({ providedIn: 'root' }) export class MyLibService { constructor() { } }
شاید بپرسید چرا؟ هدف اصلی از آن، بهبود فرآیند tree-shaking یا حذف کدهای مرده و استفاده نشدهاست. ممکن است سرویسی را تعریف کنید، اما در برنامه استفاده نشود. این حالت خصوصا در پروژههای کتابخانههای ثالث ممکن است زیاد رخ دهد. به همین جهت با ارائهی این قابلیت، امکان حذف سادهتر سرویسهایی که در برنامه استفاده نشدهاند از خروجی نهایی کامپایل شده، وجود خواهد داشت.
چگونه به پروژهی کتابخانهی جدید، یک کامپوننت جدید را اضافه کنیم؟
تمام دستورات Angular CLI، در اینجا نیز کار میکنند. تنها تفاوت آنها، ذکر صریح نام پروژهی مورد استفاده است:
ng generate component show-data --project=my-lib
البته در اینجا باید فایل my-lib.module.ts را اندکی ویرایش کرد و ShowDataComponent را به قسمت exports نیز افزود:
@NgModule({ imports: [ CommonModule, HttpClientModule ], declarations: [MyLibComponent, ShowDataComponent], exports: [MyLibComponent, ShowDataComponent] }) export class MyLibModule { }
همچنین قسمت imports آن نیز به صورت پیشفرض خالی است. اگر نیاز است با ngIf کار کنید، باید CommonModule را در اینجا قید کنید و اگر نیاز است تبادلات HTTP وجود داشته باشد، ذکر HttpClientModule نیز ضروری است.
مرحلهی ساخت پروژه
پیش از استفادهی از این پروژهی کتابخانه، باید آنرا build کرد:
ng build my-lib
پس از اجرای این دستور، خروجی ذیل مشاهده میشود:
Building Angular Package Building entry point 'my-lib' Rendering Stylesheets Rendering Templates Compiling TypeScript sources through ngc Downleveling ESM2015 sources through tsc Bundling to FESM2015 Bundling to FESM5 Bundling to UMD Minifying UMD bundle Remap source maps Relocating source maps Copying declaration files Writing package metadata Removing scripts section in package.json as it's considered a potential security vulnerability. Built my-lib Built Angular Package! - from: D:\my-lib-test\projects\my-lib - to: D:\my-lib-test\dist\my-lib
استفادهی از کتابخانهی تولید شده
پس از پایان موفقیت آمیز مرحلهی Build، اکنون نوبت به استفادهی از این کتابخانه است. استفادهی از آن نیز همانند تمام کتابخانهها و وابستگیهای ثالثی است که تا پیش از این از آنها استفاده کردهایم. برای مثال ماژول آنرا در قسمت imports مربوط به NgModule کلاس AppModule معرفی میکنیم. برای این منظور به فایل src\app\app.module.ts مراجعه کرده و MyLibModule را به نحو ذیل اضافه میکنیم:
import { MyLibModule } from "my-lib"; @NgModule({ imports: [ BrowserModule, MyLibModule ] }) export class AppModule { }
اما سؤال اینجا است که آیا این پوشه پس از build، داخل پوشهی node_modules نیز کپی شدهاست؟ پاسخ آن خیر است و برای مدیریت خودکار آن، به صورت زیر عمل شدهاست:
اگر به فایل tsconfig.json اصلی و واقع در ریشهی workspace دقت کنید، پس از اجرای دستور «ng generate library my-lib»، قسمت paths آن نیز به صورت خودکار ویرایش شدهاست:
{ "compilerOptions": { "paths": { "my-lib": [ "dist/my-lib" ] } } }
برای نمونه اگر شارهگر ماوس را بر روی my-lib قرار دهید، به درستی مسیر خوانده شدن آن، تشخیص داده میشود.
به این ترتیب مسیر این import، چه در این پروژهی محلی و چه برای کسانیکه پوشهی dist/my-lib را به صورت یک بستهی npm جدید دریافت کردهاند، یکی خواهد بود.
در ادامه اگر به فایل app.component.html مراجعه کرده و selector کامپوننت show-data را به آن اضافه کنیم:
<lib-show-data></lib-show-data>
توزیع کتابخانهی ایجاد شده برای عموم
برای اینکه این کتابخانهی تولیدی را در اختیار عموم، در سایت npm قرار دهیم، ابتدا باید کتابخانه را در حالت production build تولید و سپس آنرا publish کرد:
ng build my-lib --prod cd dist/my-lib npm publish
البته دستور آخر نیاز به ایجاد یک اکانت در سایت npm و وارد شدن به آنرا دارد. جزئیات بیشتر آن در اینجا.