"CoffeeScript is to Ruby as TypeScript is to Java/C#/C++." - Luke Hoban
A fantastic writeup (from a TC39 member, no less) of how Bloomberg (the financial media company) adopted TypeScript and now has 2,000 full-time JavaScript engineers. Curiously we also learn that Bloomberg also have their own JavaScript runtime built around the V8 engine.
Modern Microsoft is much more than Windows, and to reach their full potential developers must be able to reach users on the many platforms they use. To facilitate this, Microsoft created Universal Windows Platform (UWP) to make development across multiple platforms simultaneously an achievable goal. In UWP Succinctly, the first part of a series, author Matteo Pagani guides readers towards developing their own UWP applications.
Table of Contents
- Introduction
- The Essential Concepts: Visual Studio, XAML, and C#
- Creating the User Interface: The Controls
This post provides a simple IValueConverter implementation that makes use of the framework type converters in order to convert between a large range of source / target types. This converter can be used both within bindings and in code-behind to give more concise property setters.
تا پیش از ارائه‌ی کامپایلر TypeScript 2.0، مقادیر null و undefined، به هر نوعی قابل انتساب بودند و امکان تفکیک آن‌ها وجود نداشت که این مورد می‌تواند منشاء بروز بسیاری از خطاهای در زمان اجرا شود.
برای نمونه در اینجا یک متغیر رشته‌ای و همچنین عددی تعریف شده‌اند که انتساب null و یا undefined نیز به آن‌ها مجاز است. این مورد جهت نوع‌های ورودی و خروجی متدها، اشیاء و آرایه‌ها نیز میسر است.
نوع null در TypeScript
همانند JavaScript، نوع null تنها یک مقدار معتبر نال را می‌تواند داشته باشد و نمی‌توان برای مثال یک رشته را به آن انتساب داد. اما انتساب این مقدار به هر نوع متغیر دیگری، سبب پاک شدن مقدار آن خواهد شد. با فعالسازی strictNullChecks، این نوع را تنها به نوع‌های نال‌پذیر می‌توان انتساب داد.
نوع undefined در TypeScript
هر متغیری که مقداری به آن انتساب داده نشده باشد، با undefined مقدار دهی می‌شود. این مورد حتی جهت خروجی متدها نیز صادق است و اگر return ایی در آن‌ها فراموش شود، این خروجی نیز به undefined تفسیر می‌شود.
در اینجا نیز اگر نوع متغیری به undefined تنظیم شد، این متغیر تنها مقدار undefined را می‌تواند بپذیرد. تنها با خاموش کردن پرچم strictNullChecks می‌توان آنرا به اعداد، رشته‌ها و غیره نیز انتساب داد.
فعالسازی نوع‌های نال نپذیر در TypeScript
برای فعالسازی این قابلیت، نیاز است پرچم strictNullChecks را در فایل تنظیمات کامپایلر به true تنظیم کرد:
از این پس دیگر نمی‌توان null و undefined را به هر نوعی انتساب داد و این‌ها تنها به خودشان و یا نوع any، قابل انتساب هستند. برای مثال اکنون نوع number فقط یک عدد است و دیگر قابلیت پذیرش null و یا undefined را ندارد. البته در اینجا یک استثناء هم وجود دارد: undefined را می‌توان به نوع void نیز انتساب داد.
برای مثال اگر متدی، رشته‌ای را به عنوان پارامتر قبول کند، تا پیش از TypeScript 2.0 و فعالسازی strictNullChecks آن، مشخص نبود که رشته‌ی دریافتی از آن واقعا یک رشته‌است و یا شاید null. اما اکنون یک رشته، فقط یک رشته‌است و دیگر نال پذیر نیست.
به این ترتیب دیگر به خطاهای زمان اجرایی مانند خطاهای ذیل نخواهیم رسید:
این مورد برای آرایه‌ها نیز صادق است:
اگر strictNullChecks فعال شود، دیگر نمی‌توان به اعضای یک آرایه مقادیر null و یا undefined را نسبت داد.
ساده سازی تعریف بررسی‌های با پرچم strict، در TypeScript 2.3
تعداد گزینه‌های قابل تنظیم در فایل tsconfig روز به روز بیشتر می‌شوند. به همین جهت برای ساده سازی فعالسازی آن‌ها، از TypeScript 2.3 به بعد، پرچم strict نیز به این تنظیمات اضافه شده‌است. کار آن فعالسازی یکجای تمام بررسی‌های strict است؛ مانند noImplicitAny، strictNullChecks و غیره.
در این حالت اگر نیاز به لغو یکی از گزینه‌ها بود، می‌توان به صورت ذیل عمل کرد:
گزینه‌ی strict تمام بررسی‌های متداول را فعال می‌کند؛ اما ذکر و تنظیم صریح noImplicitThis به false، تنها این یک مورد را لغو خواهد کرد.
یک نکته: اجرای دستور tsc --init ، سبب تولید یک فایل tsconfig.json از پیش تنظیم شده، بر اساس آخرین قابلیت‌های کامپایلر TypeScript می‌شود.
اما ... اکنون چگونه یک نوع را نال‌پذیر کنیم؟
TypeScript به همراه دو نوع ویژه‌ی null و undefined نیز شده‌است که تنها دارای مقادیر null و undefined می‌توانند باشند. به این معنا که در حین تعریف نوع یک متغیر، می‌توان این دو را نیز ذکر کرد و دیگر تنها به عنوان دو مقدار مطرح نیستند. به این ترتیب می‌توان از آن‌ها یک union type را ایجاد کرد:
اکنون تنها در این حالت است که متغیر foo می‌تواند یک رشته و یا یک null را دریافت کند و یا اگر مثال ابتدای بحث را بخواهیم اصلاح کنیم، به نمونه‌ی ذیل خواهیم رسید:
یکی دیگر از مزایای این روش، وضوح بیشتر تعریف نوع متغیرها و به نوعی «خود مستند سازی» بهتر آن‌ها است. در این حالت یا به صورت صریح مشخص می‌کنیم که متدی فقط یک رشته را می‌پذیرد و یا با ذکر string | null، به استفاده کننده اعلام می‌کنیم که ارسال null نیز به آن پیش بینی شده‌است و به نتیجه‌ی نامشخصی منتهی نخواهد شد.
یک نکته:
تا پیش از این اگر متغیری را به این صورت تعریف می‌کردیم:
نوع آن any درنظر گرفته می‌شد. اما اکنون، نوع آن تنها null است و تنها مقداری را هم که می‌تواند بپذیرد نال خواهد بود.
بررسی انتساب، پیش از استفاده
با فعالسازی strictNullChecks، اکنون کامپایلر برای تمام نوع‌هایی که undefined نیستند، یک مقدار اولیه را پیش از استفاده‌ی از آن‌ها درخواست می‌کند:
در اینجا چون x از نوع عددی است، به علت عدم مقدار دهی اولیه، قابلیت استفاده‌ی از آن وجود ندارد و کامپایلر خطای ذیل را اعلام می‌کند:
اما در حالت ذیل، عدد z می‌تواند عدد و یا undefined باشد؛ به همین جهت کامپایلر با استفاده‌ی از آن مشکلی نخواهد داشت:
یک نکته: خواص و پارامترهای اختیاری، به صورت خودکار دارای نوع undefined نیز هستند. برای مثال امضای متد ذیل:
با متد زیر یکی است:
اجبار به بررسی نال نبودن مقادیر، پیش از استفاده‌ی از آن‌ها در متدهای نال نپذیر
اگر پارامتر متدی یا خاصیت شیءایی نال پذیر نباشند، با ارسال مقدار نوعی به آن‌ها که می‌تواند null و یا undefined را بپذیرد، یک خطای زمان کامپایل صادر خواهد شد. در اینجا محافظ‌های نوع‌ها توسعه یافته‌اند تا اگر بررسی نال یا undefined بودن مقداری انجام شد، مشکلی در جهت استفاده‌ی از آن‌ها نباشد:
در این مثال، متد f فقط یک عدد را می‌پذیرد (و نه نال و یا undefined). اما در حین کاربرد آن در متد testTypeGuards، مقدار متغیر x می‌تواند یک عدد، نال و یا undefined باشد. چون پیش از اولین استفاده‌ی از متد f در اینجا، بررسی دارای مقدار بودن این متغیر صورت گرفته‌است، فراخوانی صورت گرفته، مجاز است. اما در قسمت else این شرط، کامپایلر خطای ذیل را صادر می‌کند:
امکان این بررسی در مورد عبارات شرطی نیز صادق است:
توسعه‌ی محافظ‌های نوع‌ها جهت کار با نوع‌های نال نپذیر
در مثال ذیل، خروجی متد isNumber دارای امضایی به همراه is است:
به یک چنین متدهایی type guard گفته می‌شود که امکان بررسی یک نوع را میسر می‌کنند. از این امکان می‌توان جهت بررسی بهتر پارامترها و یا خواص اختیاری استفاده کرد:
یک چنین بررسی، بهتر است از بررسی ذیل:
از این جهت که عبارت شرطی بررسی شده، مقدار صفر را نیز به صورت undefined بازگشت خواهد داد (if(0) به false تعبیر می‌شود و قسمت else این شرط فراخوانی خواهد شد).
همچنین امضای متد نیز به number | undefined تغییر یافته‌است. در غیر اینصورت، خطای زمان کامپایل Type undefined is not assignable to type number صادر خواهد شد.
در حین استفاده‌ی از یک چنین متدی، دیگر نمی‌توان به خروجی آن به صورت ذیل دسترسی یافت:
چون مقدار usedMb می‌تواند undefined باشد، باید ابتدا آنرا بررسی کرد:
لغو بررسی strictNullChecks به صورت موقت
با استفاده از اپراتور ! می‌توان به کامپایلر اطمینان داد که این متغیر یا خاصیت، دارای مقدار نال نیست و نخواهد بود:
در این اینترفیس، خاصیت age به صورت اختیاری تعریف شده‌است. برای نمایش مقدار age با فعال بودن strictNullChecks، یا باید ابتدا null نبودن آنرا به صورت صریحی بررسی کرد:
در غیراینصورت قطعه کد ذیل با خطای 'Object is possibly 'undefined کامپایل نخواهد شد:
و یا می‌توان توسط اپراتور ! این بررسی را به صورت موقت خاموش کرد:
البته استفاده‌ی از این اپراتور توسط tslint توصیه نمی‌شود:
چون بهتر است به کامپایلر عنوان نکنیم «قسم می‌خورم که این مقدار نال نیست»!
یک نکته‌ی تکمیلی
پس از آزمایش موفقیت آمیز نوع‌های نال نپذیر در TypeScript، مایکروسافت قصد دارد این ویژگی را به C# 8.0 نیز در مورد نوع‌های ارجاعی که می‌توانند نال پذیر باشند، اضافه کند (امکان داشتن نوع‌های ارجاعی نال‌نپذیر).
let name: string; name = "Vahid"; // OK name = null; // OK name = undefined; // OK
let age: number; age = 24; // OK age = null; // OK age = undefined; // OK
نوع null در TypeScript
همانند JavaScript، نوع null تنها یک مقدار معتبر نال را می‌تواند داشته باشد و نمی‌توان برای مثال یک رشته را به آن انتساب داد. اما انتساب این مقدار به هر نوع متغیر دیگری، سبب پاک شدن مقدار آن خواهد شد. با فعالسازی strictNullChecks، این نوع را تنها به نوع‌های نال‌پذیر می‌توان انتساب داد.
نوع undefined در TypeScript
هر متغیری که مقداری به آن انتساب داده نشده باشد، با undefined مقدار دهی می‌شود. این مورد حتی جهت خروجی متدها نیز صادق است و اگر return ایی در آن‌ها فراموش شود، این خروجی نیز به undefined تفسیر می‌شود.
در اینجا نیز اگر نوع متغیری به undefined تنظیم شد، این متغیر تنها مقدار undefined را می‌تواند بپذیرد. تنها با خاموش کردن پرچم strictNullChecks می‌توان آنرا به اعداد، رشته‌ها و غیره نیز انتساب داد.
فعالسازی نوع‌های نال نپذیر در TypeScript
برای فعالسازی این قابلیت، نیاز است پرچم strictNullChecks را در فایل تنظیمات کامپایلر به true تنظیم کرد:
{
"compilerOptions": {
"strictNullChecks": true
}
} برای مثال اگر متدی، رشته‌ای را به عنوان پارامتر قبول کند، تا پیش از TypeScript 2.0 و فعالسازی strictNullChecks آن، مشخص نبود که رشته‌ی دریافتی از آن واقعا یک رشته‌است و یا شاید null. اما اکنون یک رشته، فقط یک رشته‌است و دیگر نال پذیر نیست.
let foo: string = null; // Error! Type 'null' is not assignable to type 'string'.
Uncaught ReferenceError: foo is not defined Uncaught TypeError: window.foo is not a function
این مورد برای آرایه‌ها نیز صادق است:
// With strictNullChecks set to false let d: Array<number> = [null, undefined, 10, 15]; //OK let e: Array<string> = ["pie", null, ""]; //OK // With strictNullChecks set to true let d: Array<number> = [null, undefined, 10, 15]; // Error let e: Array<string> = ["pie", null, ""]; // Error
ساده سازی تعریف بررسی‌های با پرچم strict، در TypeScript 2.3
تعداد گزینه‌های قابل تنظیم در فایل tsconfig روز به روز بیشتر می‌شوند. به همین جهت برای ساده سازی فعالسازی آن‌ها، از TypeScript 2.3 به بعد، پرچم strict نیز به این تنظیمات اضافه شده‌است. کار آن فعالسازی یکجای تمام بررسی‌های strict است؛ مانند noImplicitAny، strictNullChecks و غیره.
{
"compilerOptions": {
"strict": true /* Enable all strict type-checking options. */
}
} {
"compilerOptions": {
"strict": true,
"noImplicitThis": false
}
} یک نکته: اجرای دستور tsc --init ، سبب تولید یک فایل tsconfig.json از پیش تنظیم شده، بر اساس آخرین قابلیت‌های کامپایلر TypeScript می‌شود.
اما ... اکنون چگونه یک نوع را نال‌پذیر کنیم؟
TypeScript به همراه دو نوع ویژه‌ی null و undefined نیز شده‌است که تنها دارای مقادیر null و undefined می‌توانند باشند. به این معنا که در حین تعریف نوع یک متغیر، می‌توان این دو را نیز ذکر کرد و دیگر تنها به عنوان دو مقدار مطرح نیستند. به این ترتیب می‌توان از آن‌ها یک union type را ایجاد کرد:
let foo: string | null = null; // Okay!
let name: string | null; name = "Vahid"; // OK name = null; // OK name = undefined; // Error
یک نکته:
تا پیش از این اگر متغیری را به این صورت تعریف می‌کردیم:
let z = null;
بررسی انتساب، پیش از استفاده
با فعالسازی strictNullChecks، اکنون کامپایلر برای تمام نوع‌هایی که undefined نیستند، یک مقدار اولیه را پیش از استفاده‌ی از آن‌ها درخواست می‌کند:
testAssignedBeforeUseChecking() {
let x: number;
console.log(x);
} [ts] Variable 'x' is used before being assigned.
اما در حالت ذیل، عدد z می‌تواند عدد و یا undefined باشد؛ به همین جهت کامپایلر با استفاده‌ی از آن مشکلی نخواهد داشت:
let z: number | undefined; console.log(z);
یک نکته: خواص و پارامترهای اختیاری، به صورت خودکار دارای نوع undefined نیز هستند. برای مثال امضای متد ذیل:
method1(x?: number) {
} method1(x?: number | undefined) {
} اجبار به بررسی نال نبودن مقادیر، پیش از استفاده‌ی از آن‌ها در متدهای نال نپذیر
اگر پارامتر متدی یا خاصیت شیءایی نال پذیر نباشند، با ارسال مقدار نوعی به آن‌ها که می‌تواند null و یا undefined را بپذیرد، یک خطای زمان کامپایل صادر خواهد شد. در اینجا محافظ‌های نوع‌ها توسعه یافته‌اند تا اگر بررسی نال یا undefined بودن مقداری انجام شد، مشکلی در جهت استفاده‌ی از آن‌ها نباشد:
f(x: number): string {
return x.toString();
}
testTypeGuards() {
let x: number | null | undefined;
if (x) {
this.f(x); // Ok, type of x is number here
} else {
this.f(x); // Error, type of x is number? here
}
} Argument of type 'number | null | undefined' is not assignable to parameter of type 'number'. Type 'undefined' is not assignable to type 'number'.
امکان این بررسی در مورد عبارات شرطی نیز صادق است:
getLength(s: string | null) {
return s ? s.length : 0;
} توسعه‌ی محافظ‌های نوع‌ها جهت کار با نوع‌های نال نپذیر
در مثال ذیل، خروجی متد isNumber دارای امضایی به همراه is است:
isNumber(n: any): n is number { // type guard
return typeof n === "number";
} usedMb(usedBytes?: number): number | undefined {
return this.isNumber(usedBytes) ? (usedBytes / (1024 * 1024)) : undefined;
} usedMb2(usedBytes?: number): number | undefined {
return usedBytes ? (usedBytes / (1024 * 1024)) : undefined;
} همچنین امضای متد نیز به number | undefined تغییر یافته‌است. در غیر اینصورت، خطای زمان کامپایل Type undefined is not assignable to type number صادر خواهد شد.
در حین استفاده‌ی از یک چنین متدی، دیگر نمی‌توان به خروجی آن به صورت ذیل دسترسی یافت:
formatUsedMb(): string {
//ERROR: TS2531: Object is possibly undefined
return this.usedMb(123).toFixed(0).toString();
} formatUsed(): string {
const usedMb = this.usedMb(123);
return usedMb ? usedMb.toFixed(0).toString() : "";
} لغو بررسی strictNullChecks به صورت موقت
با استفاده از اپراتور ! می‌توان به کامپایلر اطمینان داد که این متغیر یا خاصیت، دارای مقدار نال نیست و نخواهد بود:
export interface User {
name: string;
age?: number;
} printUserInfo(user: User) {
if (user.age != null) {
console.log(`${user.name}, ${user.age.toString()}`);
}
} printUserInfo(user: User) {
console.log(`${user.name}, ${user.age.toString()}`);
} و یا می‌توان توسط اپراتور ! این بررسی را به صورت موقت خاموش کرد:
printUserInfo(user: User) {
console.log(`${user.name}, ${user.age!.toString()}`);
} [tslint] Forbidden non null assertion (no-non-null-assertion)
یک نکته‌ی تکمیلی
پس از آزمایش موفقیت آمیز نوع‌های نال نپذیر در TypeScript، مایکروسافت قصد دارد این ویژگی را به C# 8.0 نیز در مورد نوع‌های ارجاعی که می‌توانند نال پذیر باشند، اضافه کند (امکان داشتن نوع‌های ارجاعی نال‌نپذیر).
Learn ASP.NET Core MVC (.NET 8) - The Complete Guide
In this Complete Guide course, we will learn MVC (Model-View-Controller) with .NET 8.
When we are working with .NET Core Web Applications, there are two common ways of building website.
1. MVC (Model-View-Controller) Web Application
2. Razor Pages Web Application
In this course we will learn the basics of .NET Core (.NET 8) and then learn basics of MVC and Razor Pages as we enhance MVC Application to a more complex final project!.
Topics Covered
- Fundamentals of .NET Core
- MVC Application
- Razor Pages
- Entity Framework Core
- Repository Pattern
- ViewBag
- ViewData
- TempData
- Taostr and sweet alerts in .NET Core
- Datatables in .NET Core
- Assignments
- Errors and how to solve them!
همانطور که در توضیح پروژه PersianDateTime آمده است، کلاس PersianDateTime جایگزینی است برای System.DateTime برای استفاده در پروژه‌هایی که احتیاج به تاریخ شمسی و ساعت رسمی ایران یا سایر کشورهای فارسی‌زبان، مستقل از Time Zone سیستم و در نظر گرفتن Daylight Saving Time، دارند. این کلاس شامل اکثر متدها، پراپرتی‌ها و عملگرهای متداول System.DateTime است.
دسترسی به تاریخ و ساعت فعلی :
PersianDateTime now = PersianDateTime.Now;
string persianDateTime = now.ToString(); // 1392/03/09 23:37:57
string persianDate = now.ToString(PersianDateTimeFormat.Date); // 1392/03/09
string persianFullDateTime = now.ToString("dddd d MMMM yyyy ساعت hh:mm:ss tt"); // پنج شنبه 9 خرداد 1392 ساعت 11:37:57 ب.ظ
TimeSpan persianTime = now.TimeOfDay; // 23:37:57.4641984نحوه محاسبه PersianDateTime.Now بر اساس فیلد استاتیک PersianDateTime.Mode است که مقدار پیش‌فرض آن PersianDateTimeMode.UtcOffset است.
PersianDateTime.Mode را می‌توان یکی از سه مقدار زیر قرار داد :
PersianDateTime.Mode را می‌توان یکی از سه مقدار زیر قرار داد :
- System : بر اساس تاریخ و زمان سیستم (Time Zone فعلی سیستم)
- PersianTimeZoneInfo : بر اساس Time Zone تعیین شده در فیلد استاتیک PersianDateTime.PersianTimeZoneInfo (مستقل از Time Zone سیستم)
- UtcOffset : بر اساس اختلاف ساعت با UTC، مشخص شده در فیلد استاتیک PersianDateTime.OffsetFromUtc (مستقل از Time Zone سیستم)
مقدار پیش‌فرض PersianDateTime.PersianTimeZoneInfo برابر Iran Standard Time Zone است. توجه داشته باشید که در این حالت از DaylightSavingTime تعیین شده در Time Zone استفاده خواهد شد که مثلا برای ایران با زمان واقعی آن اختلاف دارد و باید آنرا اصلاح کرد .
مقدار پیش‌فرض PersianDateTime.OffsetFromUtc برابر 3 ساعت و نیم است. در این حالت DaylightSavingTime با توجه به مقادیر سه فیلد استاتیک DaylightSavingTimeStart ،DaylightSavingTimeEnd و DaylightSavingTime تعیین می‌شود که به صورت پیش‌فرض برابر ساعت 24 اول فروردین، ساعت 24 سی‌ام شهریور و یک ساعت است.
تمام فیلدهای استاتیک ذکر شده به صورت public تعریف شده‌اند تا برنامه‌نویسان سایر کشورهای فارسی‌زبان بتوانند به دلخواه خود آنرا تغییر دهند.
نحوه کار با مقادیر رشته‌ای تاریخ شمسی هم اینگونه است :
PersianDateTime persianDate1 = PersianDateTime.Parse("1392/03/02");
PersianDateTime persianDate2 = PersianDateTime.Parse("1392/03/02", "23:32:56");چند سازنده هم وجود دارد برای کسانی که تاریخ را به صورت int و ساعت را int یا short (بدون ثانیه) ذخیره می‌کنند :
تبدیل تاریخ میلادی به شمسی :
تبدیل تاریخ شمسی به میلادی :
علاوه بر متد ToString معمولی، دو overload دیگر از این متد برای نمایش فرمت‌های مختلف PersianDateTime وجود دارد :
که اولی برای فرمت‌های معمول و دومی برای هر نوع فرمت دلخواه قابل استفاده است که چند نمونه آنرا در قسمت تعیین تاریخ و ساعت فعلی دیدید.
برخی از خصوصیات کلاس PersianDateTime :
همچنین تمام عملگرهای +، -، >، <، =>، =<، ==، و =! قابل استفاده هستند.
PersianDateTime persianDate1 = new PersianDateTime(13920310); PersianDateTime persianDate2 = new PersianDateTime(13920310, 233256); PersianDateTime persianDate3 = new PersianDateTime(13920310, (short)2332);
تبدیل تاریخ میلادی به شمسی :
DateTime miladiDate = new DateTime(2013, 5, 31); PersianDateTime persianDate = new PersianDateTime(miladiDate);
تبدیل تاریخ شمسی به میلادی :
PersianDateTime persianDate = PersianDateTime.Parse("1392/03/02");
DateTime miladiDate = persianDate.ToDateTime();علاوه بر متد ToString معمولی، دو overload دیگر از این متد برای نمایش فرمت‌های مختلف PersianDateTime وجود دارد :
public string ToString(PersianDateTimeFormat format); public string ToString(string format);
برخی از خصوصیات کلاس PersianDateTime :
- Year : سال
- Month : ماه
- Day : روز
- TimeOfDay : زمان سپری شده از ابتدای روز
- TimeOfWeek :زمان سپری شده از ابتدای هفته
- TimeOfMonth : زمان سپری شده از ابتدای ماه
- TimeOfYear : زمان سپری شده از ابتدای سال
- DaysInYear : تعداد روز سال
- DaysInMonth : تعداد روز ماه
- DayOfWeek : چندمین روز هفته
- DayOfYear : چندمین روز سال
- DayName : نام روز
- MonthName : نام ماه
- Date : تاریخ بدون زمان
- FirstDayOfWeek : اولین روز هفته
- LastDayOfWeek : آخرین روز هفته
- FirstDayOfMonth : اولین روز ماه
- LastDayOfMonth : آخرین روز ماه
- FirstDayOfYear : اولین روز سال
- LastDayOfYear : آخرین روز سال
برخی دیگر از متدهای کلاس PersianDateTime :
public PersianDateTime Add(TimeSpan value); public PersianDateTime AddDays(double value); public PersianDateTime AddMonths(int months); public PersianDateTime AddYears(int value); public PersianDateTime AddHours(double value); public PersianDateTime AddMinutes(double value); public PersianDateTime AddSeconds(double value);
نکته‌ای در مورد رفع مشکل «typings ERR! caused by connect ECONNREFUSED 10.10.34.36:443» پس از نصب TypeScript 2.0
پس از ارائه‌ی TypeScript 2.0، مایکروسافت کار مدیریت مخزن Typings را به عهده گرفته‌است و کار آن توزیع مخزن DefinitelyTyped به npm است و دیگر نیازی به استفاده از ابزارهای typings و یا tsd نیست. برای مثال اینبار بجای اینکه دستور ذیل را صادر کنیم:
که با خطای یاد شده متوقف می‌شود، می‌توان نوشت:
یعنی همه چیز مانند حالت نصب معمولی lodash است (npm install --save lodash)؛ اما یک types@ را در ابتدای آن بیشتر دارد. در این حالت فایل‌های d.ts. را در پوشه‌ی types@ ذیل node_modules خواهید یافت:
پس از ارائه‌ی TypeScript 2.0، مایکروسافت کار مدیریت مخزن Typings را به عهده گرفته‌است و کار آن توزیع مخزن DefinitelyTyped به npm است و دیگر نیازی به استفاده از ابزارهای typings و یا tsd نیست. برای مثال اینبار بجای اینکه دستور ذیل را صادر کنیم:
typings install lodash --ambient --save
npm install --save @types/lodash
Angular 16 with ASP NET Web API, EntityFrameworkCore and Bootstrap 5 - Full Course
Asp.net Tutorial for Beginners | Asp.net Full Course 2023|.NET for Beginners
