Aspnetcore: Razorコンポーネントの名前をサーバー側のBlazorに戻します

これは承認された決定ですか？ まだ投票できますか？

個人的に私は名前を変えることに反対しています。 RazorComponentsの方がいい名前だと思います。 :(

@xcludオープンフォーラムなので、フィードバックはいつでも歓迎です😃

コンポーネントモデルを引き続きRazorコンポーネントと呼びます（つまり、.razorファイルは引き続きRazorコンポーネントになります）が、アプリケーションモデルについて話すとき、異なる名前を付けるのは非常に面倒です。 Blazorという名前の背後にはすでにかなりの勢いがあるので、私たちはそれに固執したいと思います。 名前はもちろん主観的なものです。どの名前を選んでも、誰もが満足できるわけではありませんが、Blazorはこれまでのところかなり役立っているようです。

これは良い動きだと思います。 RazorComponentsとBlazorの関係について混乱は終わりませんでした。 人々は、レンダリングの方法が異なるだけでなく、フレームワークも異なると考えているほどです。

さらに、私の個人的な意見では、Blazorはクールな名前です。

Blazorについて頻繁に人と話す人として。 RazorComponentsは混乱に他なりませんでした。 BlazorアプリがRazorComponentsアプリである場合、[Razor Pages＆Razor Class Libraries]に関連するRazor Componentsがいつであるか、Razor / Blazorと言うときに自分自身をつまずかせるという点で混乱しています。 それはまた、Blazorについて書くことを難しくし、SEOを難しくします、私は続けることができました。

正気が勝つ！ この変更に感謝します。

かみそりのページはまだ.cshtmlであり、コンポーネントは.razorであるため、.razorファイル拡張子はどうなりましたか？.blazorと呼ぶと便利な場合がありますか？ または、かみそりのページを.cshtmlではなく.razorと呼びますか？
かなり紛らわしいもの

コンポーネントの.razor拡張子を維持することを計画しています。 コンポーネントはRazor構文に基づいていますが、コンポーネントはRazorコンパイラによって異なる方法で処理されるため、異なるファイル拡張子が必要です。

ブレイザーがホストするテンプレートはどうですか？ クライアント側モデルの場合、これが最も簡単な方法です。

• CSPセキュリティヘッダーの適用
• SRIハッシュの計算（理想的には、これはblazor.webassembly.jsによって直接ダウンロードされたアセットにも必要になります）
• アセットの圧縮（少なくとも、私が試したいくつかのCDNによってすでに圧縮されているwasmコンテンツタイプでdllファイルが出荷されるまで）

したがって、ホストされているテンプレートが引き続き存在することを願っています。

この名前を「Blazor」に戻すのも大好きです。 ATMがBlazorとRazorのコンポーネントについて人々と話しているのは、単なる混乱です。

Blazorは、（少なくとも）2つのホスティングモデルを備えた技術です。 だから、私はBlazorが好きです！

それらすべてを支配する1つの名前。 2つの異なるホスティングモデルを備えた1つのBlazorの方が間違いなく優れています。 これにより、将来の多くの混乱を防ぐことができます。

この変更を歓迎します！ 新しい（または古い）命名は、私が感じる混乱をはるかに少なくします。

ファイル拡張子も.blazor変更する必要があるという@vertonghenbに同意します。 それははるかに理にかなっています。 .cshtmlと.razor両方にかみそりの構文がありますが、 .blazorファイル拡張子をより正確で曖昧さの少ないIMHOにするBlazor固有のコードを使用する必要があるのは1つだけです。

短いコメント：名前を_RazorComponents_から_Server-sideBlazor_に戻すことに同意します。

長い答え：クライアント側とサーバー側の両方の「コンポーネント」は、Blazor、Razorコンポーネント、ASP.NETCoreコンポーネントのいずれであっても同じ名前にする必要があると思います。 たとえば、ReactとReact Nativeははるかに異なるテクノロジーですが、同じ名前を共有しています。

Blazor名の利点：

• それはすでにコミュニティで確立された名前です。 実際には、ブラウザで.NETを実行するテクノロジとしても理解されていますが、これは100％正確ではありません。
• Blazorはサーバー側で.NETなしで（実際にはサーバー側なしで）使用できることを人々が受け入れ/理解する方が簡単かもしれません。

Razorコンポーネント名の利点：

• RazorおよびASP.NETCoreとリンクすると、テクノロジが適切なサポートと安定性を備えていることを理解するのに役立つ場合があります。 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（サーバー側）__の代わりに__BlazorComponents__はどうですか？

おお。 拡張子名の.blazorも良い考えだと思います。

@myty概念的には、コンポーネントは常に「Blazorコンポーネント」でした（つまり、Blazorでコンポーネントを作成します）。 「Blazor（サーバー側）」と「Blazor（クライアント側）」は、同じ（私が思うに）Blazorコンポーネントを使用して実行できる2つの異なるホスティングモデルです。 したがって、「Blazorコンポーネント」を使用してコンポーネントを作成していることを説明し、「サーバー側Blazor」を使用してBlazorコンポーネントをどのように実行しているかを説明します。

@myty概念的には、コンポーネントは常に「Blazorコンポーネント」でした（つまり、Blazorでコンポーネントを作成します）。 「Blazor（サーバー側）」と「Blazor（クライアント側）」は、同じ（私が思うに）Blazorコンポーネントを使用して実行できる2つの異なるホスティングモデルです。 したがって、「Blazorコンポーネント」を使用してコンポーネントを作成していることを説明し、「サーバー側Blazor」を使用してBlazorコンポーネントをどのように実行しているかを説明します。

それが常にBlazorコンポーネントであったという事実が、私をその名で売ったものでした。 それがそうであるようにそれを言いなさい、そしてそれもクールに聞こえる。 :)

...しかし、サーバー側とクライアント側の間の混乱も見られます。 特に声をかけずに話をするのは難しい。

はい！ 最後に：）Blazorは本当の名前です。

あなたも炎上しますか？

はい

私にとってBlazor = WASM。

したがって、「RazorComponents」（SignarR！）はまったく異なるものです。 違いを説明するのは簡単です：BlazorのWASM。

私見では。

これは間違いなく正しい決断です。 新しい「RazorComponents」という用語が導入された後も、私と私の同僚はそれをサーバーサイドブレイザーと呼んでいます。 また、.blazor拡張子または.componentのようなものが好きです。 MVCのビューもかみそりの構文を使用しているため、.razorはさらに混乱を招きます。

RazorComponentsの名前をBlazorに戻すUターンは良いことだと思います。

かみそりファイルを表す2つの異なる拡張子があると混乱するため、コンポーネント拡張子を.razorべきではないと思います。 （ .cshtmlおよび.razor ）

.blazorまたは.component拡張子は、 .razorよりも優れた代替手段になると思います。

この名前をBlazorServer-Sideに戻していただきありがとうございます。 正直に言ってほっとしました。 私は小さな笑いを持っていましたか？ 名前がRazorComponentsに変更されたのを最初に聞いた瞬間。

個人的には、 Razorという言葉は十分に過負荷になっていると思います。

• かみそり
• かみそりのビュー
• かみそりのページ
• かみそりのページコントローラー
• かみそりのページモデル
• かみそりクラスライブラリ
• かみそりの部分ビュー
• RazorViewコンポーネント
• ：new：Razorコンポーネント：confused： //confusing much yet?
• 次のRazorファミリー機能： Razorコンポーネントビュー// just kidding :)

私たちはすでに、新しい誰かがこれらすべてのRazorのことをナビゲートしようとし、それぞれのユースケースを理解しようとすることを困難にしています。

初心者に共感を感じるだけでなく、使用する方法（方法/時期/内容）を説明および調整するときに、大規模なチームで「正しい」用語の使用法を説明および維持しようとすることを想像してください。

Blazorは、すでにそのユースケースに関連付けられているため、良い名前です。 ヨ、でもカミソリソケットはカミソリのコンポーネントよりも優れ名前だったでしょう。 ：サングラス：

また、 .razor名前を.blazorに変更するのも良い考えだと思います。

ネーミングは難しいです。
物事をシンプルにしてください。

-ブライアン:)

私のプロジェクトでうまく機能するのでRazorComponentsに興味を持っていると、私はここにたどり着きます。
私たちが話していることは理解していますが、始めたばかりの人は、名前のせいで、ボンネットの下にあるものに混乱するかもしれません。
今後のBlazorの一時的な代替品として、Razorコンポーネントを出荷することが目標である場合、その名前を変更したくありません。

@Mitikoサーバー側Blazorは、クライアント側Blazor（WebAssemblyに基づく）に関する決定の影響を受けません。 後者がいずれかの時点でリリースされたと仮定すると、サーバー側のBlazorを引き続き使用できます。 どちらのアプリケーションモデルも実際には特定のものを共有できるため、それらを名前に合わせる方が理にかなっています。

これが最終的に混乱する理由です。 どこでホストされているかを気にしないロジックがある場合、それは何と呼ばれますか？ 次に、フレームワークは、使用する「シェル」に基づいて名前を魔法のように変更します。 2つの名前を持つことは意味がありません。 @pokeのポイントについては、以下のビデオを参照してください： @Mitiko

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

ブレイザーがホストするテンプレートはどうですか？

@ghidelloそのままです。 したがって、スタンドアロンのクライアント側、ASP.NET Coreでホストされている、サーバー側の3つのBlazorテンプレートがあります。

おっしゃるように、これを見てうれしいです。名前には意味と勢いがあり、どちらのモデルも強力なサポートを受けて前進していることを私には伝えています。

IMOは、Razor構文/エンジンを使用している場合でも、Blazorを参照するためにコンポーネントモデル名にも名前を付ける必要があります。 それは、賢明な命名で、それをよりまとまりのあるワンストップショップソリューションにするだけです。

コンポーネントの名前空間はどうですか？ 名前も変更する必要があります。

また、.razorファイルはBlazorテクノロジーにリンクされているため、.blazorである必要があります。 それ以外の場合は、一般的なRazorMvcにも使用する必要があります。

コンポーネントに関してまだ少し混乱しています：

したがって、サーバー側とクライアント側の両方のBlazorで機能するコンポーネントライブラリを構築している場合、コンポーネントを「Blazorコンポーネント」または「Razorコンポーネント」と呼びますか？

@egil Dan Rothが上記で述べたことに基づいて、コンポーネントは引き続きRazorコンポーネントとして知られています。

コンポーネントモデルを引き続きRazorコンポーネントと呼びます（つまり、.razorファイルは引き続きRazorコンポーネントになります）

この変更に私の承認投票を追加します。

ご覧のとおり、 RazorComponentは、Razor構文とC＃コードを使用して記述されたC＃コンポーネントです。 Blectron （StorageExplorerデモのように）、HTMLジェネレーター（たとえば、 RazorGeneratorが.cshtmlに対して行うのと同じ方法でメール本文を生成するため）を含む幅広いプロジェクトでRazorComponentsを使用できます。 .cshtmlコンテンツ。 Blazorだけに限定されません。

対照的に、 Blazorは、2つの異なるホスティングモデル（WebAssemblyとサーバー側）を使用して、クライアントでRazorComponentsを使用するアプリケーションフレームワークです。

私はそれをどのように見るかを示す図を追加しました..コメントを歓迎します

Blazor（クライアント側w / WASM）とBlazor（サーバー側w / .NET Core）は素晴らしいサウンドです！

両方のUI用のRazorコンポーネント。ホスティングモデルに関係なく、アプリケーションのフレームワークとしてBlazorを使用します。 シンプルでクリーン、そして私のお気に入りのコメディアンの1人が言うように.... 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構文で記述されたUIコンポーネントです。
• 解約を減らします。 ファイル拡張子を更新するには、複数のチームやプロジェクト間でかなりの量の調整が必要です。 .razorに対してこの作業をすでに行っているので、本当に正当な理由がない限り、再度行うことはしたくありません。
• フレームワークを製品名や戦略の変更から隔離します。 コンポーネントモデルの名前をもう少し一般的なものにしておくことで、将来の潜在的な名前のシャッフルやプロジェクトの方向性の変更による影響を減らすことができます。

@ danroth27私を

他の2つのポイントは十分に公平です。

@ danroth27

名前はまだ正確で説明的です。 .razorファイルは、Razor構文で記述されたUIコンポーネントです。

この引数について気になるのは、 .razorファイルにイベントハンドラー、ライフサイクルメソッド、変数バインディングなどが含まれていることです。 これらの概念はBlazorに非常に固有であり、Blazorの外では機能しません。 したがって、これはRazor構文ですが、クライアント側のロジックを実行できるようにするのは非常に特殊なフレーバーです。

これらは、純粋にサーバー側およびサーバーでレンダリングされた「Razorコンポーネント」では機能しません。これは、将来的には架空のものになる可能性があります（たとえば、レンダリングフラグメントはサーバーでも非常にうまく機能するため）。

そのため、ファイル拡張子.razorと名前「Razorcomponent」をロックして、クライアント側の動作が埋め込まれたコンポーネントでのみ機能するRazorの特定のフレーバーを指定します。

@ danroth27ほとんど（私を含め）誰もがそれを望むれる.blazorの代わりに.razorそして、なぜあなたはに固執したいされている.razor個別。 これを変更するための技術的な課題はありますか？ それともこれがあなたとあなたのチームの好みですか？

ありがとうございました。

@ danroth27が複数のチームとの調整について言及したように、VSチーム、Razorチームチームと考えることができます。これは、各チームがタスクの優先順位が異なる大きな作業の塊である可能性があります。

.xamlがデスクトップの世界でリソースとコントロールの両方にどのように使用されるかなど、Razorで記述されたあらゆる種類のコンポーネントを説明するより一般的なものになる場合は、 .razor拡張機能のフィッティングを確認できます。

あなたはネイティブ使用することができ、将来的に言って、可能であればUWP / xamlではない、かみそりを使用して作成コントロールをhtml統制を構築するのかみそりの不可欠なスタイルがにとって魅力的な選択肢かもしれないとして、電子を通じて純粋にネイティブ.xaml's現在の宣言的な方法（特にC＃制御フローに対するかみそりのサポート）。

これは理論的な例ですが、その時点では、Razorコンポーネントを使用しているが、Blazorコンテキストではなく、イベントバインディングが異なるなど、Blazor固有の属性が異なるなど、ReactNativeのようなネイティブコンテキストにあると言えます。 NS...

私はカミソリのコンポーネントを使用してフレームワークとしてBlazorを参照してください（ .razor ）フレームワークを使用するとどのように反応するかのように.jsx/.tsx成分組成のためにとのように.jsx/.tsxそれがすることが可能かもしれませんビルドシステムが.jsx/.tsxファイルに対して行うことを構成することにより、VueとTKOが.jsx/.tsxサポートする方法など、他の同様のフレームワークで使用できます。

この問題についてフィードバックをお寄せいただき、ありがとうございます。 サーバー側のBlazorに名前を変更するRazorコンポーネントが完了しました！

上記の理由により、.razor拡張子はそのままにしておくことにしました。 この決定については、さまざまなフィードバックがありました。 Blazorに対するすべての要望に感謝しますが、現在の拡張子は適切であると考えており、ファイル拡張子を変更するのではなく、Blazorを出荷できるようにすることに注力することを好みます。 この決定を踏まえて、私は先に進んでこの問題を解決します。

ラベルの名前をfeature-Componentsからfeature-Blazorに変更してください。

親愛なる、私はvs 2019を使用しています、私はBlazorの最後のバージョンをインストールしました、私はコア3プレビュー4を持っています、私はBlazorプロジェクトを作成しました、今すべてのページは.cshtmlの代わりに.razor拡張子を持っています、私はアプリケーションを実行しました、しかし私に与えます読み込んでいます... Index.razorページに移動せずに、助けてください。 前もって感謝します。

@ImadMichaelAyoubコンソールにエラーメッセージがありますか？ クライアント側またはサーバー側のBlazorを実行していますか？

これはおそらくこの議論に最適な場所ではないことをお勧めします。 Blazor Gitterチャンネル（https://gitter.im/aspnet/Blazor）に参加するのがおそらく最善であり、そこでお手伝いします。

返信いただきありがとうございます。 クライアントサイドのBlazorを使用しています。 アプリケーションはwwwrootでindex.htmlファイルを実行し、pagesフォルダーのindex.cshtmlに移動していないようです。

RazorとBlazorは初めてです。 オンラインで解決策を検索するときは混乱します。かみそりや古いものが大量にあり、もはや適用されないため、さらに混乱が生じます。 私は、最新の名前を検索して取得できるように、変更を新しい名前（.blazorにも）に変更することに強く投票します。

コンポーネントの.razor拡張子を維持することを計画しています。 コンポーネントはRazor構文に基づいていますが、コンポーネントはRazorコンパイラによって異なる方法で処理されるため、異なるファイル拡張子が必要です。

これは、「同じ.razor拡張子を維持するように計画されていますが、計画されていなくても、.razorとは異なる拡張子が必要です」という意味ですか？

「優れたテクノロジーには、名前の混乱が伴います」