عنوان:

‫طراحی صفحات 404 سفارشی در برنامه‌های وب Blazor نسخه .NET 8 و جدیدتر


نویسنده: وحید نصیری
تاریخ: ۱۴۰۴/۰۱/۲۸ ۱۲:۵۴
آدرس: www.dntips.ir
مقدمه
در توسعه برنامه‌های وب، ارائه تجربه کاربری (User Experience) مناسب هنگام مواجهه با خطاها از اهمیت ویژه‌ای برخوردار است. یکی از رایج‌ترین خطاها، خطای 404 (یافت نشد) است که زمانی رخ می‌دهد که کاربر به صفحه‌ای دسترسی پیدا می‌کند که وجود ندارد. در فریم‌ورک Blazor، ایجاد صفحات 404 سفارشی به توسعه‌دهندگان این امکان را می‌دهد تا به‌جای نمایش پیام‌های پیش‌فرض مرورگر، صفحاتی کاربرپسند و متناسب با طراحی برنامه ارائه دهند. با معرفی مدل جدید Blazor Web App در نسخه .NET 8، رویکردهای قدیمی‌تر برای مدیریت صفحات 404، مانند استفاده از تگ <NotFound> در کامپوننت Router، دیگر کارایی ندارند.

آشنایی با Blazor Web App و تغییرات در .NET 8
Blazor یک فریم‌ورک قدرتمند برای ساخت برنامه‌های وب تعاملی (Interactive Web Applications) با استفاده از زبان #C به‌جای جاوااسکریپت است. در نسخه‌های قدیمی‌تر Blazor، توسعه‌دهندگان می‌توانستند از دو مدل میزبانی (Hosting Model) استفاده کنند: Blazor Server و Blazor WebAssembly. در این مدل‌ها، مدیریت صفحات 404 از طریق تگ <NotFound> در کامپوننت Router امکان‌پذیر بود. کد زیر نمونه‌ای از این رویکرد در نسخه‌های قدیمی‌تر است:
<Router AppAssembly="@typeof(Program).Assembly">
    <Found Context="routeData">
        <AuthorizeRouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)"/>
    </Found>
    <NotFound>
        <LayoutView Layout="@typeof(MainLayout)">
            <p>این صفحه یافت نشد. لطفاً آدرس را بررسی کنید.</p>
        </LayoutView>
    </NotFound>
</Router>
این کد زمانی اجرا می‌شد که مسیری (Route) در برنامه پیدا نمی‌شد و محتوای داخل تگ <NotFound> به‌عنوان صفحه 404 نمایش داده می‌شد. با این حال، در مدل جدید Blazor Web App که در .NET 8 معرفی شده است، این روش دیگر پشتیبانی نمی‌شود. دلیل آن تغییر در نوع Router و استفاده از اسکریپت blazor.web.js به‌جای blazor.server.js یا blazor.webassembly.js است. این تغییر به توسعه‌دهندگان امکان می‌دهد تا از ترکیب رندر سمت سرور (Server-Side Rendering یا SSR)، رندر سمت کلاینت (Client-Side Rendering یا CSR) و رندر استاتیک (Static SSR) در یک برنامه استفاده کنند، اما تگ <NotFound> دیگر به‌درستی عمل نمی‌کند.

روش جدید: استفاده از صفحه Fall-Through
برای ایجاد یک صفحه 404 سفارشی در Blazor Web App، می‌توان از یک صفحه با اولویت پایین (Low Specificity) استفاده کرد که به‌عنوان یک مسیر پیش‌فرض (Fallback Route) عمل کند. این صفحه زمانی نمایش داده می‌شود که هیچ مسیر دیگری با درخواست کاربر مطابقت نداشته باشد. برای این منظور، یک کامپوننت Razor با نام NotFoundPage.razor ایجاد می‌کنیم که از یک الگوی مسیر (Route Template) با مشخصه nonfile استفاده می‌کند. کد زیر نمونه‌ای از این صفحه است:
@page "/{*route:nonfile}"

<h1>صفحه یافت نشد</h1>
<p>متأسفانه صفحه‌ای که به دنبال آن هستید وجود ندارد. لطفاً آدرس را بررسی کنید یا به <a href="/">صفحه اصلی</a> بازگردید.</p>

@code {
    [Parameter]
    public string? Route { get; set; }
}
توضیحات کد:
  • الگوی مسیر/ {*route:nonfile}: این الگو به Blazor می‌گوید که هر مسیر غیرمعتبر (که به یک فایل فیزیکی اشاره ندارد) را به این صفحه هدایت کند. مشخصه nonfile تضمین می‌کند که درخواست‌های مربوط به فایل‌های استاتیک (مانند تصاویر یا CSS) به این صفحه هدایت نشوند.
  • پارامتر Route: این پارامتر مسیر درخواست‌شده را دریافت می‌کند، اما در این مثال استفاده نمی‌شود. وجود آن برای جلوگیری از خطای Blazor در مورد عدم تطابق پارامترها ضروری است.
  • محتوای صفحه: می‌توانید محتوای دلخواه، مانند پیام خطا، لینک بازگشت به صفحه اصلی یا حتی یک فرم جستجو، را در این بخش قرار دهید.

این روش ساده و مؤثر است و به توسعه‌دهندگان اجازه می‌دهد تا یک صفحه 404 کاملاً سفارشی با طراحی متناسب با برند برنامه ایجاد کنند.

نکات پیشرفته‌تر

مدیریت سئو (SEO): صفحات 404 باید کد وضعیت HTTP 404 را به درستی به مرورگر و موتورهای جستجو ارسال کنند. Blazor به‌طور پیش‌فرض این کار را انجام می‌دهد، اما برای اطمینان، می‌توانید از middleware سفارشی در ASP.NET Core استفاده کنید:
app.UseStatusCodePagesWithReExecute("/not-found");
این کد هر درخواست با کد وضعیت 404 را به مسیر /not-found هدایت می‌کند، که می‌تواند همان NotFoundPage.razor باشد.

ثبت خطاها (Logging): برای بهبود برنامه، می‌توانید مسیرهای نامعتبر را ثبت کنید تا الگوهای دسترسی کاربران را تحلیل کنید. این کار با استفاده از سرویس ILogger در کد C# کامپوننت امکان‌پذیر است:
@page "/{*route:nonfile}"
@layout MainLayout
@inject ILogger<NotFoundPage> Logger

<h1>صفحه یافت نشد</h1>
<p>متأسفانه صفحه‌ای که به دنبال آن هستید وجود ندارد.</p>

@code {
    [Parameter]
    public string? Route { get; set; }

    protected override void OnInitialized()
    {
        Logger.LogWarning($"Requested invalid route: {Route}");
    }
}

نتیجه‌گیری
طراحی صفحات 404 سفارشی در Blazor Web Apps نسخه .NET 8 و جدیدتر، با وجود تغییرات در معماری Router، همچنان ساده و انعطاف‌پذیر است. با استفاده از یک صفحه Fall-Through با الگوی مسیر مناسب، توسعه‌دهندگان می‌توانند صفحاتی کاربرپسند و هماهنگ با طراحی برنامه ایجاد کنند. این روش نه‌تنها تجربه کاربری را بهبود می‌بخشد، بلکه با امکاناتی مانند ثبت خطاها و بهینه‌سازی سئو، به توسعه‌دهندگان کمک می‌کند تا برنامه‌های حرفه‌ای‌تر و قابل‌اعتمادتری بسازند.


مشاهده مطلب اصلی

نظرات

  • مجید شهاب فر در ۱۴۰۴/۰۱/۲۸ ۱۶:۰۸
    من سال گذشته 3 پروژه با Blazor Web Apps با رندرینگ اتومات به صورت فول استک (با external backend) رو پیاده سازی و توسعه دادم واقعا تجربه دل انگیزی بود. همچنان هم ادامه میدم. امیدوارم پشتیبانی مایکروسافت با قدرت ادامه داشته باشته. اگه برنامه نویس NET. هستید و در دوراهی انتخاب Blazor و React/Angular قرار دارید من Blazor رو پیشنهاد میکنم.
    • جاهد در ۱۴۰۴/۰۱/۲۸ ۲۱:۳۶
      من چندتا پروژه با blazor wasm انجام دادم درکنارتمام مزیت های اون برای برنامه نویسان دات نتی یکسری معایب رو هم داره که موقع انتخاب براساس پروژه باید تصمیم گیری بشه:
      1. صفحات blazor wasm به نرمی و روانی صفحات در دیگر فریمورک ها (asp mvc-react-vuejs ..) نیست
      2. درblazor wasm با بزرگتر شدن پروژه مدت لود اولیه طولانی داره.گاهی مواقع تا 40 ثانیه هم طول میکشه.هرچند در برخی سناریو ها میشه از مدلهای میزبانی دیگه blazor استفاده کرد.حتی بعداز لود اولیه هم بازم کندی احساس میشه.مخصوصا با توجه به کاربرانی که مدام عادت به زدن f5 درکوچکترین مشکل دارن
      3. در صورت بروز رسانی برنامه blazor wasm به دلیل کش شدن در موارد زیادی حتما نیاز به ctrr+f5 هست.
      4. کارایی blazor wasm در مرورگرهای موبایل کمی با کندی همراه هست.واین کندی کاملا حس میشه
      5. اگر برنامه شما نیاز به بروزرسانی ui به صورت مداوم داشته باشه برنامه دچار کندی و اختلال خواهد شد.(مثلا در مورد راه اندازی یه callcenter که نیاز هست تعداد زیادی ایونت از بک اند به ui ارسال بشه و وضعیت داخلی ها در لحظه مانیتورینگ بشه برنامه بشدت کند وغیر قابل استفاده شد)
      6. کتابخانه و کامپوننتهای کمتردر برخی موارد اصلا کامپوننتی وجود نداره واگر هم باشه امکاناتی بسیار کمترکه به ناچار مجبورمیشیم ازاون صرف نظر کنیم.(به عنوان مثال نبود کتابخانه ای شبیه به react diagram
      https://projectstorm.cloud/react-diagrams/)

      همین موارد باعث شده درپروژه جدید تمایل به استفاده از vuejs داشته باشم.
      • مجید شهاب فر در ۱۴۰۴/۰۱/۲۸ ۲۱:۵۱
        دلیل این معایبی که ذکر کردین اینه که شما تنها از WASM استفاده کردین و سراغ ویژگیهای جدیدی که اضافه شده نرفتین. از Blazor 8 به بعد مدل جدید Blazor Web App معرفی شد که امکان استفاده خودکار از رندرینگ توئمان سمت کلاینت و سرور محیا شده و این مشکلات مربوط به کندی لود برنامه و ... حل شده.
        در مورد کامپوننت هم که با توجه به توسعه روز افزون چارچوبهای CSS مخصوصا Tailwind به راحتی میشه کامپوننتهای مختلف رو خودتون ایجاد کنید (از هوش مصنوعی هم کمکهای خوبی میتونین بگیرین). اگر هم نیاز به کامپوننتهای پیجیده تر دارید، موارد متعددی رو میتونین با یک جستجوی ساده پیدا کنین. فکر میکنم که Syncfusion یک پلنهایی برای استفاده رایگان از کامپوننتهاش که خیلی هم حرفه ای هستن داشته باشه.