برای تعریف المانهای فرمها نیاز است ویژگیهای قابل توجهی را مانند placeholder ،required ،maxlength و غیره، تعریف کرد که در صورت زیاد بودن تعداد المانهای یک فرم، مدیریت تعریف این ویژگیها مشکل میشود. به همین جهت قابلیت ویژهای مخصوص اینکار به نام Attribute Splatting در Blazor درنظر گرفته شدهاست. برای توضیح آن، ابتدا کامپوننت والد Pages\LearnBlazor\AttributeSplatting.razor و کامپوننت فرزند Pages\LearnBlazor\LearnBlazorComponents\AttributeSplattingChild.razor را ایجاد میکنیم.
در کامپوننت فرزند یا همان AttributeSplattingChild، یک المان را به همراه تعدادی ویژگی تعریف شده مشاهده میکنید:
<div> <h4 class="text-primary pt-3">Attribute Splatting Child Component</h4> <input id="roomName" placeholder="@Placeholder" required="@Required" maxlength="@MaxLength" class="form-control" /> </div> @code { [Parameter] public string Placeholder { get; set; } = "Initial Text"; [Parameter] public string Required { get; set; } = "required"; [Parameter] public string MaxLength { get; set; } = "10"; }
@page "/AttributeSplatting" <h1>Attribute Splatting</h1> <AttributeSplattingChild Placeholder="Enter the Room Name From Parent" MaxLength="5"> </AttributeSplattingChild>
مشکل! کامپوننت AttributeSplattingChild که فقط به همراه یک المان است، تا این لحظه نیاز به تعریف سه پارامتر جدید را جهت تامین ویژگیهای آن المان داشتهاست. اگر تعداد این المانها افزایش پیدا کرد، آیا راه بهتری برای مدیریت تعداد بالای ویژگیهای مورد نیاز وجود دارد؟
پاسخ: در یک چنین حالتی میتوان ویژگیهای هر المان را توسط پارامتری از نوع Dictionary مدیریت کرد؛ بجای تعریف تک تک آنها به صورت خواصی مجزا. به این قابلیت، Attribute Splatting میگویند.
در این حالت تمام کدهای AttributeSplattingChild.razor به صورت زیر خلاصه میشوند:
<div> <h4 class="text-primary pt-3">Attribute Splatting Child Component</h4> <input id="roomName" @attributes="InputAttributes" class="form-control" /> </div> @code { [Parameter] public Dictionary<string, object> InputAttributes { get; set; } = new Dictionary<string, object> { { "required" , "required"}, { "placeholder", "Initial Text"}, { "maxlength", 10} }; }
و همچنین در ادامه کامپوننت والد یا AttributeSplatting.razor نیز به صورت زیر تغییر میکند:
@page "/AttributeSplatting" <h1>Attribute Splatting</h1> <AttributeSplattingChild InputAttributes="InputAttributesFromParent"></AttributeSplattingChild> @code{ Dictionary<string, object> InputAttributesFromParent = new Dictionary<string, object> { { "required" , "required"}, { "placeholder", "Enter the Room Name From Parent"}, { "maxlength", 5} }; }
ساده سازی روش تعریف key/valueهای شیء دیکشنری Attribute Splatting
تا اینجا موفق شدیم تعداد قابل ملاحظهای از پارامترهای عمومی یک کامپوننت را تنها توسط یک شیء Dictionary مدیریت کنیم. همچنین همانطور که ملاحظه میکنید، هم Dictionary سمت کامپوننت فرزند و هم سمت کامپوننت والد، نیاز به مقدار دهی اولیهای را دارند. این مقدار دهی اولیه را میتوان به نحو دیگری نیز در حین استفادهی از قابلیت Attribute Splatting، انجام داد:
<div> <h4 class="text-primary pt-3">Attribute Splatting Child Component</h4> <input id="roomName" @attributes="InputAttributes" placeholder="Initial Text" class="form-control" /> </div> @code { [Parameter(CaptureUnmatchedValues = true)] public Dictionary<string, object> InputAttributes { get; set; } = new Dictionary<string, object>(); }
پس از این تغییر، کامپوننت والد هم به صورت زیر خلاصه میشود و دیگر نیازی به تعریف و مقدار دهی InputAttributes و یا تعریف مجزای یک دیکشنری را ندارد. در اینجا هر ویژگی که به المان نسبت داده شود، به عنوان Unmatched Values تفسیر شده و مورد استفاده قرار میگیرد.
@page "/AttributeSplatting" <h1>Attribute Splatting</h1> <AttributeSplattingChild placeholder="Placeholder default"></AttributeSplattingChild>
اگر به تصویر فوق دقت کنید، هرچند در کامپوننت والد مقدار placeholder، به متن دیگری تنظیم شده، اما متن تنظیم شدهی در کامپوننت فرزند، تقدم بیشتری پیدا کرده و نمایش داده شدهاست. علت اینجا است که محل قرارگیری آن در مثال فوق، در سمت راست دایرکتیو attributes@ است. اگر آنرا در سمت چپ attributes@ قرار دهیم، حق تقدم attributes@ بیشتر شده و مقدار تنظیم شدهی در سمت کامپوننت والد، بجای placeholder اولیهی تعریف شدهی در اینجا مورد استفاده قرار میگیرد:
<input id="roomName" placeholder="Initial Text" @attributes="InputAttributes" class="form-control" />
روش انتقال پارامترها به چندین زیر سطح
در قسمت قبل، ParentComponent.razor و ChildComponent.razor را تعریف و تکمیل کردیم. هدف از آنها، بررسی ویژگی Render Fragmentها بود. در ادامهی آن، یک زیر کامپوننت دیگر را نیز به نام Pages\LearnBlazor\LearnBlazorComponents\GrandChildComponent.razor اضافه میکنیم. هدف این است که کامپوننت Parent، کامپوننت Child را فراخوانی کند و کامپوننت Child، کامپوننت GrandChild را تا یک سلسله مراتب از کامپوننتها را تشکیل دهیم.
محتوای GrandChildComponent را هم بسیار ساده نگه میداریم، تا پارامتری رشتهای را دریافت کرده و نمایش دهد:
<div class="row"> <h4 class="text-primary pl-4 pt-2 col-12">Grand Child Component</h4> <br /> <p> There is a message - @MessageForGrandChild </p> </div> @code { [Parameter] public string MessageForGrandChild { get; set; } }
<div class="mt-2"> <GrandChildComponent MessageForGrandChild="@MessageForGrandChild"></GrandChildComponent> </div> @code { [Parameter] public string MessageForGrandChild { get; set; } // ... }
<ChildComponent MessageForGrandChild="This is a message from Grand Parent" Title="This is the second child component"> <p><b>@MessageText</b></p> </ChildComponent>
بنابراین اکنون این سؤال مطرح میشود که آیا میتوان پارامتری را در همان کامپوننت Parent تعریف کرد که توسط کامپوننت GrandChild قابل شناسایی و استفاده باشد، بدون اینکه کامپوننت Child را در این بین تغییر دهیم؟
پاسخ: بله. برای اینکار ویژگیهای CascadingValue و CascadingParameter در Blazor پیش بینی شدهاند.
در ابتدا، پارامتر MessageForGrandChild کامپوننت Child حذف کرده و سپس آنرا توسط کامپوننت توکار CascadingValue محصور میکنیم. در اینجا نیاز است مقدار انتقالی را نیز مشخص کنیم:
<CascadingValue Value="@MessageForGrandChild"> <ChildComponent Title="This is the second child component"> <p><b>@MessageText</b></p> </ChildComponent> </CascadingValue> @code { string MessageForGrandChild = "This is a message from Grand Parent";
<GrandChildComponent></GrandChildComponent>
[CascadingParameter] public string MessageForGrandChild { get; set; }
چند نکته:
- در اینجا نوع CascadingParameter تعریف شده، باید با نوع Value کامپوننت CascadingValue، در بالاترین سطح سلسله مراتب کامپوننتها، یکی باشد.
- نام CascadingParameter تعریف شده مهم نیست. فقط نوع آن مهم است.
- تمام کامپوننتهای موجود و پوشش داده شدهی در سلسله مراتب جاری، قابلیت تعریف CascadingParameter ای مانند مثال فوق را دارند و این تعریف، محدود به پایینترین سطح موجود نیست. برای مثال در اینجا در کامپوننت Child هم در صورت نیاز میتوان همین CascadingParameter را تعریف و استفاده کرد.
روش تعریف پارامترهای آبشاری نامدار
تا اینجا روش انتقال یک پارامتر را از بالاترین سطح، به پایینترین سطح سلسله مراتب کامپوننتهای تعریف شده، بررسی کردیم. اکنون شاید این سؤال مطرح شود که اگر خواستیم بیش از یک پارامتر را بین اجزای این سلسله، به اشتراک بگذاریم چه باید کرد؟
در این حالت میتوان پارامتر جدید را توسط یک کامپوننت CascadingValue تو در تو، به صورت زیر معرفی کرد؛ که اینبار نامدار نیز هست:
<CascadingValue Value="@MessageForGrandChild" Name="MessageFromGrandParent"> <CascadingValue Value="@Number" Name="GrandParentsNumber"> <ChildComponent Title="This is the second child component"> <p><b>@MessageText</b></p> </ChildComponent> </CascadingValue> </CascadingValue> @code { string MessageForGrandChild = "This is a message from Grand Parent"; int Number = 7;
پس از این تغییر، GrandChildComponent، این پارامترهای نامدار را از طریق ذکر صریح خاصیت Name ویژگی CascadingParameter، دریافت میکند:
<div class="row"> <h4 class="text-primary pl-4 pt-2 col-12">Grand Child Component</h4> <br /> There is a message: @Message <br /> GrandParentsNumber: @Number </div> @code { [CascadingParameter(Name = "MessageFromGrandParent")] public string Message { get; set; } [CascadingParameter(Name = "GrandParentsNumber")] public int Number { get; set; } }
یک نکته: چون نوع پارامترهای ارسالی یکی نیست، الزامی به ذکر نام آنها نبود. در این حالت بر اساس نوع پارامترهای آبشاری، عملیات اتصال مقادیر صورت میگیرد. اما اگر نوع هر دو را برای مثال رشتهای تعریف میکردیم، مقدار Number، بر روی مقدار MessageForGrandChild بازنویسی میشد. یعنی در UI، هر دو پارامتر هم نوع، یک مقدار را نمایش میدادند که در حقیقت مقدار پایینترین CascadingValue تعریف شدهاست. بنابراین ذکر نام پارامترهای آبشاری، روشیاست جهت تمایز قائل شدن بین پارامترهای هم نوع.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: Blazor-5x-Part-09.zip