Blazor من الصفر: الفصل الأول — ما هو Blazor؟

مرحباً بك في الفصل الأول من سلسلة Blazor من الصفر. إذا فاتك منشور المقدمة حيث شرحت الغرض من هذه السلسلة والجمهور المستهدف، ابدأ بقراءته أولاً — فهو قصير.

في هذا الفصل سنجيب على السؤال الجوهري: ما هو Blazor؟ يبدو هذا بسيطاً، لكن الإجابة ذات طبقات متعددة — لا سيما أن “Blazor” اكتسب معاني متباينة قليلاً عبر السنوات. بنهاية هذا المنشور ستعرف ما هو Blazor، وكيف يندرج ضمن منظومة .NET، وما هي نماذج التصيير المختلفة، ولماذا قد تختاره بدلاً من إطار عمل JavaScript — أو لا تختاره.

نبذة تاريخية مختصرة

بدأ Blazor كمشروع تجريبي لـ Steve Sanderson في Microsoft حوالي عام 2017. كانت الفكرة استفزازية: تشغيل C# في المتصفح باستخدام WebAssembly، مما يُلغي الحاجة إلى JavaScript كلياً. كان ذلك دليلاً على المفهوم، والاسم كان مزجاً مقصوداً بين Blazer وRazor — محرك القوالب الذي بُني عليه Blazor في نهاية المطاف.

أثار التجربةُ حماساً كافياً جعل Microsoft تأخذها بجدية. شُحن Blazor كجزء من ASP.NET Core 3.0 في سبتمبر 2019 — أولاً كـ Blazor Server: نموذج يُشغّل كود C# على الخادم ويستخدم اتصال SignalR في الوقت الحقيقي لإرسال تحديثات واجهة المستخدم إلى المتصفح. تبعه Blazor WebAssembly كجزء من ASP.NET Core 3.1 في مايو 2020، مُجلِباً تنفيذاً حقيقياً على جانب العميل للإطار.

صقّل .NET 6 و7 تجربة المطورين. ثم جاء .NET 8، الذي صدر في نوفمبر 2023، ليُعيد التفكير جذرياً في نموذج التصيير بما أسمته Microsoft واجهة مستخدم ويب متكاملة. باتت التصيير الثابت من جانب الخادم، والتصيير المتدفق، والخادم التفاعلي، وWebAssembly التفاعلي، ووضع Auto الجديد تتعايش جميعها تحت سقف واحد في مشروع واحد. أسهم .NET 9 في البناء على هذا الأساس وتصحيح العقبات.

هذا هو المكان الذي نقف فيه اليوم.

ما هو Blazor فعلاً

في جوهره، Blazor هو إطار عمل لواجهة المستخدم مبني على المكونات لـ .NET. تبني واجهتك من مكونات — وحدات مستقلة من C# وترميز HTML قادرة على الاحتفاظ بالحالة والاستجابة للأحداث وتأليف هياكل أكبر. إذا عملت مع React أو Vue فسيبدو هذا النموذج الذهني مألوفاً. الفارق الرئيسي أنك تكتب C# بدلاً من JavaScript.

تُكتب المكونات في Blazor في ملفات .razor. يمزج ملف .razor بين ترميز HTML وكود C# باستخدام صيغة Razor التي ربما تعرفها من عروض ASP.NET MVC. هكذا يبدو مكوّن بسيط:

@page "/counter"

<h1>عدّاد</h1>
<p>العدد الحالي: @currentCount</p>
<button @onclick="IncrementCount">انقر هنا</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

لا أثر لـ JavaScript. يربط توجيه @onclick النقر على الزر بطريقة C#. يُصيّر التعبير @currentCount القيمة الحالية. حين تتغير الحالة يُحدد Blazor ما يجب تحديثه في DOM.

هذا هو الجوهر. كل ما سواه — التوجيه، وحقن التبعيات، والنماذج، واستدعاءات HTTP — مبني فوق نموذج المكونات هذا.

نماذج التصيير

هنا يتمركز كثير من الالتباس، فلنكن دقيقين. “Blazor” اليوم يُشير إلى عائلة من أوضاع التصيير، لا إلى نموذج نشر وحيد. فهم الفارق مهم لأنه يؤثر في الأداء ومتطلبات البنية التحتية وما يستطيع مكوناتك وما لا تستطيع فعله.

SSR الثابت

أبسط الأوضاع. تُصيَّر مكونات Razor على الخادم إلى HTML ويُرسل ذلك HTML إلى المتصفح. لا اتصال دائم، لا WebAssembly، ولا تفاعلية من جانب العميل افتراضياً. هذا جوهرياً ما تفعله Razor Pages، لكن باستخدام نموذج المكونات.

استخدمه للصفحات الغنية بالمحتوى، وصفحات الهبوط، وكل ما لا يحتاج إلى تفاعلية حية.

الخادم التفاعلي

يعمل كود المكون على الخادم. تُقام اتصال WebSocket عبر SignalR بين المتصفح والخادم. حين تنقر على زر أو تكتب في حقل إدخال، ينتقل الحدث عبر WebSocket إلى الخادم، يُنفَّذ كود C#، يُحسب الفرق، وتُرسل تحديثات DOM إلى المتصفح.

المزايا: وصول كامل لموارد الخادم (قواعد البيانات، نظام الملفات، الأسرار). تحميل أولي سريع. حجم تنزيل صغير. يعمل في متصفحات بلا دعم لـ WebAssembly.

العيوب: كل تفاعل مستخدم يستلزم رحلة ذهاباً وإياباً للخادم، مما يضيف زمن استجابة. تتوسع موارد الخادم مع عدد الاتصالات النشطة. تتدهور التطبيق عند انقطاع الاتصال.

استخدمه لتطبيقات الأعمال والأدوات الداخلية والتطبيقات التي يُقدَّم فيها الوصول للبيانات على الخادم على حساب قدرة العمل دون اتصال.

WebAssembly التفاعلي

يُنزَّل وقت تشغيل .NET إلى المتصفح ويعمل تطبيقك بالكامل على جانب العميل. بعد التنزيل الأولي يعمل التطبيق بشكل كامل دون اتصال وكل تفاعل فوري — لا رحلات للخادم لمنطق الواجهة.

المزايا: تنفيذ حقيقي من جانب العميل. يعمل دون اتصال. تقليل الحمل على الخادم بعد تحميل التطبيق.

العيوب: تنزيل أولي أكبر (وقت تشغيل .NET + تطبيقك). تحميل أبطأ عند أول زيارة. تحتاج إلى API للوصول إلى البيانات من جانب الخادم.

استخدمه للتطبيقات القادرة على العمل دون اتصال، والأدوات التي تحتاج استجابة فورية، والسيناريوهات التي لا تحتاج فيها الواجهة لمعالجة من الخادم.

وضع Auto

مُقدَّم في .NET 8. يبدأ التطبيق في وضع الخادم التفاعلي (تحميل أولي سريع، دون انتظار تنزيل WebAssembly). بمجرد تنزيل ملفات WebAssembly في الخلفية تتحول الزيارات اللاحقة تلقائياً إلى وضع WebAssembly.

يمنحك هذا التحميل الأولي السريع لوضع الخادم والتنفيذ الكامل من جانب العميل لـ WebAssembly في نهاية المطاف. إنه أكثر النماذج تعقيداً في الاستيعاب، لكنه قيمة افتراضية عملية لكثير من التطبيقات.

مزج الأوضاع في التطبيق الواحد

في .NET 8 وما بعده لست مُقيَّداً بوضع تصيير واحد لكامل التطبيق. يمكن أن تكون صفحة الهبوط التسويقية SSR ثابتاً؛ ولوحة التحكم المُصادَق عليها خادماً تفاعلياً؛ وأداة تصور البيانات WebAssembly تفاعلياً. يتولى الإطار إدارة الانتقالات.

في هذه السلسلة سنبدأ بالخادم التفاعلي لأنه الأسهل تشغيلاً ويتميز بنموذج ذهني أكثر مباشرة. سنستكشف الأوضاع الأخرى مع التقدم.

كيف يقارن Blazor بأطر عمل JavaScript

إذا بنيت مع React أو Angular أو Vue فهذه على الأرجح المقارنة التي تستفسر عنها.

أوجه الشبه حقيقية. نموذج مكونات Blazor مشابه عمداً لـ React. لديك props (Parameters في Blazor)، وحالة محلية (حقول في كتلة @code)، وخطافات دورة الحياة، ونمط الاتصال ذاته: البيانات للأسفل والأحداث للأعلى. إذا عرفت React ستشعر بالألفة في غضون ساعات.

الفارق الرئيسي هو اللغة. في Blazor تكتب C#. يمكن مشاركة منطق الأعمال وقواعد التحقق ونماذج البيانات بين واجهتك في Blazor وخلفيتك في ASP.NET Core. لن تحتاج بعد الآن لتكرار صنف User في TypeScript وهو موجود لديك في C#.

الفجوة في النظام البيئي حقيقية لكنها تضيق. النظام البيئي لـ npm ضخم. النظام البيئي لـ NuGet لمكونات الواجهة أصغر، رغم أنه نما بشكل ملحوظ. إذا احتجت مكتبة رسوم بيانية محددة أو أداة سحب وإفلات فلا يزال JavaScript يوفر خيارات أكثر. لكن لمعظم تطبيقات الأعمال، ما هو متاح في عالم .NET يزيد على الكفاية.

التشغيل البيني مع JavaScript موجود حين تحتاجه. يتيح لك Blazor استدعاء JavaScript من C# وC# من JavaScript. لواجهات برمجة المتصفح التي تفتقر لغلاف .NET، أو حين تريد استخدام مكتبة JS موجودة، فالتشغيل البيني متاح. يُضيف طبقة لكنه ليس مؤلماً.

الإجابة الصادقة: إذا كان فريقك بالكامل من مطوري JavaScript ويبنون منتجاً عاماً يُعدّ فيه SEO والأداء ونظام npm البيئي أموراً جوهرية، التزم بـ JavaScript. إذا كان فريقك من مطوري .NET، أو إذا كنت تبني تطبيقات داخلية أو خاصة بالأعمال، أو إذا كانت مشاركة الكود بين الواجهتين الأمامية والخلفية مهمة لك، فـ Blazor خيار مقنع.

ما تحتاجه للمتابعة

لبقية هذه السلسلة ستحتاج إلى:

• .NET 9 SDK — حمّله من dot.net
• بيئة تطوير — Visual Studio 2022 (الإصدار المجتمعي مجاني)، أو VS Code مع امتداد C# Dev Kit، أو JetBrains Rider
• إلمام أساسي بـ C# — الأصناف والخصائص والواجهات وasync/await

هذا كل شيء. لا Node، لا npm، لا webpack.

الفصل القادم

في الفصل الثاني سننشئ تطبيق Blazor الأول لك، ونستعرض هيكل المشروع، ونتأكد من قدرتك على تشغيله محلياً. ستخرج منه بتطبيق يعمل وصورة واضحة عما يفعله كل ملف.

نلتقي هناك.