‫۱ سال و ۶ ماه قبل، دوشنبه ۱۰ بهمن ۱۴۰۱، ساعت ۱۷:۰۵
یک نکته‌ی تکمیلی: ساده شدن نحوه‌ی پردازش پیام‌های خالی رسیده در دات نت 7

تا پیش از دات نت 7، اگر درخواستی با یک بدنه‌ی خالی، یعنی با مشخصات Content-Length == 0 به سمت یک اکشن متد که آن‌را از طریق [FromBody] دریافت می‌کند، ارسال شود، با پیام خطای «A non-empty request body is required» خاتمه خواهد یافت. یک روش رفع سراسری آن، تنظیم زیر است:
var builder = WebApplication.CreateBuilder(args);

builder.Services.Configure<MvcOptions>(options =>
{
     options.AllowEmptyInputInBodyModelBinding = true;
});
و روش دیگر آن فقط برای یک اکشن متد خاص، به صورت زیر:
public IActionResult Post([FromBody(EmptyBodyBehavior = EmptyBodyBehavior.Allow)] MyBody? body)
{
   // body will be null if the request Content-Length == 0
}
در دات نت 7 این وضعیت ساده شده و بر اساس نال پذیری پارامتر دریافتی، در این مورد تصمیم گیری می‌شود:
public class ExampleController : Controller
{
    public IActionResult Post(MyBody? body) // Nullable
    {
        // body will be null if the request Content-Length == 0
    }
    
    public IActionResult Post(MyBody body) // Non-nullable
    {
        // Request will fail with a 400 and "A non-empty request body is required."
        // when Content-Length == 0
    }
}
یعنی اگر پارامتری نال‌پذیر بود، قابلیت پردازش یک بدنه‌ی درخواست خالی را به صورت نال دارد و برعکس.
‫۱ سال و ۷ ماه قبل، شنبه ۸ بهمن ۱۴۰۱، ساعت ۲۱:۴۳
یک نکته‌ی تکمیلی: اضافه شدن پشتیبانی از IResult به ASP.NET Core MVC 7x

خروجی‌های اکشن متدهای MVC به همراه IActionResult و <ActionResult<T هستند و در minimal APIs که نمونه‌ای از آن‌را در این مطلب مشاهده کردید، از نوع IResult و <IValueHttpResult<TValue و ... این دو نباید با هم مخلوط شوند!
برای مثال اگر در ASP.NET Core MVC 6x چنین اکشن متدی را تهیه کنیم:
[HttpGet(Name = "GetWeatherForecast")]
public IResult Get()
{
    return Results.Ok(new { Name = "My name" });
}
بدون مشکل کامپایل می‌شود و ... کار هم می‌کند؛ اما با خروجی زیر:
{
  "value": {
    "name" : "My name"
  },
  "statusCode" : 200,
  "contentType" : null
}
به این معنا که MVC 6x، شیء از نوع IResult را به صورت متداولی serialize کرده و خروجی فوق را ارائه داده‌است.
این مشکل یا محدودیت در MVC 7x برطرف شده‌است و اکنون خروجی زیر را تولید می‌کند:
{
   "name" : "My name"
}
البته باید بخاطر داشت که با استفاده از IResult مخصوص minimal APIs در MVC 7x، یکسری از ویژگی‌های MVC مانند content negotiation و output formatters دیگر کار نخواهند کرد؛ یعنی همیشه خروجی را به صورت JSON دریافت می‌کنیم.
‫۱ سال و ۷ ماه قبل، جمعه ۷ بهمن ۱۴۰۱، ساعت ۱۶:۰۲
یک نکته‌ی تکمیلی: آشنایی با مفهوم «C# Lowering»


در این مطلب، جهت بررسی درک علت یکسان بودن کارآیی حلقه‌هایی که از دیدگاه ما یکی نیستند، از قابلیت نمایش #Low-level C استفاده شد که نام اصلی آن «C# Lowering» است. Lowering به معنای ترجمه‌ی امکانات سطح بالای یک زبان به امکانات سطح پایین آن است. یعنی حاصل عملیات صورت گرفته نیز باز به همان زبان اولیه است که نمونه‌ی آن، تبدیل یک حلقه‌ی foreach سطح بالا به نمونه‌ی سطح پایینی است که توسط NET Runtime. بهتر درک شده و ساده‌تر اجرا می‌شود.

مزایای Lowering
- بهبود کارآیی برنامه: برای مثال یکی از کارهایی که در این بین عموما انجام می‌شود «Loop unrolling» است. یعنی یک حلقه به چندین حلقه‌ی کوچکتر تقسیم می‌شود تا سربار instructions کنترلی حلقه کاهش پیدا کنند.
- طراحی ساده‌تر زبان: اینکار به تیم طراحی زبان امکان نوشتن کدهای اضافه‌تری را می‌دهد که کار برنامه نویس‌ها را کمتر می‌کند. برای مثال یک record واقعا چیزی نیست بجز یک کلاس پیاده سازی کننده‌ی IEquatable به صورت خودکار و در پشت صحنه.

Lowering چه زمانی رخ می‌دهد؟
Lowering جزئی از عملیات صورت گرفته‌ی در حین کامپایل است. زمانیکه دستور dotnet build را صادر می‌کنیم، ابتدا semantics & syntax analysis صورت می‌گیرد تا اگر برای مثال خطای دستوری وجود دارد، مشخص شود. سپس کدها به CIL یا Common intermediate language تبدیل می‌شوند. در حین این قسمت است که عملیات lowering نیز انجام می‌شود.
اگر علاقمند به مشاهده‌ی این کد #C ثانویه‌ی تولید شده‌ی توسط کامپایلر هستید، می‌توان از ابزار https://sharplab.io نیز استفاده کرد. برای مثال در سمت چپ آن کدهای زیر را قرار دهید:
using System;
using System.Collections.Generic;

var list = new List<int> { 1, 2 };

foreach(var item in list)
    Console.Write(item);
سپس در سمت راست آن، گزینه‌ی #Results C را انتخاب کنید تا بتوانید نمونه‌ی معادل تبدیل شده‌ی توسط کامپایلر را مشاهده نمائید.
‫۱ سال و ۷ ماه قبل، سه‌شنبه ۴ بهمن ۱۴۰۱، ساعت ۱۵:۵۶
یک نکته‌ی تکمیلی: بررسی صحت ساختار JSON دریافتی توسط واژه‌ی کلیدی required در زمان اجرای برنامه

فرض کنید یک Dto را به صورت زیر تعریف کرده‌اید و توسط یک API قرار است این اطلاعات را دریافت کنید:
public class OldCarDto
{
    public string Brand { get; set; }
    public string Model { get; set; }
    public uint Horsepower { get; set; }
}
در این حالت هیچ کنترلی بر روی الزام به تکمیل تمام فیلدهای مورد نیاز وجود ندارد. برای مثال اگر JSON دریافتی به صورت زیر باشد:
var json = """
[
  {
    "brand": "Ferrari",
    "horsePower": 651
  },
  {
    "model": "F50",
    "horsePower": 512
  }
]
""";
که در لیست اشیاء آن، در یکی Model و در دیگری Brand وجود ندارد، عملیات Deserialize آن به صورت زیر، بدون هیچ خطایی به پایان می‌رسد:
var options = new JsonSerializerOptions
              {
                  PropertyNameCaseInsensitive = true,
                  PropertyNamingPolicy = JsonNamingPolicy.CamelCase
              };

var oldResults =  JsonSerializer.Deserialize<List<OldCarDto>>(json, options);
که البته در آن خواصی که وجود نداشته‌اند، با null مقدار دهی خواهند شد.

اگر اینبار تعریف Dto را به صورت زیر و بر اساس واژه‌ی کلیدی جدید required اصلاح کنیم:
public class NewCarDto
{
    public required string Brand { get; init; }
    public required string Model { get; init; }
    public required uint Horsepower { get; init; }
}
اینبار همان عملیات Deserialize زیر:
var newResults =  JsonSerializer.Deserialize<List<NewCarDto>>(json, options);
با این استثنای در زمان اجرا خاتمه خواهد یافت:
System.Text.Json.JsonException: JSON deserialization for type 'NewCarDto'
was missing required properties, including the following: model
که عنوان می‌کند به علت عدم قید خاصیت الزامی model، امکان deserialization وجود ندارد.
‫۱ سال و ۷ ماه قبل، دوشنبه ۳ بهمن ۱۴۰۱، ساعت ۱۴:۳۵
امکان دریافت تائید از کاربر، در حین ترک صفحه‌ی یک فرم ذخیره نشده در دات نت 7

Blazor در دات نت 7 به همراه امکانات مدیریت بهتر تغییرات آدرس صفحات است. برای مثال توسط آن می‌توان به کاربران در مورد کارهای ذخیره نشده، در صورت شروع به هدایت به صفحه‌ای دیگر، هشدار داد.
برای مدیریت تغییرات آدرس صفحات، می‌توان از سرویس NavigationManager و متد RegisterLocationChangingHandler آن به صورت زیر استفاده کرد:
var registration = NavigationManager.RegisterLocationChangingHandler(async cxt =>
{
    if (cxt.TargetLocation.EndsWith("counter"))
    {
        cxt.PreventNavigation();
    }
});
- در این مثال اگر آدرس درخواستی به counter ختم شود، با فراخوانی متد PreventNavigation، مانع آن خواهیم شد.
- خروجی این متد برای مثال registration در اینجا، از نوع IDisposable است و dispose آن سبب حذف Handler ثبت شده می‌شود.
- باید بخاطر داشت که امکانات فوق تنها آدرس‌های درون برنامه‌ای را مدیریت می‌کند. برای مدیریت هدایت به آدرس‌های خارجی باید از رخ‌داد beforeunload جاوا اسکریپت استفاده کرد.


ساده سازی کار با سرویس مدیریت تغییرات آدرس با کامپوننت جدید NavigationLock

نکات عنوان شده را توسط کامپوننت جدید NavigationLock نیز می‌توان به نحو ساده‌تری مدیریت کرد:
<NavigationLock OnBeforeInternalNavigation="ConfirmNavigation" ConfirmExternalNavigation />
در این کامپوننت، OnBeforeInternalNavigation یک callback است که کار ردیابی و مدیریت تغییرات آدرس‌های درون برنامه‌ای را انجام می‌دهد. اگر می‌خواهید هدایت به آدرس‌های خارجی را نیز کنترل کرده و همچنین علاقمند به پیاده سازی دستی رخ‌داد beforeunload جاوا اسکریپت نیستید، می‌توانید خاصیت ConfirmExternalNavigation را نیز قید کنید که با یک browser-specific prompt مدیریت می‌شود.
از این کامپوننت می‌توان جهت مدیریت یک فرم ذخیره نشده درصورت شروع به هدایت کاربر به آدرسی دیگر، به صورت زیر استفاده کرد:
<EditForm EditContext="editContext" OnValidSubmit="Submit">
    ...
</EditForm>
<NavigationLock OnBeforeInternalNavigation="ConfirmNavigation" ConfirmExternalNavigation />

    @code {
        private readonly EditContext editContext;
        ...

        // Called only for internal navigations.
        // External navigations will trigger a browser specific prompt.
        async Task ConfirmNavigation(LocationChangingContext context)
        {
            if (editContext.IsModified())
            {
                var isConfirmed = await JS.InvokeAsync<bool>("window.confirm", 
                   "Are you sure you want to leave this page?");
                
                if (!isConfirmed)
                {
                    context.PreventNavigation();
                }
            }
        }
    }
توضیحات:
- با استفاده از EditContext یک EditForm و متد IsModified آن می‌توان تشخیص داد که اطلاعات فرم جاری توسط کاربر تغییر کرده‌است و هنوز ذخیره شده یا نشده.
- در اینجا پیاده سازی OnBeforeInternalNavigation را توسط متد ConfirmNavigation مشاهده می‌کنید که در آن بررسی می‌شود آیا کاربر فرم را تغییر داده‌است یا خیر؟ اگر بله، متد confirm جاوا اسکریپت را جهت تائید ترک صفحه نمایش می‌دهد. اگر کاربر آن‌را تائید نکند، توسط متد PreventNavigation، مانع تغییر آدرس صفحه و از دست رفتن اطلاعات خواهد شد.
‫۱ سال و ۷ ماه قبل، یکشنبه ۲ بهمن ۱۴۰۱، ساعت ۱۴:۰۳
ساده شدن «روش تعریف data binding دو طرفه در کامپوننت‌ها» در دات نت 7

در نکته‌ی فوق، روش تعریف data binding دو طرفه را در کامپوننت‌ها بررسی کردیم. برای مثال اگر بخواهیم کامپوننت سفارشی ما دارای ویژگی bind-Value@ باشد، باید حداقل توسط دو پارامتر زیر پشتیبانی شود:
[Parameter] public string Value { set; get; }
[Parameter] public EventCallback<string> ValueChanged { get; set; }
که در اینجا باید قسمت setter مربوط به خاصیت Value را هم بازنویسی کنیم و توسط آن، با فراخوانی ValueChanged.InvokeAsync، به استفاده کننده اطلاع دهیم که مقدار Value تغییر کرده‌است. این قسمت بازنویسی در دات نت 7 به صورت زیر قابل حذف شدن است (نام فرضی کامپوننت زیر، MyInput است):
<input @bind:get="Value" @bind:set="ValueChanged" />

@code {
    [Parameter]
    public TValue Value { get; set; }
    
    [Parameter]
    public EventCallback<TValue> ValueChanged { get; set; }
}
در دات نت 7، دو binding modifier جدید bind:get و bind:set جهت تعریف ساده‌تر two-way data-binding اضافه شده‌اند که باید به همراه هم اضافه شوند. توسط bind:get، مقدار در حال تغییر و توسط bind:set، یک callback را که پس از تغییر این مقدار فراخوانی می‌شود، مشخص می‌کنیم و ... همین! پس از این تعاریف دیگر نیازی به بازنویسی قسمت set پارامتر Value مانند قبل نیست و اکنون می‌توان به bind-Value@ دو طرفه به صورت زیر دسترسی یافت:
<MyInput @bind-Value="text" />

@code {
    string text = "Type something great!";
}