مطالب
HTML5 Web Component - قسمت اول - معرفی و مفاهیم اولیه
Web Components مجموعه‌ای از تکنولوژی‌هایی می‌باشند که امکان ساخت المان‌های سفارشی با قابلیت استفاده‌ی مجدد و به همراه کپسوله‌سازی ساختار، استایل و عاملیت (Functionality) متناظر با المان ایجاد شده را در اختیار شما قرار می‌دهد. 

A Path to Standard Components

در این سری چند قسمتی، ابتدا روش ساخت Web Components را بدون استفاده از ابزار خاصی بررسی کرده و در ادامه با معرفی Stenciljs، چند کامپوننت سفارشی را طراحی خواهیم کرد.

سه تکنولوژی اصلی مورد استفاده برای ساخت Web Components عبارتند از:

  • Custom Elements
  • Shadow DOM
  • HTML Templates


Custom Elements

مجموعه‌ای از API‌های جاوااسکریپتی هستند که امکان تعریف یکسری المان معتبر HTML را با قالب‌، رفتار و نام سفارشی، فراهم می‌کنند. علاوه بر اینکه می‌توان یک المان سفارشی مستقل (Autonomous custom elements) را تعریف کرد، امکان سفارشی‌سازی و گسترش المان‌های موجود (Customized built-in elements) را نیز خواهیم داشت. 
المان‌های سفارشی تعریف شده را مانند کامپوننت‌های Angular و یا React تصور کنید؛ با این تفاوت که هیچ وابستگی به Angular و یا React ندارند. همچنین امکان استفاده از آنها در انوع و اقسام فریمورک‌های فرانت-اند وجود دارد.
شکل ساده‌ی یک Custom Element، متشکل است از کلاسی که کلاس HTMLElement را گسترش می‌دهد و یک نام یکتا که باید حتما دارای یک «-» باشد (kebab-case). برای مثال:
//app.component.js
class AppComponent extends HTMLElement {
  static is = 'app-root'
  connectedCallback(){
    this.innerHTML=`<h1>Hello World!</h1>`
  }
}

customElements.define(AppComponent.is, AppComponent)

//index.html
<app-root></app-root>



در تکه کد بالا، از متد connectedCallback به عنوان یکی از متدهای چرخه‌ی حیات یک المان سفارشی، برای تنظیم innerHTML آن استفاده شده است. سپس با استفاده متد define مربوط به CustomElementRegistry که از طریق window.customeElements قابل دسترسی می‌باشد و با مشخص کردن نام و کلاس مرتبط، المان مورد نظر را ثبت و معرفی کردیم.

برای سفارشی‌سازی یک المان موجود، کار با ارث‌بری از کلاس متناظر با آن المان شروع می‌شود. به عنوان مثال در اینجا قصد داریم با کلیک بر روی لینک‌های موجود در صفحه و قبل از هدایت به آدرس مقصد، یک تأییدیه را از کاربر بگیریم:
//confirm-link.component.js
class ConfirmLinkComponent extends HTMLAnchorElement {
  static is = "confim-link";
  connectedCallback() {
    this.addEventListener("click", e => {
      if (!confirm("Are you sure?")) {
        e.preventDefault();
      }
    });
  }
}
customElements.define(ConfirmLinkComponent.is, ConfirmLinkComponent, {
  extends: "a"
});
<a href="http://google.com" is='confirm-link'>
google.com
</a>
در اینجا در بدنه‌ی متد connectedCallback، مشترک رخداد کلیک المان جاری شده و براساس نتیجه‌ی تأییدیه، تصمیم به ادامه یا لغو رفتار پیش‌فرض آن گرفته‌ایم. برای معرفی این المان جدید، کافی است از طریق آرگومان سوم متد define، مشخص کنیم که قصد گسترش چه المانی را داریم. از این پس اگر لینک‌های موجود را از طریق ویژگی is با "confirm-link" تزئین کرده باشید، شاهد رفتار سفارشی جدید خواهیم بود.

Shadow DOM

جنبه‌ی بسیار مهم Web Components، کپسوله‌سازی می‌باشد که امکان مخفی کردن ساختار، استایل و رفتار متناظر با المان سفارشی را مهیا می‌کند تا با سایر قسمت‌های کد تداخلی نداشته باشد. در این میان Shadow DOM نقش اصلی را برای رسیدن به این سطح از کپسوله‌سازی ایفا خواهد کرد. Shadow DOM به عنوان یک نسخه‌ی کپسوله شده‌ی DOM می‌باشد که امکان کپسوله‌سازی Markup & Styling و همچنین کاهش پیچیدگی استایل‌دهی را مهیا خواهد کرد. می‌توان Shadow DOM را همانند iframe تصور کرد که امکان نشتی استایل‌ها و سلکتورها از Light DOM (همان DOM اصلی) به داخل و از داخل به Light DOM وجود ندارد؛ ولی برخلاف iframe همچنان Shadow Rootهای (المان ریشه Shadow DOM) متناظر، در همان کانتکست DOM اصلی قرار دارند و همچنین در اینجا برای دسترسی به مقادیر المان‌های موجود در Shadow DOM، می‌توان یک API مناسب را در سطح المان سفارشی در نظر گرفت، ولی در مقابل برای همین کار در یک iframe نیاز است تا DOM متناظر با آن را Traverse کنیم که البته به عمد به این صورت طراحی شده است؛ چرا که اهداف دیگری را نیز دنبال می‌کند.

به تصویر زیر توجه نمائید:

برای مشاهده‌ی Shadow DOM متناظر با یکسری المان توکار مانند input.range یا input.date در مرورگر کروم، لازم است به قسمت Developer tools آن مراجعه کرده و سپس با فشردن دکمه‌ی F1 به قسمت تنظیمات آن مراجعه کرده و در قسمت Preferences آن و بخش Elements گزینه "Show user agent shadow DOM" را انتخاب کنید. در اینجا input به عنوان المانی که Shadow DOM به آن متصل شده (attach) نقش Shadow Host را ایفا می‌کند.
برای اتصال یک Shadow DOM به یک المان، به شکل زیر می‌توان عمل کرد:
var div = document.createElement('div');
var shadowRoot = div.attachShadow({mode: 'open'}); //or mode: 'closed'
shadowRoot.innerHTML = '<h1>Hello Shadow DOM</h1>';

متد attachShadow یک Shadow DOM Tree جدید را به div متصل کرده و ارجاعی به shadowRoot آن را برمی‌گرداند. این shadowRoot از طریق خصوصیت host نیز ارجاعی را به میزبان خود دارد. از این پس نیز از طریق خصوصیت div.shadowRoot امکان دسترسی به Shadow DOM ایجاد شده خواهیم داشت. البته به دلیل اینکه در اینجا با حالت 'open' استفاده شده است، این دسترسی به shadowRoot از طریق المان وجود دارد، در غیر این صورت اگر با 'closed' مقداردهی شود، خصوصیت div.shadowRoot مقدار نال خواهد داشت و امکان دسترسی به المان‌های داخلی از طریق جاوااسکریپت ممکن نخواهد بود. 
نکته: 'user-agent' نیز حالتی است که برای المان‌های توکار مانند input.range و ... مورد استفاده قرار می‌گیرد و رفتاری شبیه به حالت 'closed' را دارد.
نکته: امکان اتصال Shadow DOM به المان‌های خاصی از جمله div و یا المان‌های سفارشی که کلاس HTMLElement را گسترش می‌دهند (این اتصال در زمان پیاده‌سازی آنها انجام خواهد شد)، وجود دارد.
در زمان استفاده از متد attachShadow، علاوه بر امکان تعیین حالت آن، امکان تنظیم delegatesFocus برای برطرف کردن موضوعات مرتبط با focus در زمان توسعه‌ی المان‌های سفارشی مورد استفاده قرار می‌گیرد. به این صورت که اگر در قسمتی از المان سفارشی که خاصیت و قابلیت focus را ندارد، کلیک شود، focus به اولین المان با قابلیت focus داخل المان سفارشی خواهد رسید و از این پس امکان استایل‌دهی با استفاده از سلکتور custom-element:focus را خواهیم داشت.

مفهوم دیگری وجود دارد تحت عنوان Shadow Boundary که تعیین کننده‌ی مرز بین Light DOM و Shadow DOM و همان لایه‌ی مهیا کننده‌ی کپسوله‌سازی Styling و Markup می‌باشد. در مطالب آتی خواهیم دید که به چه شکلی رخدادهای سفارشی ما قابلیت عبور از این لایه را خواهند داشت.


HTML Templates 

تا قبل از اینکه المان template معرفی شود، از یکی از روش‌های زیر برای استفاده‌ی مجدد از یک قالب HTML عمل می‌کردیم:
1- استفاده از یک المان خاص با ویژگی hidden یا استایل display:none 
  • استفاده از DOM و آگاه بودن مرورگر از وجود آن، عملیات clone را ساده خواهد کرد.
  • محتوای داخل آن رندر نخواهد شد.
  • اگرچه محتوای آن مخفی می‌باشد، با این حال درخواست‌های مرتبط با تصاویر یا اسکریپت‌ها انجام خواهد شد.
<div id="template" hidden>
  <img src="logo.png">
  <div class="comment"></div>
</div>

2- استفاده از تگ script با یک type سفارشی
<script id="template" type="text/x-template">
  <img src="logo.png">
  <div class="comment"></div>
</script>

<script id="template" type="text/x-kendo-template">
        <ul>
            # for (var i = 0; i < data.length; i++) { #
            <li>#= data[i] #</li>
            # } #
        </ul>
</script>
  • از آنجا که تگ script به صورت پیش‌فرض دارای استایل display:none می‌باشد، محتوای داخل آن رندر نخواهد شد.
  • به دلیل عدم مقداردهی ویژگی type آن با "text/javascript"، مرورگر محتوای آن را به عنوان کد جاوااسکریپت parse نخواهد کرد.
  • استفاده از خصوصیت innerHTML مشکل امنیتی XSS را بدنبال خواهد داشت .
HTML Template ویژگی‌های مثبت هر دو روش قبل را دارد. از طریق کد امکان clone و رندر کردن آن وجود دارد و همچنین کوئری المان‌های داخل آن نیز ممکن نیست:
<template id="template">
  <img src="logo.png">
  <div class="comment"></div>
</template>
و برای فعال‌سازی آن از طریق متد cloneNode متناظر با خصوصیت content به شکل زیر عمل خواهیم کرد:
  var template = document.querySelector("template");
  var clonedNode = template.content.cloneNode(true); //deep:true
  document.body.appendChild(clonedNode);
نکته: امکان تعریف قالب‌های تودرتو نیز وجود دارد که در این صورت به شکل جداگانه‌ای باید عملیات فعال‌سازی هر کدام از آنها انجام گیرد.
نظرات مطالب
نمایش پیام هشدار در Blazor با استفاده از کامپوننت Alert بوت استرپ ۵
معرفی کامپوننت Error Boundaries در Blazor 6x

شبیه به کامپوننت Alert ای که در اینجا ملاحظه می‌کنید و امکان دسترسی به آن توسط یک CascadingValue در سایر کامپوننت‌ها میسر شده، در Blazor 6x، کامپوننت جدید ErrorBoundary اضافه شده‌است که می‌توان همانند مثال فوق، آن‌را در بالاترین سطح ممکن در فایل MainLayout.razor، جهت محصور سازی Body به صورت زیر معرفی کرد:
<ErrorBoundary> 
    <ChildContent> 
        @Body 
    </ChildContent> 
    <ErrorContent> 
        <p>Whoa, sorry about that! While we fix this problem, buy some shirts!</p> 
    </ErrorContent> 
</ErrorBoundary>
کار آن نمایش خطایی در زمان بروز یک استثنای مدیریت نشده، در کامپوننت‌های ذیل این سلسله مراتب است و قالب ErrorContent آن، امکان سفارشی سازی پیامی را جهت نمایش به کاربر میسر می‌کند. اگر از این قالب استفاده نشود، فقط پیام «An error has occurred» نمایش داده خواهد شد. بنابراین دیگر بروز استثناءها، سبب خاتمه‌ی کل برنامه و نیاز به ری‌استارت آن نمی‌شوند.

روش دسترسی به اصل استثناء: قالب محتوای آن به صورت جنریک، یعنی <RenderFragment<Exception تعریف شده‌است. بنابراین می‌توان به اصل استثنای رخ داده به صورت زیر دسترسی یافت:
<ErrorContent Context="exception"> 
  @exception
</ErrorContent>

روش پاک کردن استثنای نمایش داده شده: اطلاعات نمایش داده شده چون در بالاترین سطح (در layout برنامه) رندر می‌شوند، تا زمانیکه مرورگر باز است به همان نحو باقی می‌مانند و تغییر نمی‌کنند. البته خود این کامپوننت به همراه خاصیت MaximumErrorCount است که به صورت پیش‌فرض به 100 تنظیم شده‌است و پس از وقوع 100 استثناء، ریست می‌شود. اگر می‌خواهید این ریست، پس از هدایت به صفحات دیگر صورت گیرد و در صفحه‌ی جدید، خطای صفحه‌ی قبلی را مشاهده نکنید، خودتان باید به صورت دستی آن‌را ریست کنید:
<ErrorBoundary @ref="errorBoundary">
    @Body
</ErrorBoundary>

@code {
    ErrorBoundary errorBoundary;
    protected override void OnParametersSet()
    {
        // On each page navigation, reset any error state
        errorBoundary?.Recover();
    }
}
در اینجا با استفاده از یک ref@، به وهله‌ای از کامپوننت، دسترسی یافته و سپس می‌توان متد Recover آن‌را جهت پاک کردن سابقه‌ی استثناءهای رخ داده فراخوانی کرد.


پ.ن.
این کامپوننت جدید از امکان مشابهی در React ایده گرفته شده‌است.
مطالب
مدیریت استثناءها در Blazor Server - قسمت دوم
در قسمت اول دیدیم که توسط Error boundary می‌توان استثناءها را در Blazor مدیریت کرد؛ اما اگر بخواهیم قدری سفارشی‌تر عمل کرده و علاوه بر نمایش پیغام خطای مناسب به صورت جاوا اسکریپتی، استثنای رخ داده را لاگ کنیم چطور؟
خبر خوب اینکه این مهم نیز به راحتی امکان پذیر است؛ با استفاده از مفهوم CascadingValueها.
یک کامپوننت Error.razor به شکل زیر ایجاد می‌کنیم:
@using Microsoft.Extensions.Logging
@inject ILogger<Error> Logger
@inject IJSRuntime jsRuntime

<CascadingValue Value="this">
    @ChildContent
</CascadingValue>

@code {
    [Parameter]
    public RenderFragment? ChildContent { get; set; }

    public void ProcessError(Exception ex)
    {
        Logger.LogError("Error:ProcessError - Type: {Type} Message: {Message}", 
            ex.GetType(), ex.Message);
        jsRuntime.ToastrError("متاسفانه خطایی رخ داد");
        //StateHasChanged();
    }
}
همانطور که مشخص است این کامپوننت سفارشی توسط متد ProcessError می‌تواند خطاها را با استفاده از logger توکار Blazor لاگ نموده و پیغام خطای جاوااسکریپتی نمایش دهد. بدیهی است که می‌توان از لاگ کننده‌های دیگری نظیر Serilog، Elmah و حتی لاگ کننده‌های سفارشی دیگر نیز برای لاگ کردن در این متد بهره جست.
از StateHasChanged زمانی استفاده خواهد شد که متد پردازش خطا می‌خواهد به صورت مستقیم در رندر شدن رابط کاربری کامپوننتی که در آن استثنایی رخ داده‌است، دخالت کند. برای مثال زمانیکه می‌خواهیم تغییری در عناصر رندر شده صفحه، بعد از خطا ایجاد کنیم (رنگ دکمه ای عوض شود یا رنگ فونت برچسب یا تکست باکس یا ...).
حال کامپوننت App.razor را به شکل زیر ویرایش می‌نماییم:
<Error>
    <Router ...>
        ...
    </Router>
</Error>
در حقیقت کامپوننت Router را توسط کامپوننت سفارشی خودمان (Error) محصور می‌کنیم تا کامپوننت Error به صورت آبشاری به هر کامپوننت برنامه که Error را به صورت [ CascadingParameter ]  درنظر بگیرد منتقل شود.
حال فقط کافی است برای پردازش خطاها به شکل زیر در کامپوننت‌های دیگر عمل نمود:
@code {
    [CascadingParameter]
    public Error? Error { get; set; }

    private void CreatePost()
    {
        try
        {           
           throw new InvalidOperationException("پست ساخته نشد!");            
        }
        catch (Exception ex)
        {
            Error?.ProcessError(ex);
        }
    }
}
همینطور که ملاحظه می‌نمایید کامپوننت Error به عنوان یک CascadingParameter تعریف شده‌است و در یک بلاک try catch متد ProcessError کامپوننت Error صدا زده شده و استثنای صادر شده به آن ارسال شده‌است. در مثال من کامپوننت Error فقط یک متد پردازش خطا دارد. بدیهی است که این کامپوننت می‌تواند چندین متد پردازش خطای سفارشی دیگر نیز برای مقاصد مختلف داشته باشد.
نظرات اشتراک‌ها
آیا blazor آینده ای دارد؟
مطلب عجیبی بود چون نویسنده MVP بوده یه زمانی. Blazor مسلماً هدفش برنامه نویسهای دات نت و سی شارپ هستن و اصولا کاری به برنامه نویسهای javascript نداره که اونا رو به خودش جذب کنه. نویسنده به Web assembly ایراد گرفته اما وسطهای متن اومده گفته تکنولوژی‌های دیگه مثل flutter هم دارن میرن سمت web assembly و یه جایی هم اشاره می‌کنه که تکنولوژی‌های دیگه که از Web assembly استفاده می‌کنن تو بحث کارایی بهتر از blazor هستند یا خواهند بود. نویسنده به razor اشاره می‌کنه که چرا برنامه نویس محدود شده. در کل نویسنده به دلایل نام معلوم مغرضانه به blazor حمله کرده. البته این موارد کم هم نیست مثلا توی youtube هم یکی رفته react رو با blazor مقایسه کرده که داخل یک صفحه چند هزار تا div ایجاد می‌کنه. حتی به خودش زحمت نداده کد Async بزنه و بجای concat از String builder استفاده کنه.