Aspnetcore: أعد تسمية مكونات Razor إلى Blazor من جانب الخادم

هل هذا قرار معتمد؟ هل مازلنا نصوت؟

أنا شخصياً ضد تغيير الاسم. أعتقد أن مكونات Razor هي اسم أفضل. :(

xclud إنه منتدى مفتوح ، لذا نرحب دائمًا بالتعليقات 😃

سنظل نشير إلى نموذج المكون على أنه مكونات Razor (على سبيل المثال ، سيظل ملف .razor مكونًا لـ Razor) ، ولكن عند الحديث عن نموذج التطبيق ، نجد أنه من الصعب جدًا أن يكون لدينا أسماء مختلفة. هناك بالفعل قدر كبير من الزخم وراء اسم Blazor لذلك نود التمسك به. الأسماء بالطبع ذاتية - بغض النظر عن الاسم الذي نختاره ، لن يكون الجميع سعداء ، ولكن يبدو أن Blazor قد خدمنا جيدًا حتى الآن.

أعتقد أن هذه خطوة جيدة. لم يكن هناك نهاية للارتباك حول العلاقة بين مكونات Razor و Blazor. لدرجة أن الناس اعتقدوا أنهم أطر عمل مختلفة ، وليس مجرد طرق مختلفة للعرض.

بالإضافة إلى ذلك ، في رأيي الشخصي ، Blazor اسم رائع.

كشخص يتحدث كثيرًا مع الناس حول Blazor. لم تكن مكونات الحلاقة سوى الارتباك. إنه أمر محير من حيث: متى يكون تطبيق Blazor هو تطبيق Razor Components ، و Razor Components من حيث صلته بـ [Razor Pages & Razor Class Libraries] ، والتعثر على الذات عند قول Razor / Blazor. كما أنه يجعل الكتابة عن Blazor أمرًا صعبًا ، كما أنه من الصعب تحسين محركات البحث ، ويمكنني الاستمرار.

يسود العقل! شكرا جزيلا على هذا التغيير.

ماذا حدث مع امتدادات الملفات .razor ، نظرًا لأن صفحات razor لا تزال .cshtml والمكونات هي .razor ، فقد يكون من المفيد تسميتها .blazor؟ أو استدعاء صفحات ماكينة الحلاقة أيضًا .razor بدلاً من .cshtml؟
أشياء محيرة للغاية

نحن نخطط للاحتفاظ بامتداد .razor للمكونات. تستند المكونات إلى بناء جملة Razor ، ولكن يتم التعامل مع المكونات بشكل مختلف بواسطة مترجم Razor ، لذلك فهي بحاجة إلى امتداد ملف مختلف.

ماذا عن قالب Blazor المستضاف؟ بالنسبة لنموذج جانب العميل ، فهي أسهل طريقة لـ:

• تطبيق رؤوس أمان CSP
• حساب تجزئات SRI (من الناحية المثالية ، ستكون هناك حاجة أيضًا للأصول التي يتم تنزيلها مباشرةً بواسطة blazor.webassembly.js)
• ضغط الأصول (على الأقل حتى يتم شحن ملفات dll بنوع محتوى wasm الذي تم ضغطه بالفعل بواسطة زوج من شبكات CDN التي جربتها)

لذلك آمل أن يظل النموذج المستضاف موجودًا.

كما أنني أحب إعادة التسمية هذه إلى "Blazor" فقط. إن التحدث عن أجهزة الصراف الآلي مع الأشخاص حول مكونات Blazor و Razor هو مجرد ارتباك واضح.

Blazor هو علم trchnology مع (على الأقل) نموذجين للاستضافة. لذا ، أنا أحب Blazor!

اسم واحد للحكم عليهم جميعا. One Blazor بنموذجين مختلفين للاستضافة هو بالتأكيد أفضل. إنه يوفر الكثير من الارتباك على الطريق.

أرحب بهذا التغيير! إن التسمية الجديدة (أو القديمة) أقل إرباكًا بكثير مما أشعر به.

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

تعليق قصير: أوافق على تغيير الاسم من _Razor Components_ إلى Blazor من جانب الخادم.

إجابة طويلة: أعتقد أن "المكونات" من جانب العميل والخادم يجب أن يكون لها نفس الاسم ، أيا كان: Blazor ، Razor Components ، ASP.NET Core Components. على سبيل المثال ، تعد React و React Native تقنيات مختلفة كثيرًا ومع ذلك تشتركان في نفس الاسم.

ميزة اسم Blazor:

• إنه بالفعل اسم راسخ في المجتمع. في الواقع ، يُفهم أيضًا على أنها تقنية لتشغيل .NET في متصفح ، وهذا ليس صحيحًا بنسبة 100٪.
• قد يكون من الأسهل على الأشخاص قبول / فهم إمكانية استخدام Blazor بدون .NET على جانب الخادم (في الواقع بدون أي جانب من جانب الخادم).

ميزة اسم مكونات ماكينة الحلاقة:

• قد يساعد الارتباط بـ Razor و ASP.NET Core الأشخاص على فهم أن التكنولوجيا ستحصل على دعم واستقرار مناسبين. على الرغم من أن Blazor قد حصل بالفعل على الكثير من الاهتمام ، أعتقد أنه يُفهم على أنه تقنية مستقرة.

وفيما يتعلق بالتمديد ، فإنه يعتمد على كيفية تمديد تجميع Razor. على سبيل المثال ، إذا كانت هناك في المستقبل صفحات Razore ثابتة أيضًا بامتداد .razor ويمكن للمجمع التعامل معها ، فسأحتفظ بامتداد .razor . بشكل أساسي مثل .xaml يتم استخدام الامتداد لعناصر التحكم والصفحات والموارد وكائنات التطبيق.

أعتقد أن هذا يجب أن يكون قابلاً للتحقيق تمامًا. لا أعرف ما هي الحالة الحالية لدعم الترميز الخلفي لمكونات Razor. ومع ذلك ، إذا كان هناك رمز خلفي يحدد ما إذا كان المكون موروثًا من ComponentBase أو أي شيء آخر. وهذا قد يحدد كيفية تجميع ملف .razor . وبدون التوريث الافتراضي للتعليمات البرمجية الخلفية هو ComponentBase وفي المستقبل قد يكون هناك إمكانية لتغيير الفئة الأساسية الافتراضية.

ومع ذلك ، إذا احتاجت كائنات Razor المستقبلية إلى امتداد مختلف ، فإن .blazor لمكونات Blazor سيكون خيارًا أفضل بكثير.

أرحب بهذا التغيير كثيرا! لطالما كان اسم "مكونات Razor" محيرًا بعض الشيء لأن التوقع كان أن هذا شيء من جانب الخادم البحت ، مثل كل شيء آخر تقوم به Razor. لذلك كان التوقع أن تكون مكونات Razor ، نوعًا ما مثل عناصر تحكم المستخدم في WPF ، طريقة لتكوين مكونات مخصصة باستخدام صيغة Razor بدلاً من التعليمات البرمجية (مثل تسمح مساعدة العلامات).

من خلال إعادة تسمية هذا ، يتم إزالة هذا الالتباس ، ولدينا بالفعل فرصة للتوصل في النهاية إلى مكونات Razor قابلة للإنشاء من جانب الخادم في مرحلة ما.

بالنسبة إلى الامتداد .razor ، مثل الآخرين ، أعتقد أنه سيكون من المنطقي استخدام .blazor بدلاً من ذلك. بالطريقة التي أفهمها ، يمكن أن تحتوي هذه الملفات على تعليمات برمجية قابلة للتطبيق فقط في سياق Blazor ، نظرًا لأن المنطق مرتبط بعمق بالمكون. لا أفترض أن هذا سيكون من الممكن إعادة استخدامه في سياق غير Blazor. أيضًا ، إذا كانت مكونات Blazor من جانب العميل ستنتهي باستخدام نفس الشيء ، أعتقد أن استخدام .blazor باستمرار هو فكرة أفضل لتحديد مكونات Blazor (والتي يمكن استخدامها بعد ذلك إما من جانب الخادم أو من جانب العميل) .

أعلم أن poke و @ duracellko ذكر كلاهما مصطلح مكونات blazor بشكل عابر ، لكنني في الحقيقة أحب ذلك كاسم. ماذا عن __مكونات Blazor__ بدلاً من __Blazor (من جانب الخادم) __؟

أوه. وأعتقد أن .blazor لاسم الامتداد فكرة جيدة أيضًا.

myty أعتقد أنه من الناحية المفاهيمية ، كانت المكونات دائمًا "مكونات Blazor" (على سبيل المثال ، يمكنك إنشاء مكونات باستخدام Blazor). "Blazor (من جانب الخادم)" و "Blazor (من جانب العميل)" هما نموذجان مختلفان للاستضافة يمكنك من خلالهما استهلاك وتشغيل نفس مكونات Blazor (على ما أعتقد؟). لذا يمكنك استخدام "مكونات Blazor" لوصف أنك تقوم بإنشاء مكون ، و "Blazor من جانب الخادم" لوصف كيفية تنفيذ مكونات Blazor.

myty أعتقد أنه من الناحية المفاهيمية ، كانت المكونات دائمًا "مكونات Blazor" (على سبيل المثال ، يمكنك إنشاء مكونات باستخدام Blazor). "Blazor (من جانب الخادم)" و "Blazor (من جانب العميل)" هما نموذجان مختلفان للاستضافة يمكنك من خلالهما استهلاك وتشغيل نفس مكونات Blazor (على ما أعتقد؟). لذا يمكنك استخدام "مكونات Blazor" لوصف أنك تقوم بإنشاء مكون ، و "Blazor من جانب الخادم" لوصف كيفية تنفيذ مكونات Blazor.

حقيقة أن مكونات Blazor كانت دائمًا ما باعني بهذا الاسم. أخبره كما هو ويبدو رائعًا أيضًا. :)

... لكني أرى أيضًا ارتباكًا بين جانب الخادم وجانب العميل. من الصعب أن تروي القصة دون أن تناديهم على وجه التحديد.

نعم! أخيرًا :) Blazor هو الاسم الحقيقي.

هل اشتعلت النيران حتى؟

نعم

بالنسبة لي Blazor = WASM.

لذا فإن "مكونات الحلاقة" (SignarR!) شيء مختلف تمامًا. شرح الفرق سهل بما فيه الكفاية: Blazor ís WASM.

برأيي المتواضع.

هذا بالتأكيد هو القرار الصحيح. حتى بعد تقديم مصطلح "مكونات Razor" الجديد ، ما زلت أنا وزملائي نشير إليها على أنها Blazor من جانب الخادم. أفضل أيضًا امتداد blazor أو شيء مثل .component. تستخدم طرق العرض في MVC أيضًا صيغة الشفرة ، لذلك يجلب .razor مزيدًا من الارتباك.

أعتقد أن العودة إلى إعادة تسمية مكونات Razor إلى Blazor جيدة.

أعتقد أن امتداد المكون لا ينبغي أن يكون .razor لأنه من المربك أن يكون لديك امتدادان مختلفان يمثلان ملفات razor. ( .cshtml و .razor )

أعتقد أن الإضافات .blazor أو .component ستكون بديلاً أفضل من .razor .

شكرًا لك على تغيير هذا الاسم مرة أخرى إلى Blazor Server-Side . أنا مرتاح لأكون صادقًا تمامًا. كان لدي lolwut صغير؟ لحظة عندما سمعت لأول مرة تغيير الاسم إلى مكونات Razor .

أنا شخصياً أعتقد أن كلمة Razor مليئة بما يكفي:

• موس الحلاقة
• وجهات النظر الحلاقة
• صفحات الحلاقة
• أدوات تحكم صفحة الحلاقة
• نماذج صفحة الحلاقة
• مكتبات فئة Razor
• مناظر جزئية للحلاقة
• مكونات عرض الشفرة
• : جديد: مكونات ماكينة الحلاقة: confused: //confusing much yet?
• ميزة عائلة Razor التالية: مكونات Razor View // just kidding :)

لقد جعلنا الأمر صعبًا بالفعل على شخص جديد يحاول التنقل في كل هذه الأشياء مع محاولة فهم كل حالة استخدام.

ليس فقط الشعور بالتعاطف مع المبتدئين ، ولكن تخيل محاولة شرح والحفاظ على استخدام المصطلحات "الصحيح" على فرق كبيرة عند الوصف والتنسيق (كيف / متى / ماذا) للاستخدام.

Blazor هو اسم جيد لأننا وصلنا بالفعل إلى ربط حالات استخدامه. يو ، حتى Razor Sockets سيكون اسمًا أفضل من Razor Components . :نظارة شمسيه:

أيضًا ، أعتقد أن إعادة تسمية .razor إلى .blazor فكرة جيدة.

التسمية صعبة.
اجعل الأمور بسيطة.

-براين :)

إن الاهتمام بمكونات Razor لأنها تلعب بشكل جيد في مشروعي يقودني إلى هنا.
أنا أفهم ما نتحدث عنه ، لكن الشخص الذي بدأ للتو قد يكون مرتبكًا بشأن ما هو تحت الغطاء ، بسبب التسمية.
إذا كان الهدف هو شحن مكونات Razor كبديل مؤقت لجهاز Blazor القادم ، فلن أرغب في تغيير اسمه.

لن تتأثر BlazorMitiko Server-side بالقرارات المتعلقة بـ Blazor من جانب العميل (استنادًا إلى WebAssembly). بافتراض إطلاق الإصدار الأخير في وقت ما ، ستظل قادرًا على استخدام Blazor من جانب الخادم. سيكون كلا نموذجي التطبيق في الواقع قادرين على مشاركة أشياء معينة ، لذا من المنطقي مواءمتها مع أسمائهم أيضًا.

هذا هو السبب في أنها محيرة في النهاية. عندما يكون لديك منطق لا يهتم بمكان استضافته ، ماذا يسمى؟ ثم يغير إطار العمل الأسماء بطريقة سحرية بناءً على "shell" الذي تستخدمه. ليس من المنطقي أن يكون لديك اسمان. لمعرفة نقطة poke ، انظر الفيديو أدناه: Mitiko

https://www.youtube.com/watch؟v=dNQ7MgPZby4

ماذا عن قالب Blazor المستضاف؟

ghidello يبقى كما هو. لذلك سيكون هناك ثلاثة قوالب Blazor: جانب العميل المستقل ، و ASP.NET Core المستضاف ، والجانب الخادم

يسعدني أن أرى هذا ، كما قلت - الاسم له معنى وزخم وراءه ويوضح لي أن كلا النموذجين يمضيان قدمًا بدعم قوي.

IMO يجب عليك أيضًا تسمية اسم طراز المكون للإشارة إلى Blazor ، حتى إذا كنت تستخدم صيغة / محرك Razor. من شأنه أن يجعله حلاً أكثر تماسكًا في متجر واحد ، تسمية حكيمة.

ماذا عن مساحة اسم المكونات؟ يجب إعادة تسميته أيضًا.

ويجب أن تكون ملفات .razor. blazor لأنها مرتبطة بتقنية Blazor. وإلا يجب استخدامها في Razor Mvc الشائعة أيضًا.

لا يزال مرتبكًا بعض الشيء فيما يتعلق بالمكونات:

لذا ، إذا كنت أقوم ببناء مكتبة مكونة ، تعمل مع جانب الخادم وجانب العميل من Blazor ، فهل أشير إلى المكونات على أنها "مكونات Blazor" أو "مكونات Razor"؟

egil بناءً على ما قاله دان روث أعلاه ، سيظل أحد المكونات معروفًا باسم مكون Razor.

سنستمر في الإشارة إلى نموذج المكون على أنه مكونات Razor (على سبيل المثال ، سيظل ملف .razor أحد مكونات Razor)

إضافة تصويتي بالموافقة على هذا التغيير.

كما أراها ، فإن RazorComponent هو مكون C # مكتوب باستخدام صيغة Razor ورمز C #. يمكننا استخدام RazorComponents في مجموعة واسعة من المشاريع ، بما في ذلك Blectron (كما في العرض التوضيحي StorageExplorer) ، مولدات HTML (على سبيل المثال لإنشاء جسم البريد الإلكتروني بنفس الطريقة التي يستخدمها RazorGenerator مقابل .cshtml محتوى Blazor .

على النقيض من ذلك ، فإن Blazor هو إطار عمل التطبيق الذي يستخدم RazorComponents على العميل ، باستخدام نموذجين مختلفين للاستضافة (WebAssembly والجانب الخادم).

لقد أضفت مخططًا يوضح كيف أراه .. نرحب بالتعليقات

يبدو Blazor (جانب العميل مع WASM) و Blazor (من جانب الخادم مع .NET Core) رائعين!

مكونات Razor لواجهة المستخدم لكليهما ، مع Blazor كإطار عمل للتطبيقات بغض النظر عن نموذج الاستضافة. بسيط ، نظيف ، وكما سيقول أحد الكوميديين المفضلين لدي .... GIT R DONE!

يبدو عميل Blazor وجانب الخادم جيدًا حقًا.
بالنسبة للمبتدئين ، من الأسهل فهم الاختلافات بين جانب العميل وجانب الخادم.

كما قال آخرون ، هناك أسباب مقنعة للنظر في .blazor (واسم "مكون Blazor"). هل يمكن مشاركة المبررات الأكثر منطقية وراء الاحتفاظ بـ .razor (واسم "مكون Razor")؟

هذا هو الأساس المنطقي حتى هذه النقطة الذي يمكن أن أجده:

نحن نخطط للاحتفاظ بامتداد .razor للمكونات. تستند المكونات إلى بناء جملة Razor ، ولكن يتم التعامل مع المكونات بشكل مختلف بواسطة مترجم Razor ، لذلك فهي بحاجة إلى امتداد ملف مختلف.

أشعر أن وجهة نظري قد تكون شديدة التبسيط:

const string serverSideName = "Blazor (server-side)";
const string clientSideName = "Blazor (client-side)";

string componentModel = "Razor Components";
string ext = ".razor";

if (serverSideName.Contains("Blazor") && clientSideName.Contains("Blazor"))
{
    componentModel = "Blazor Components";
    ext = ".blazor";
} 

Console.WriteLine(componentModel);
Console.WriteLine(ext);

هناك عدة أسباب وراء تفضيلنا للاحتفاظ بامتداد .razor:

• لا يزال الاسم دقيقًا وصفيًا. ملف .razor هو مكون واجهة مستخدم مكتوب باستخدام صيغة Razor.
• تقليل الزبد. يتطلب تحديث امتداد الملف قدرًا معقولاً من التنسيق عبر فرق ومشاريع متعددة. نظرًا لأننا قمنا بالفعل بهذا العمل لـ .razor ، فإننا نفضل عدم القيام بذلك مرة أخرى ما لم يكن هناك سبب وجيه لذلك.
• اعزل الإطار عن اسم المنتج أو تغييرات الإستراتيجية. من خلال الحفاظ على تسمية نموذج المكون بشكل أكثر عمومية ، نأمل في تقليل تأثير أي خلط محتمل في الأسماء أو تغييرات في اتجاه المشروع في المستقبل.

@ danroth27 ما يزعجني هو أن بنية الشفرة موجودة في ملفات .cshtml و .razor. أعتقد أنه سيكون هناك ارتباك بشأن الامتداد الذي يتم عرض صفحة Razor / Component / MVC من أجله.

نقطتان أخريان عادلة بما فيه الكفاية.

@ danroth27

لا يزال الاسم دقيقًا وصفيًا. ملف .razor هو مكون واجهة مستخدم مكتوب باستخدام صيغة Razor.

ما يزعجني في هذه الحجة هو أن ملف .razor يحتوي على أشياء مثل معالجات الأحداث أو طرق دورة الحياة أو الارتباطات المتغيرة. هذه المفاهيم خاصة جدًا بـ Blazor ولن تعمل خارجها. لذلك ، في حين أنه بناء جملة Razor ، إلا أنه نكهة محددة للغاية تمكن من تنفيذ منطق جانب العميل.

لن تعمل هذه الأشياء مع "مكونات Razor" من جانب الخادم والمقدمة فقط ، والتي يمكن أن تكون شيئًا افتراضيًا في المستقبل (نظرًا لأن أجزاء العرض على سبيل المثال ستعمل بشكل جيد جدًا على الخادم أيضًا).

لذلك نحن نغلق امتداد الملف .razor والاسم "Razor component" لنكهة معينة من Razor لن تعمل إلا مع المكونات ذات السلوك المضمّن من جانب العميل.

@ danroth27 الجميع تقريبًا (بمن فيهم أنا) .blazor بدلاً من .razor فلماذا تريد التمسك بـ .razor فردي. هل هناك أي تحديات فنية لتغيير هذا؟ أو فقط هذا هو ما تفضله أنت وفريقك؟

شكرا لك.

كما ذكر @ danroth27 التنسيق مع فرق متعددة ، يمكنني التفكير في فريق VS Team وفريق Razor ، قد يكون جزءًا كبيرًا من العمل الذي لكل فريق أولويات مختلفة في المهام.

يمكنني رؤية ملحق .razor المناسب إذا كان سيكون شيئًا أكثر عمومية يصف أي نوع من المكونات المكتوبة في Razor مثل كيفية استخدام .xaml لكل من الموارد وعناصر التحكم في عالم سطح المكتب.

لنفترض أنه إذا كان ذلك ممكنًا في المستقبل ، يمكنك استخدام عناصر تحكم أصلية UWP / xaml مؤلفة باستخدام ماكينة حلاقة ، وليس html عبر الإلكترون ولكن أصلي تمامًا ، حيث قد يكون أسلوب الحلاقة الضروري لإنشاء عناصر التحكم بديلاً مقنعًا مقابل .xaml's طريقة الإعلان الحالية

هذا مثال نظري على الرغم من ذلك ، في هذه المرحلة ، يمكنك القول أنه يستخدم مكونات Razor ولكنه ليس في سياق Blazor بل في سياق أصلي مثل React Native حيث يمكن أن تختلف الأشياء مثل اختلاف روابط الأحداث ، وبعض السمات المحددة لـ Blazor غير قابلة للتطبيق إلخ...

أرى Blazor كإطار عمل يستخدم مكونات Razor ( .razor ) مثل كيفية استخدام React كإطار عمل .jsx/.tsx لتكوين المكون ومثل .jsx/.tsx قد يكون من الممكن أن يكون يمكن استخدامها في أطر أخرى مماثلة مثل كيفية دعم Vue و TKO .jsx/.tsx خلال تكوين ما يفعله نظام الإنشاء لملفات .jsx/.tsx .

شكرا للجميع على ملاحظاتكم حول هذه المسألة. تم الانتهاء من إعادة تسمية مكونات Razor إلى Blazor من جانب الخادم!

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

يرجى إعادة تسمية الملصق-المكونات إلى feature-Blazor أيضًا.

أعزائي ، أنا أستخدم vs 2019 ، لقد قمت بتثبيت الإصدار الأخير من Blazor ، لدي معاينة Core 3 4 ، لقد قمت بإنشاء مشروع Blazor ، جميع الصفحات الآن بامتداد .razor بدلاً من .cshtml ، قمت بتشغيل التطبيق ، ولكن أعطني تحميل ... دون الانتقال إلى صفحة Index.razor ، أي مساعدة من فضلك. شكرا لك مقدما.

ImadMichaelAyoub هل لديك رسائل خطأ في وحدة التحكم؟ هل تقوم بتشغيل Blazor من جانب العميل أم من جانب الخادم؟

أود أن أقترح أن هذا ربما لا يكون أفضل مكان لهذه المناقشة. من الأفضل الانضمام إلى قناة Blazor Gitter (https://gitter.im/aspnet/Blazor) ويمكننا مساعدتك هناك.

شكرا على الرد. أنا أستخدم Blazor من جانب العميل. يبدو أن التطبيق يقوم بتشغيل ملف index.html في wwwroot ولا ينتقل إلى index.cshtml في مجلد الصفحات.

أنا جديد على Razor و Blazor. إنه أمر محير عند البحث عبر الإنترنت عن حل ، فإنك تحصل على الكثير من شفرات الحلاقة أو الأشياء القديمة التي لا تنطبق بعد الآن ، مما يضيف المزيد من الالتباس. أصوت بشدة للتغيير إلى اسم جديد (حتى إلى .blazor) حتى نتمكن من البحث والحصول على الأحدث.

نحن نخطط للاحتفاظ بامتداد .razor للمكونات. تستند المكونات إلى بناء جملة Razor ، ولكن يتم التعامل مع المكونات بشكل مختلف بواسطة مترجم Razor ، لذلك فهي بحاجة إلى امتداد ملف مختلف.

هل هذا يعني - "تم التخطيط للاحتفاظ بامتداد .razor نفسه .. لكنه يحتاج إلى امتداد مختلف عن .razor ، حتى لو لم يكن مخططًا له"؟

"التكنولوجيا العظيمة تأتي مع التباس كبير في الاسم"