اشتراکها
سری کار با Blazor و GraphQL
اشتراکها
Blazor Renderer مخصوص Flutter
با استفاده از Blazor میتوان برنامههای وب تعاملی را با کمک زبان #C تهیه کرد که پیشتر برای نوشتن آنها به جاوا اسکریپت نیاز بود. به این ترتیب میتوان برای تهیهی قسمتهای front-end و backend پروژهی خود، از زبانی که به آن تسلط دارید استفاده کنید. یکی از مزایای آن امکان به اشتراک گذاری کدهای سمت سرور و کلاینت است؛ با توجه به اینکه هر دو به یک زبان تهیه میشوند.
وضعیت توسعهی برنامههای وب، پیش از ارائهی Blazor
عموما برای توسعهی برنامههای وب، در سمت سرور آنها از زبانهایی مانند C#، Java و Python و امثال آنها استفاده میشود؛ اما این وضعیت در سمت کلاینت فرق میکند. در سمت کلاینت، عموما از فریمورکها و کتابخانههای جاوا اسکریپتی مانند Angular ،React ،Vue.js ،jQuery و غیره استفاده میشود.
همانطور که مشاهده میکنید، فراگیری و اجرای این دو گروه متفاوت از زبانها، مشکل و وقتگیر است. بنابراین چقدر خوب میشد اگر امکان تهیهی هر دو قسمت برنامههای وب، تنها با یک زبان میسر میشد. با استفاده از Blazor، این آرزو میسر شدهاست.
با استفاده از Blazor میتوان کدهای تعاملی UI را بجای استفاده از زبان جاوا اسکریپت، با کمک زبان #C تهیه کرد. به این ترتیب با استفاده از یک زبان میتوان کدهای سمت سرور و سمت کلاینت را پیاده سازی کرد. البته شاید این سؤال مطرح شود که مرورگرها تنها قادر به درک کدهای HTML و جاوا اسکریپت هستند و نه #C، بنابراین چگونه میتوان از زبان #C در مرورگرها نیز استفاده کرد؟ پاسخ به آن، به فناوری جدید «وب اسمبلی» بر میگردد. Blazor با استفاده از «وب اسمبلی» است که میتواند کدهای #C را درون مرورگر اجرا کند.
حالتهای مختلف هاست و ارائهی برنامههای مبتنی بر Blazor
برنامههای مبتنی بر Blazor، به دو روش مختلف قابل ارائه هستند:
الف) Blazor Server
Blazor Server، در اساس یک برنامهی استاندارد ASP.NET Core است که در آن تمام قابلیتهای سمت سرور، مانند کار با EF-Core، میسر است و امکان دسترسی به این امکانات به صورت یکپارچهای در سراسر برنامه وجود دارد. در این حالت، کامپوننتهای Blazor، بجای اجرای بر روی مرورگر کاربر، در سمت سرور اجرا میشوند. این تعاملات و به روز رسانیهای UI، توسط یک اتصال دائم SignalR مدیریت میشوند.
همانطور که مشاهده میکنید، در حالت هاست سمت سرور، همه چیز، منجمله کامپوننتهای Blazor، در همان سمت سرور قرار دارند و این اتصال پشت صحنهی SignalR است که کار تبادل اطلاعات ارسالی و رندر شده را بر عهده میگیرد.
ب) Blazor web assembly
در این حالت با استفاده از فناوری جدید «وب اسمبلی»، تمام کدهای یک برنامهی مبتنی بر Blazor به کمک NET Runtime.، داخل مرورگر اجرا میشود. به Blazor web assembly باید همانند فریمورکهای SPA (تک صفحهای وب)، مانند Angular و React نگاه کرد؛ با یک تفاوت مهم: در اینجا بجای استفاده از جاو اسکریپت برای نوشتن برنامهی SPA، از #C استفاده میشود. اگر به تصویر فوق دقت کنید، در حالت اجرای برنامههای Blazor web assembly، تنها به مرورگر کاربر نیاز است و همه چیز داخل آن قرار میگیرد. در اینجا دیگر خبری از یک اتصال دائم SignalR با سرور وجود ندارد.
البته باید دقت داشت که از فناوری وب اسمبلی، در تمام مرورگرهای جدید پشتیبانی میشود؛ منهای IE 11. در این حالت مرورگر کل برنامهی Blazor را دریافت میکند (همانند دریافت کل کدهای یک برنامهی Angular و یا React) و بدون استفاده از رندر سمت سرور حالت الف، قابلیت تعامل با کاربر را دارد.
بدیهی است با توجه به اینکه Blazor web assembly مستقیما داخل مرورگر اجرا میشود، دیگر همانند حالت الف، امکان دسترسی مستقیم به فناوریها و امکانات سمت سرور، مانند کار مستقیم با EF-Core را نخواهد داشت. برای این منظور دقیقا همانند روش کار با سایر فریم ورکهای SPA، نیاز به تهیهی یک ASP.NET Core Web API جهت تعامل با سرور خواهد بود.
مزایا و معایب حالتهای مختلف هاست برنامههای Blazor
الف) Blazor Server
مزایا:
- حجم دریافتی توسط مرورگر در این حالت بسیار کم است.
- امکان دسترسی به تمام امکانات سمت سرور را دارد؛ مانند تمام کتابخانههای سمت سرور و همچنین امکان دیباگ آن نیز همانند سایر برنامههای سمت سرور است.
- بر روی مرورگرهای قدیمی نیز قابل اجرا است؛ چون بدون نیاز به فناوری جدید «وب اسمبلی» کار میکند.
معایب:
- رندر شدن UI آن نسبت به حالت ب، کندتر است. از این جهت که تمام تعاملات UI آن، توسط اتصال SignalR به سمت سرور ارسال شده و سپس نتیجهی نهایی رندر شده، به سمت کلاینت بازگشت داده میشود.
- پشتیبانی از اجرای offline آن وجود ندارد. اگر اتصال SignalR موجود قطع شود، دیگر نمیتوان از برنامه استفاده کرد.
- با توجه به نیاز به استفادهی از یک اتصال دائم SignalR به ازای هر کاربر، مقیاس پذیری این نوع برنامهها کمتر است. البته اگر تعداد کاربران برنامههای شما در یک شبکهی اینترانت داخلی شرکتی محدود است، این مورد مشکل خاصی نخواهد بود. از دیدگاهی دیگر اگر تعداد کاربران برنامهی شما بسیار زیاد است، استفاده از Blazor Server توصیه نمیشود. البته باید دقت داشت که سروری با 4GB RAM، میتواند 5000 کاربر همزمان SignalR را مدیریت کند.
ب) Blazor web assembly یا به اختصار Blazor WASM
مزایا:
- هیچ نوع وابستگی به سمت سرور ندارد. همینقدر که برنامه توسط مرورگر دریافت شد، قابل اجر است.
- برای هاست آن الزاما نیازی به یک سرور IIS و یا یک وب سرور ASP.NET Core نیست.
- امکان ارائهی آن توسط یک CDN نیز وجود دارد.
- چون در این حالت کل برنامه توسط مرورگر دریافت میشود، قابلیت اجرای آفلاین را نیز پیدا میکند.
- برای کار، نیازی به اتصال دائم SignalR را ندارد؛ به همین جهت مقیاس پذیری آن بیشتر است.
معایب:
- حتما نیاز به استفادهی از مرورگرهای جدید با پشتیبانی از web assembly را دارد؛ برای مثال نیاز به کروم نگارش 57 به بعد و فایرفاکس نگارش 52 به بعد را دارد و بر روی IE اجرا نمیشود.
- چون کل برنامه در این حالت توسط مرورگر دریافت میشود، حجم ابتدایی دریافت آن کمی بالا است.
- میدان دید و عملکرد آن همانند سایر برنامههای SPA، محدود است به امکاناتی که مرورگر، در اختیار برنامه قرار میدهد.
ایجاد پروژههای خالی Blazor Server و Blazor web assembly
یا میتوانید از ویژوال استودیوی کامل و منوی افزودن پروژهی آن برای اینکار استفاده کنید و یا اگر به خروجی دستور dotnet new --list مراجعه کنیم، SDK دات نت 5، به همراه دو قالب مرتبط زیر نیز هست:
بنابراین فقط کافی است دستور dotnet new blazorserver و یا dotnet new blazorwasm را در یک پوشهی خالی اجرا کنیم تا بر اساس قالبهای پیشفرض ارائه شده، بتوان پروژههای خالی Blazor Server و یا Blazor WebAssembly را ایجاد کرد.
در قسمت بعد، این دو پروژهی خالی فوق را ایجاد کرده و ساختار آنها را بررسی میکنیم. همچنین نکاتی را هم که در این قسمت در مورد نحوهی هاست این برنامهها عنوان شد، بر روی این پروژهها مشاهده خواهیم کرد.
وضعیت توسعهی برنامههای وب، پیش از ارائهی Blazor
عموما برای توسعهی برنامههای وب، در سمت سرور آنها از زبانهایی مانند C#، Java و Python و امثال آنها استفاده میشود؛ اما این وضعیت در سمت کلاینت فرق میکند. در سمت کلاینت، عموما از فریمورکها و کتابخانههای جاوا اسکریپتی مانند Angular ،React ،Vue.js ،jQuery و غیره استفاده میشود.
همانطور که مشاهده میکنید، فراگیری و اجرای این دو گروه متفاوت از زبانها، مشکل و وقتگیر است. بنابراین چقدر خوب میشد اگر امکان تهیهی هر دو قسمت برنامههای وب، تنها با یک زبان میسر میشد. با استفاده از Blazor، این آرزو میسر شدهاست.
با استفاده از Blazor میتوان کدهای تعاملی UI را بجای استفاده از زبان جاوا اسکریپت، با کمک زبان #C تهیه کرد. به این ترتیب با استفاده از یک زبان میتوان کدهای سمت سرور و سمت کلاینت را پیاده سازی کرد. البته شاید این سؤال مطرح شود که مرورگرها تنها قادر به درک کدهای HTML و جاوا اسکریپت هستند و نه #C، بنابراین چگونه میتوان از زبان #C در مرورگرها نیز استفاده کرد؟ پاسخ به آن، به فناوری جدید «وب اسمبلی» بر میگردد. Blazor با استفاده از «وب اسمبلی» است که میتواند کدهای #C را درون مرورگر اجرا کند.
حالتهای مختلف هاست و ارائهی برنامههای مبتنی بر Blazor
برنامههای مبتنی بر Blazor، به دو روش مختلف قابل ارائه هستند:
الف) Blazor Server
Blazor Server، در اساس یک برنامهی استاندارد ASP.NET Core است که در آن تمام قابلیتهای سمت سرور، مانند کار با EF-Core، میسر است و امکان دسترسی به این امکانات به صورت یکپارچهای در سراسر برنامه وجود دارد. در این حالت، کامپوننتهای Blazor، بجای اجرای بر روی مرورگر کاربر، در سمت سرور اجرا میشوند. این تعاملات و به روز رسانیهای UI، توسط یک اتصال دائم SignalR مدیریت میشوند.
همانطور که مشاهده میکنید، در حالت هاست سمت سرور، همه چیز، منجمله کامپوننتهای Blazor، در همان سمت سرور قرار دارند و این اتصال پشت صحنهی SignalR است که کار تبادل اطلاعات ارسالی و رندر شده را بر عهده میگیرد.
ب) Blazor web assembly
در این حالت با استفاده از فناوری جدید «وب اسمبلی»، تمام کدهای یک برنامهی مبتنی بر Blazor به کمک NET Runtime.، داخل مرورگر اجرا میشود. به Blazor web assembly باید همانند فریمورکهای SPA (تک صفحهای وب)، مانند Angular و React نگاه کرد؛ با یک تفاوت مهم: در اینجا بجای استفاده از جاو اسکریپت برای نوشتن برنامهی SPA، از #C استفاده میشود. اگر به تصویر فوق دقت کنید، در حالت اجرای برنامههای Blazor web assembly، تنها به مرورگر کاربر نیاز است و همه چیز داخل آن قرار میگیرد. در اینجا دیگر خبری از یک اتصال دائم SignalR با سرور وجود ندارد.
البته باید دقت داشت که از فناوری وب اسمبلی، در تمام مرورگرهای جدید پشتیبانی میشود؛ منهای IE 11. در این حالت مرورگر کل برنامهی Blazor را دریافت میکند (همانند دریافت کل کدهای یک برنامهی Angular و یا React) و بدون استفاده از رندر سمت سرور حالت الف، قابلیت تعامل با کاربر را دارد.
بدیهی است با توجه به اینکه Blazor web assembly مستقیما داخل مرورگر اجرا میشود، دیگر همانند حالت الف، امکان دسترسی مستقیم به فناوریها و امکانات سمت سرور، مانند کار مستقیم با EF-Core را نخواهد داشت. برای این منظور دقیقا همانند روش کار با سایر فریم ورکهای SPA، نیاز به تهیهی یک ASP.NET Core Web API جهت تعامل با سرور خواهد بود.
مزایا و معایب حالتهای مختلف هاست برنامههای Blazor
الف) Blazor Server
مزایا:
- حجم دریافتی توسط مرورگر در این حالت بسیار کم است.
- امکان دسترسی به تمام امکانات سمت سرور را دارد؛ مانند تمام کتابخانههای سمت سرور و همچنین امکان دیباگ آن نیز همانند سایر برنامههای سمت سرور است.
- بر روی مرورگرهای قدیمی نیز قابل اجرا است؛ چون بدون نیاز به فناوری جدید «وب اسمبلی» کار میکند.
معایب:
- رندر شدن UI آن نسبت به حالت ب، کندتر است. از این جهت که تمام تعاملات UI آن، توسط اتصال SignalR به سمت سرور ارسال شده و سپس نتیجهی نهایی رندر شده، به سمت کلاینت بازگشت داده میشود.
- پشتیبانی از اجرای offline آن وجود ندارد. اگر اتصال SignalR موجود قطع شود، دیگر نمیتوان از برنامه استفاده کرد.
- با توجه به نیاز به استفادهی از یک اتصال دائم SignalR به ازای هر کاربر، مقیاس پذیری این نوع برنامهها کمتر است. البته اگر تعداد کاربران برنامههای شما در یک شبکهی اینترانت داخلی شرکتی محدود است، این مورد مشکل خاصی نخواهد بود. از دیدگاهی دیگر اگر تعداد کاربران برنامهی شما بسیار زیاد است، استفاده از Blazor Server توصیه نمیشود. البته باید دقت داشت که سروری با 4GB RAM، میتواند 5000 کاربر همزمان SignalR را مدیریت کند.
ب) Blazor web assembly یا به اختصار Blazor WASM
مزایا:
- هیچ نوع وابستگی به سمت سرور ندارد. همینقدر که برنامه توسط مرورگر دریافت شد، قابل اجر است.
- برای هاست آن الزاما نیازی به یک سرور IIS و یا یک وب سرور ASP.NET Core نیست.
- امکان ارائهی آن توسط یک CDN نیز وجود دارد.
- چون در این حالت کل برنامه توسط مرورگر دریافت میشود، قابلیت اجرای آفلاین را نیز پیدا میکند.
- برای کار، نیازی به اتصال دائم SignalR را ندارد؛ به همین جهت مقیاس پذیری آن بیشتر است.
معایب:
- حتما نیاز به استفادهی از مرورگرهای جدید با پشتیبانی از web assembly را دارد؛ برای مثال نیاز به کروم نگارش 57 به بعد و فایرفاکس نگارش 52 به بعد را دارد و بر روی IE اجرا نمیشود.
- چون کل برنامه در این حالت توسط مرورگر دریافت میشود، حجم ابتدایی دریافت آن کمی بالا است.
- میدان دید و عملکرد آن همانند سایر برنامههای SPA، محدود است به امکاناتی که مرورگر، در اختیار برنامه قرار میدهد.
ایجاد پروژههای خالی Blazor Server و Blazor web assembly
یا میتوانید از ویژوال استودیوی کامل و منوی افزودن پروژهی آن برای اینکار استفاده کنید و یا اگر به خروجی دستور dotnet new --list مراجعه کنیم، SDK دات نت 5، به همراه دو قالب مرتبط زیر نیز هست:
C:\Users\Vahid>dotnet new --list Templates Short Name Language Tags -------------------------------------------- ------------------- ------------ ---------------------- Blazor Server App blazorserver [C#] Web/Blazor Blazor WebAssembly App blazorwasm [C#] Web/Blazor/WebAssembly
در قسمت بعد، این دو پروژهی خالی فوق را ایجاد کرده و ساختار آنها را بررسی میکنیم. همچنین نکاتی را هم که در این قسمت در مورد نحوهی هاست این برنامهها عنوان شد، بر روی این پروژهها مشاهده خواهیم کرد.
Blazor Server
Blazor WASM
Blazor WASM
ASP.NET Core 8x به همراه یک IResult جدید بهنام RazorComponentResult است که توسط آن میتوان در Endpointهای Minimal-API و همچنین اکشن متدهای MVC، از کامپوننتهای Blazor، خروجی گرفت. این خروجی نه فقط static یا به عبارتی SSR، بلکه حتی میتواند تعاملی هم باشد. در این مطلب، جزئیات فعالسازی و استفاده از این IResult جدید را در یک برنامهی Minimal-API بررسی میکنیم.
ایجاد یک برنامهی Minimal-API جدید در دات نت 8
پروژهای را که در اینجا پیگیری میکنیم، بر اساس قالب استاندارد تولید شدهی توسط دستور dotnet new webapi تکمیل میشود.
ایجاد یک صفحهی Blazor 8x به همراه مسیریابی و دریافت پارامتر
در ادامه قصد داریم که یک کامپوننت جدید را به نام SsrTest.razor در پوشهی جدید Components\Tests ایجاد کرده و برای آن مسیریابی از نوع page@ هم تعریف کنیم. یعنی نهفقط قصد داریم آنرا توسط RazorComponentResult رندر کنیم، بلکه میخواهیم اگر آدرس آنرا در مرورگر هم وارد کردیم، قابل دسترسی باشد.
به همین جهت یک پوشهی جدید را به نام Components در ریشهی پروژهی Web API جاری ایجاد میکنیم، با این محتوا:
برای ایده گرفتن از محتوای مورد نیاز، به «معرفی قالبهای جدید شروع پروژههای Blazor در دات نت 8» قسمت دوم این سری مراجعه کرده و برای مثال قالب سادهترین حالت ممکن را توسط دستور زیر تولید میکنیم (در یک پروژهی مجزا، خارج از پروژهی جاری):
پس از اینکار، محتویات پوشهی Components آنرا مستقیما داخل پوشهی پروژهی Minimal-API جاری کپی میکنیم. یعنی در نهایت در این پروژهی جدید Web API، به فایلهای زیر میرسیم:
- فایل Imports.razor_ ساده شده برای سهولت کار با فضاهای نام در کامپوننتهای Blazor (فضاهای نامی را که در آن وجود ندارند و مرتبط با پروژهی دوم هستند، حذف میکنیم).
- فایل App.razor، برای تشکیل نقطهی آغازین برنامهی Blazor.
- فایل Routes.razor برای معرفی مسیریابی صفحات Blazor تعریف شده.
- پوشهی Layout برای معرفی فایل MainLayout.razor که در Routes.razor استفاده شدهاست.
و ... یک فایل آزمایشی جدید به نام Components\Tests\SsrTest.razor با محتوای زیر:
این فایل، میتواند پارامتر Data را از طریق فراخوانی مستقیم آدرس فرضی http://localhost:5227/ssr-page/2 دریافت کند و یا ... از طریق خروجی جدید RazorComponentResult که توسط یک Endpoint سفارشی ارائه میشود:
تغییرات مورد نیاز در فایل Program.cs برنامهی Web-API برای فعالسازی رندر سمت سرور Blazor
در ادامه کل تغییرات مورد نیاز جهت اجرای این برنامه را مشاهده میکنید:
توضیحات:
- همین اندازه تغییر در جهت فعالسازی رندر سمت سرور کامپوننتهای Blazor در یک برنامهی ASP.NET Core کفایت میکند. یعنی اضافه شدن:
AddRazorComponents ،UseAntiforgery و MapRazorComponents
- در اینجا نحوهی ارسال پارامترها را به یک RazorComponentResult نیز مشاهده میکنید.
- در حالت فراخوانی از طریق مسیر endpoint (یعنی فراخوانی مسیر http://localhost:5227/ssr-component در مثال فوق)، خود کامپوننت فراخوانی شده، بدون layout تعریف شدهی در فایل App.razor، رندر میشود. علت اینجا است که layout برنامه به همراه کامپوننت Router و RouteView آن فعال میشود که این دو هم مختص به صفحات دارای مسیریابی Blazor هستند و برای رندر کامپوننتهای خالص آن بکار گرفته نمیشوند. خروجی RazorComponentResult تنها یک static SSR خالص است؛ مگر اینکه فایل blazor.web.js را نیز بارگذاری کند.
یک نکته: اگر در حالت رندر توسط RazorComponentResult، علاقمند به استفادهی از layout هستید، میتوان از کامپوننت LayoutView داخل یک کامپوننت فرضی به صورت زیر استفاده کرد؛ اما این مورد هم شامل اطلاعات فایل App.razor نمیشود:
سؤال: آیا در این حالت کامپوننتهای تعاملی هم کار میکنند؟
پاسخ: بله. فقط برای ایده گرفتن، یک نمونه پروژهی تعاملی Blazor 8x را در ابتدا ایجاد کنید و قسمتهای اضافی AddRazorComponents و MapRazorComponents آنرا در اینجا کپی کنید؛ یعنی برای مثال جهت فعالسازی کامپوننتهای تعاملی Blazor Server، به این دو تغییر زیر نیاز است:
همچنین باید دقت داشت که امکانات تعاملی، به دلیل وجود و دسترسی به یک سطر ذیل که در فایل Components\App.razor واقع شده، اجرایی میشوند:
و همانطور که عنوان شد، اگر از روش new RazorComponentResult استفاده میشود، باید این سطر را به صورت دستی اضافهکرد؛ چون به همراه رندر layout تعریف شدهی در فایل App.razor نیست. برای مثال فرض کنید کامپوننت معروف Counter را به صورت زیر داریم که حالت رندر آن به InteractiveServer تنظیم شدهاست:
در این حالت پس از تعریف endpoint زیر، خروجی آن فقط یک صفحهی استاتیک SSR خواهد بود و دکمهی Click me آن کار نمیکند:
علت اینجا است که اگر به سورس HTML رندر شده مراجعه کنیم، خبری از درج اسکریپت blazor.web.js در انتهای آن نیست. به همین جهت برای مثال فایل جدید CounterInteractive.razor را به صورت زیر اضافه میکنیم که ساختار آن شبیه به فایل App.razor است:
و هدف اصلی از آن، تشکیل یک قالب و درج اسکریپت blazor.web.js در انتهای آن است.
سپس تعریف endpoint متناظر را به صورت زیر تغییر میدهیم:
اینبار به علت بارگذاری فایل blazor.web.js، امکانات تعاملی کامپوننت Counter فعال شده و قابل استفاده میشوند.
سؤال: آیا میتوان این خروجی static SSR کامپوننتهای بلیزر را در سرویسهای یک برنامه ASP.NET Core هم دریافت کرد؟
منظور این است که آیا میتوان از یک کامپوننت Blazor، به همراه تمام پیشرفتهای Razor در آن که در Viewهای MVC قابل دسترسی نیستند، بهشکل یک رشتهی خالص، خروجی گرفت و برای مثال از آن بهعنوان قالب پویای محتوای ایمیلها استفاده کرد؟
پاسخ: بله! زیر ساخت RazorComponentResult که از سرویس HtmlRenderer استفاده میکند، بدون نیاز به برپایی یک endpoint هم قابل دسترسی است:
برای کار با آن، ابتدا باید سرویس فوق را به صورت زیر ثبت و معرفی کرد:
و سپس یک نمونه مثال فرضی نحوهی تزریق و فراخوانی سرویس BlazorStaticRendererService به صورت زیر است که در آن روش ارسال پارامترها هم بررسی شدهاست:
کدهای کامل این مطلب را میتوانید از اینجا دریافت کنید: WebApi8x.zip
ایجاد یک برنامهی Minimal-API جدید در دات نت 8
پروژهای را که در اینجا پیگیری میکنیم، بر اساس قالب استاندارد تولید شدهی توسط دستور dotnet new webapi تکمیل میشود.
ایجاد یک صفحهی Blazor 8x به همراه مسیریابی و دریافت پارامتر
در ادامه قصد داریم که یک کامپوننت جدید را به نام SsrTest.razor در پوشهی جدید Components\Tests ایجاد کرده و برای آن مسیریابی از نوع page@ هم تعریف کنیم. یعنی نهفقط قصد داریم آنرا توسط RazorComponentResult رندر کنیم، بلکه میخواهیم اگر آدرس آنرا در مرورگر هم وارد کردیم، قابل دسترسی باشد.
به همین جهت یک پوشهی جدید را به نام Components در ریشهی پروژهی Web API جاری ایجاد میکنیم، با این محتوا:
برای ایده گرفتن از محتوای مورد نیاز، به «معرفی قالبهای جدید شروع پروژههای Blazor در دات نت 8» قسمت دوم این سری مراجعه کرده و برای مثال قالب سادهترین حالت ممکن را توسط دستور زیر تولید میکنیم (در یک پروژهی مجزا، خارج از پروژهی جاری):
dotnet new blazor --interactivity None
- فایل Imports.razor_ ساده شده برای سهولت کار با فضاهای نام در کامپوننتهای Blazor (فضاهای نامی را که در آن وجود ندارند و مرتبط با پروژهی دوم هستند، حذف میکنیم).
- فایل App.razor، برای تشکیل نقطهی آغازین برنامهی Blazor.
- فایل Routes.razor برای معرفی مسیریابی صفحات Blazor تعریف شده.
- پوشهی Layout برای معرفی فایل MainLayout.razor که در Routes.razor استفاده شدهاست.
و ... یک فایل آزمایشی جدید به نام Components\Tests\SsrTest.razor با محتوای زیر:
@page "/ssr-page/{Data:int}" <PageTitle>An SSR component</PageTitle> <h1>An SSR component rendered by a Minimal-API!</h1> <div> Data: @Data </div> @code { [Parameter] public int Data { get; set; } }
تغییرات مورد نیاز در فایل Program.cs برنامهی Web-API برای فعالسازی رندر سمت سرور Blazor
در ادامه کل تغییرات مورد نیاز جهت اجرای این برنامه را مشاهده میکنید:
var builder = WebApplication.CreateBuilder(args); // ... builder.Services.AddRazorComponents(); // ... // http://localhost:5227/ssr-component?data=2 // or it can be called directly http://localhost:5227/ssr-page/2 app.MapGet("/ssr-component", (int data = 1) => { var parameters = new Dictionary<string, object?> { { nameof(SsrTest.Data), data }, }; return new RazorComponentResult<SsrTest>(parameters); }); app.UseStaticFiles(); app.UseAntiforgery(); app.MapRazorComponents<App>(); app.Run(); // ...
- همین اندازه تغییر در جهت فعالسازی رندر سمت سرور کامپوننتهای Blazor در یک برنامهی ASP.NET Core کفایت میکند. یعنی اضافه شدن:
AddRazorComponents ،UseAntiforgery و MapRazorComponents
- در اینجا نحوهی ارسال پارامترها را به یک RazorComponentResult نیز مشاهده میکنید.
- در حالت فراخوانی از طریق مسیر endpoint (یعنی فراخوانی مسیر http://localhost:5227/ssr-component در مثال فوق)، خود کامپوننت فراخوانی شده، بدون layout تعریف شدهی در فایل App.razor، رندر میشود. علت اینجا است که layout برنامه به همراه کامپوننت Router و RouteView آن فعال میشود که این دو هم مختص به صفحات دارای مسیریابی Blazor هستند و برای رندر کامپوننتهای خالص آن بکار گرفته نمیشوند. خروجی RazorComponentResult تنها یک static SSR خالص است؛ مگر اینکه فایل blazor.web.js را نیز بارگذاری کند.
یک نکته: اگر در حالت رندر توسط RazorComponentResult، علاقمند به استفادهی از layout هستید، میتوان از کامپوننت LayoutView داخل یک کامپوننت فرضی به صورت زیر استفاده کرد؛ اما این مورد هم شامل اطلاعات فایل App.razor نمیشود:
<LayoutView Layout="@typeof(MainLayout)"> <PageTitle>Home</PageTitle> <h2>Welcome to your new app.</h2> </LayoutView>
سؤال: آیا در این حالت کامپوننتهای تعاملی هم کار میکنند؟
پاسخ: بله. فقط برای ایده گرفتن، یک نمونه پروژهی تعاملی Blazor 8x را در ابتدا ایجاد کنید و قسمتهای اضافی AddRazorComponents و MapRazorComponents آنرا در اینجا کپی کنید؛ یعنی برای مثال جهت فعالسازی کامپوننتهای تعاملی Blazor Server، به این دو تغییر زیر نیاز است:
// ... builder.Services.AddRazorComponents() .AddInteractiveServerComponents(); // ... app.MapRazorComponents<App>().AddInteractiveServerRenderMode(); // ...
<script src="_framework/blazor.web.js"></script>
@rendermode InteractiveServer <h1>Counter</h1> <p role="status">Current count: @_currentCount</p> <button class="btn btn-primary" @onclick="IncrementCount">Click me</button> @code { private int _currentCount; private void IncrementCount() { _currentCount++; } }
// http://localhost:5227/server-interactive-component app.MapGet("/server-interactive-component", () => new RazorComponentResult<Counter>());
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Interactive server component</title> <base href="/"/> </head> <body> <h1>Interactive server component</h1> <Counter/> <script src="_framework/blazor.web.js"></script> </body> </html>
سپس تعریف endpoint متناظر را به صورت زیر تغییر میدهیم:
// http://localhost:5227/server-interactive-component app.MapGet("/server-interactive-component", () => new RazorComponentResult<CounterInteractive>());
سؤال: آیا میتوان این خروجی static SSR کامپوننتهای بلیزر را در سرویسهای یک برنامه ASP.NET Core هم دریافت کرد؟
منظور این است که آیا میتوان از یک کامپوننت Blazor، به همراه تمام پیشرفتهای Razor در آن که در Viewهای MVC قابل دسترسی نیستند، بهشکل یک رشتهی خالص، خروجی گرفت و برای مثال از آن بهعنوان قالب پویای محتوای ایمیلها استفاده کرد؟
پاسخ: بله! زیر ساخت RazorComponentResult که از سرویس HtmlRenderer استفاده میکند، بدون نیاز به برپایی یک endpoint هم قابل دسترسی است:
using Microsoft.AspNetCore.Components; using Microsoft.AspNetCore.Components.Web; namespace WebApi8x.Services; public class BlazorStaticRendererService { private readonly HtmlRenderer _htmlRenderer; public BlazorStaticRendererService(HtmlRenderer htmlRenderer) => _htmlRenderer = htmlRenderer; public Task<string> StaticRenderComponentAsync<T>() where T : IComponent => RenderComponentAsync<T>(ParameterView.Empty); public Task<string> StaticRenderComponentAsync<T>(Dictionary<string, object?> dictionary) where T : IComponent => RenderComponentAsync<T>(ParameterView.FromDictionary(dictionary)); private Task<string> RenderComponentAsync<T>(ParameterView parameters) where T : IComponent => _htmlRenderer.Dispatcher.InvokeAsync(async () => { var output = await _htmlRenderer.RenderComponentAsync<T>(parameters); return output.ToHtmlString(); }); }
builder.Services.AddScoped<HtmlRenderer>(); builder.Services.AddScoped<BlazorStaticRendererService>();
app.MapGet("/static-renderer-service-test", async (BlazorStaticRendererService renderer, int data = 1) => { var parameters = new Dictionary<string, object?> { { nameof(SsrTest.Data), data }, }; var html = await renderer.StaticRenderComponentAsync<SsrTest>(parameters); return Results.Content(html, "text/html"); });
کدهای کامل این مطلب را میتوانید از اینجا دریافت کنید: WebApi8x.zip
⭐️ Course Contents ⭐️
Section 1: Introduction
Section 2: Blazor Files and Folders
Section 3: Blazor - Data and Property Binding
Section 4: Blazor - Shared Components and Event Binding
Section 5: Blazor - Render Fragment, Attribute Splatting and Routing
Section 6: Blazor - JavaScript
Section 7: Blazor Lifecycle
Section 8: Model and Repository
Section 9: Category CRUD
Section 10: Delete Component
نظرات مطالب
معرفی Blazor Hybrid
سلام عرض شد یک سوال داشتم ، الان net maui Blazor app که در نسخه پیش نمایش Visual studio 2022 وجود داره همون Blazor Native Mobile Apps است که در متن بالا شما بهش اشاره کردید؟
جهت به اشتراک گذاشتن کامپوننتهای سفارشی Blazor در پروژههای مختلف، امکان بسته بندی آنها به صورت کتابخانههای کامپوننتها نیز پیشبینی شدهاست که میتوانند به همراه فایلهای CSS ،JS و تصاویر هم باشند.
روش ایجاد یک پروژهی کتابخانهای، از کامپوننتهای Blazor
اگر از ویژوال استودیو استفاده میکنید، نوع «Razor Class Library»، پروژههای مخصوص کتابخانههای کامپوننتهای Blazor را آغاز میکند و اگر میخواهید از CLI استفاده کنید، باید از دستور «dotnet new razorclasslib» استفاده کرد؛ که قابلیت تبدیل به بستههای نیوگت را با دستور dotnet pack داشته و به این ترتیب میتوان آنها را به اشتراک گذاشت و یا حتی میتوان ارجاعی از این پروژه را در سایر پروژههای شخصی، مورد استفاده قرار داد.
ساختار پیشفرض فایل csproj اینگونه پروژهها به صورت زیر است:
روش افزودن فایلهای ثابت مورد استفادهی در کتابخانه
پروژهی پیشفرضی که در اینجا ایجاد میشود، به همراه یک پوشهی wwwroot نیز هست. این پوشه محلی است که باید فایلهای ثابت اشتراکی پروژه را مانند فایلهای CSS و JS مورد استفاده، قرار داد.
این نوع پروژهها از ویژگی Isolated CSS و یا Isolated JS ارائه شدهی در Blazor 5x نیز پشتیبانی میکنند.
روش استفادهی از فایلهای ثابت موجود در یک کتابخانه
این فایلهای ثابت به همراه بستهی نهایی پروژه، به صورت خودکار توزیع میشوند (و نیازی به ارائهی مجزای آنها نیست) و برای استفادهی از آنها در پروژههای دیگر، باید از روش مسیردهی زیر استفاده کرد:
- content_ مسیر آغاز کنندهی دسترسی به منابع یک کتابخانهی کامپوننتهای Blazor است.
- PackageId عموما همان نام پروژهی مورد استفادهاست (نام فایل csproj مانند MyBlazorComponentLibrary). هرچند میتوان آنرا به صورت مجزایی در فایل csproj نیز مقدار دهی کرد.
- در این مثال MyImage.png، نام منبعی است که قرار است از آن استفاده کنیم و پیشتر در پوشهی wwwroot کتابخانه، کپی شدهاست و یا حتی میتوان زیر پوشههایی را نیز در اینجا ایجاد و از آنها استفاده کرد؛ مانند:
همچنین باید دقت داشت که مداخل فایلهای اسکریپتی کتابخانه را مانند:
در برنامههای Blazor WASM باید به فایل wwwroot/index.html و در برنامههای Blazor Server به فایل Pages/_Host.cshtml افزود و این مداخل باید پیش از یکی از فایلهای framework/blazor.server.js_ و یا framework/blazor.webassembly.js_ تعریف شوند.
روش استفادهی از کتابخانهی نهایی تولید شده
برای استفادهی از کتابخانهی نهایی تولید شده یا میتوان ارجاعی را به فایل csproj آن، به پروژهی خود افزود:
و یا میتوان بستهی نیوگت آنرا (در صورت وجود) نصب کرد.
پس از آن، جهت سهولت استفادهی از این کامپوننتهای اشتراکی، بهتر است فضای نام آنها را به فایل Imports.razor_ پروژهی خود افزود؛ تا نیازی به تعریف آنها در تمام کامپوننتهای مورد استفاده نباشد.
روش ایجاد یک پروژهی کتابخانهای، از کامپوننتهای Blazor
اگر از ویژوال استودیو استفاده میکنید، نوع «Razor Class Library»، پروژههای مخصوص کتابخانههای کامپوننتهای Blazor را آغاز میکند و اگر میخواهید از CLI استفاده کنید، باید از دستور «dotnet new razorclasslib» استفاده کرد؛ که قابلیت تبدیل به بستههای نیوگت را با دستور dotnet pack داشته و به این ترتیب میتوان آنها را به اشتراک گذاشت و یا حتی میتوان ارجاعی از این پروژه را در سایر پروژههای شخصی، مورد استفاده قرار داد.
ساختار پیشفرض فایل csproj اینگونه پروژهها به صورت زیر است:
<Project Sdk="Microsoft.NET.Sdk.Razor"> <PropertyGroup> <TargetFramework>net5.0</TargetFramework> </PropertyGroup> <ItemGroup> <SupportedPlatform Include="browser" /> </ItemGroup> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Components.Web" Version="5.0.6" /> </ItemGroup> </Project>
روش افزودن فایلهای ثابت مورد استفادهی در کتابخانه
پروژهی پیشفرضی که در اینجا ایجاد میشود، به همراه یک پوشهی wwwroot نیز هست. این پوشه محلی است که باید فایلهای ثابت اشتراکی پروژه را مانند فایلهای CSS و JS مورد استفاده، قرار داد.
این نوع پروژهها از ویژگی Isolated CSS و یا Isolated JS ارائه شدهی در Blazor 5x نیز پشتیبانی میکنند.
روش استفادهی از فایلهای ثابت موجود در یک کتابخانه
این فایلهای ثابت به همراه بستهی نهایی پروژه، به صورت خودکار توزیع میشوند (و نیازی به ارائهی مجزای آنها نیست) و برای استفادهی از آنها در پروژههای دیگر، باید از روش مسیردهی زیر استفاده کرد:
/_content/PackageId/MyImage.png
- PackageId عموما همان نام پروژهی مورد استفادهاست (نام فایل csproj مانند MyBlazorComponentLibrary). هرچند میتوان آنرا به صورت مجزایی در فایل csproj نیز مقدار دهی کرد.
- در این مثال MyImage.png، نام منبعی است که قرار است از آن استفاده کنیم و پیشتر در پوشهی wwwroot کتابخانه، کپی شدهاست و یا حتی میتوان زیر پوشههایی را نیز در اینجا ایجاد و از آنها استفاده کرد؛ مانند:
/_content/MyBlazorComponentLibrary/scripts/HelloWorld.js
<script src="_content/MyBlazorComponentLibrary/exampleJsInterop.js"></script>
روش استفادهی از کتابخانهی نهایی تولید شده
برای استفادهی از کتابخانهی نهایی تولید شده یا میتوان ارجاعی را به فایل csproj آن، به پروژهی خود افزود:
<ItemGroup> <ProjectReference Include="..\MyBlazorComponentLibrary\MyBlazorComponentLibrary.csproj" /> </ItemGroup>
پس از آن، جهت سهولت استفادهی از این کامپوننتهای اشتراکی، بهتر است فضای نام آنها را به فایل Imports.razor_ پروژهی خود افزود؛ تا نیازی به تعریف آنها در تمام کامپوننتهای مورد استفاده نباشد.
Here’s what’s new in this preview release:
- Razor compiler updated to use source generators
- Support for custom event arguments in Blazor
- CSS isolation for MVC Views and Razor Pages
- Infer component generic types from ancestor components
- Preserve prerendered state in Blazor apps
- SignalR – Nullable annotations