Aspnetcore: 将 Razor 组件重命名回服务器端 Blazor

这是批准的决定吗？ 我们还能投票吗？

我个人反对更改名称。 我认为 Razor Components 是一个更好的名字。 :(

@xclud这是一个开放的论坛，所以随时欢迎反馈😃

我们仍将组件模型称为 Razor 组件（即 .razor 文件仍将是 Razor 组件），但在讨论应用程序模型时，我们发现使用不同的名称非常麻烦。 Blazor 这个名字背后已经有了相当大的动力，所以我们想坚持下去。 名字当然是主观的——无论我们选择什么名字，并不是每个人都会高兴，但到目前为止，Blazor 似乎对我们的服务很好。

我认为这是一个很好的举措。 关于 Razor Components 和 Blazor 之间的关系一直没有结束混淆。 以至于人们认为它们是不同的框架，而不仅仅是不同的渲染方式。

另外，在我个人看来，Blazor 是一个很酷的名字。

作为一个经常与人们谈论 Blazor 的人。 Razor Components 一直令人困惑。 在以下方面令人困惑：Blazor 应用程序何时是 Razor 组件应用程序、与 [Razor 页面和 Razor 类库] 相关的 Razor 组件，以及在说 Razor/Blazor 时被自己绊倒。 这也使撰写有关 Blazor 的文章变得困难，SEO 变得困难，我可以继续。

理智占上风！ 非常感谢这个改变。

.razor 文件扩展名发生了什么，因为 razor 页面仍然是 .cshtml 而组件是 .razor，将其称为 .blazor 可能会有所帮助？ 或者将剃刀页面也称为 .razor 而不是 .cshtml？
相当混乱的东西

我们计划保留组件的 .razor 扩展名。 组件基于 Razor 语法，但 Razor 编译器对组件的处理方式不同，因此它们需要不同的文件扩展名。

blazor 托管模板怎么样？ 对于客户端模型，这是最简单的方法：

• 应用 CSP 安全标头
• 计算 SRI 哈希（理想情况下，blazor.webassembly.js 直接下载的资产也需要这样做）
• 压缩资产（至少在 dll 文件将与 wasm 内容类型一起交付之前，该内容类型已由我尝试过的几个 CDN 压缩）

所以我希望托管模板仍然存在。

我也喜欢这个重命名回到“Blazor”。 ATM 与人们谈论 Blazor 和 Razor 组件只是简单的混淆。

Blazor 是一种具有（至少）两个托管模型的技术。 所以，我喜欢Blazor！

一统天下。 具有两种不同托管模型的 Blazor 绝对更好。 它避免了道路上的很多混乱。

我欢迎这个改变！ 我觉得新（或旧）命名远没有那么混乱。

我同意@vertonghenb 的观点，即文件扩展名也应该重命名为.blazor 。 这更有意义。 .cshtml和.razor都有 razor 语法，但只有一个应该有 Blazor 特定的代码，这将使.blazor文件扩展名更精确，恕我直言不那么模棱两可。

简短评论：我同意将名称从 _Razor Components_ 改回 _​​Server-side Blazor_。

长答案：我相信客户端和服务器端的“组件”应该具有相同的名称，无论它是什么：Blazor、Razor 组件、ASP.NET Core 组件。 例如 React 和 React Native 是更多不同的技术，但它们共享相同的名称。

Blazor 名称的优点：

• 它已经在社区中享有盛誉。 实际上也可以理解为在浏览器中运行 .NET 的技术，这不是 100% 正确的。
• 人们可能更容易接受/理解 Blazor 可以在没有 .NET 的服务器端使用（实际上没有任何服务器端）。

Razor Components 的优势名称：

• 与 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也是一个好主意。

@myty我认为从概念上讲，组件始终是“Blazor 组件”（即您使用 Blazor 创建组件）。 “Blazor（服务器端）”和“Blazor（客户端）”是两种不同的托管模型，您可以在其中使用和运行相同的（我认为？）Blazor 组件。 因此，您将使用“Blazor 组件”来描述您正在创建一个组件，并使用“服务器端 Blazor”来描述您如何执行 Blazor 组件。

@myty我认为从概念上讲，组件始终是“Blazor 组件”（即您使用 Blazor 创建组件）。 “Blazor（服务器端）”和“Blazor（客户端）”是两种不同的托管模型，您可以在其中使用和运行相同的（我认为？）Blazor 组件。 因此，您将使用“Blazor 组件”来描述您正在创建一个组件，并使用“服务器端 Blazor”来描述您如何执行 Blazor 组件。

它始终是 Blazor 组件这一事实是我以这个名字出售的原因。 照原样告诉它，听起来也很酷。 :)

...但是，我也看到了服务器端和客户端之间的混淆。 如果不特别指出他们，就很难讲述这个故事。

是的！ 最后:) Blazor 是真名。

你甚至开火吗？

是的

对我来说 Blazor = WASM。

所以“Razor Components”（SignarR！）是完全不同的东西。 解释差异很容易：Blazor 是 WASM。

恕我直言。

这绝对是正确的决定。 即使在引入了新的“Razor 组件”术语之后，我和我的同事仍然将其称为服务器端 Blazor。 我也更喜欢 .blazor 扩展名或类似 .component 的东西。 MVC 中的视图也使用 razor 语法，因此 .razor 带来了额外的混乱。

我认为将 Razor Components 重命名为 Blazor 的掉头是一个很好的方法。

我确实认为组件扩展名不应该是.razor因为有 2 个不同的扩展名代表 razor 文件会令人困惑。 （ .cshtml和.razor ）

我认为.blazor或.component扩展会比.razor更好。

感谢您将此名称改回Blazor Server-Side 。 老实说，我松了口气。 我有一个小lolwut？ 我第一次听到名称更改为Razor Components 的那一刻。

就我个人而言，我认为Razor这个词已经够用了：

• 剃刀
• 剃刀视图
• 剃刀页面
• Razor 页面控制器
• 剃刀页面模型
• Razor 类库
• 剃刀部分视图
• Razor 视图组件
• :new: Razor 组件 :confused: //confusing much yet?
• 下一个 Razor 系列功能： Razor 组件视图// just kidding :)

我们已经让新人难以驾驭所有这些 Razor事物以及试图理解每个用例。

不仅要对新手有同理心，还要想象在描述和协调（如何/何时/什么）使用时，尝试解释和维护大型团队的“正确”术语使用。

Blazor 是一个好名字，因为我们已经开始与它的用例相关联。 哟，即使是Razor Sockets也比Razor Components更好。 ：太阳镜：

另外，我认为将.razor重命名.blazor是个好主意。

命名很难。
保持简单。

-布莱恩 :)

对 Razor Components 感兴趣，因为它在我的项目中表现得很好，这让我来到了这里。
我明白我们在说什么，但刚开始的人可能会因为命名而对引擎盖下的内容感到困惑。
如果目标是将 Razor 组件作为即将推出的 Blazor 的临时替代品发布，我不希望它的名称发生变化。

@Mitiko服务器端 Blazor 不会受到围绕客户端 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根据 Dan Roth 上面所说的，组件仍将被称为 Razor 组件。

我们仍将组件模型称为 Razor 组件（即 .razor 文件仍将是 Razor 组件）

将我的赞成票添加到此更改中。

在我看来， RazorComponent是使用 Razor 语法和 C# 代码编写的 C# 组件。 我们可以在广泛的项目中使用RazorComponents ，包括Blectron （如在 StorageExplorer 演示中）、HTML 生成器（例如用于电子邮件正文生成，与RazorGenerator为.cshtml所做的相同Blazor 。

相比之下， Blazor是在客户端使用RazorComponents的应用程序框架，使用两种不同的托管模型（WebAssembly 和服务器端）。

我添加了一个图表来展示我的看法..欢迎评论

Blazor（带有 WASM 的客户端）和 Blazor（带有 .NET Core 的服务器端）听起来很棒！

两者的 UI 的 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 语法编写的 UI 组件。
• 减少流失。 更新文件扩展名需要跨多个团队和项目进行大量协调。 由于我们已经为 .razor 完成了这项工作，除非有很好的理由，否则我们宁愿不再这样做。
• 将框架与产品名称或策略更改隔离开来。 通过保持组件模型命名更通用，我们希望减少任何潜在的名称改组或未来项目方向变化的影响。

@danroth27让我感到

其他两点就足够公平了。

@danroth27

该名称仍然准确且具有描述性。 .razor 文件是使用 Razor 语法编写的 UI 组件。

这个论点让我感到困扰的是， .razor文件包含诸如事件处理程序、生命周期方法或变量绑定之类的内容。 这些概念非常特定于 Blazor，在它之外不起作用。 因此，虽然它是 Razor 语法，但它是一种非常特殊的风格，可以执行客户端逻辑。

这些东西不适用于纯粹的服务器端和服务器渲染的“Razor 组件”，这在未来可能是一个假设的东西（因为例如渲染片段在服务器上也能很好地工作）。

因此，我们锁定文件扩展名.razor和名称“Razor 组件”，用于特定类型的 Razor，该版本仅适用于具有嵌入式客户端行为的组件。

@danroth27几乎每个人（包括我）都想要它.blazor而不是.razor那么你为什么要单独坚持.razor 。 改变这一点是否有任何技术挑战？ 或者这只是您和您的团队的偏好？

谢谢你。

正如@danroth27提到的与多个团队协调，我可以想到，VS Team、Razor 团队团队，这可能是一大块工作，每个团队在任务上都有不同的优先级。

我可以看到.razor扩展适合，如果它是一个更通用的东西，它描述了用 Razor 编写的任何类型的组件，比如.xaml如何用于桌面世界中的资源和控件。

假设将来可能的话，您可以使用使用 razor 编写的本机UWP / xaml控件，而不是通过电子的html而是纯本机的，因为 razor 构建控件的命令式风格可能是.xaml's一个引人注目的替代方案

不过，这是一个理论上的例子，在这一点上，您可以说它使用 Razor 组件，但不是在 Blazor 上下文中，而是在像 React Native 这样的本机上下文中，其中事情可能有所不同，例如事件绑定不同，某些 Blazor 特定属性不适用等等...

我认为 Blazor 是一个使用 Razor 组件（ .razor ）的框架，就像 React 作为框架使用.jsx/.tsx进行组件组合一样，就像.jsx/.tsx它可能是通过配置构建系统对.jsx/.tsx文件的操作，可以在其他类似的框架上使用，例如 Vue 和 TKO 如何支持.jsx/.tsx 。

感谢大家对这个问题的反馈。 Razor 组件重命名回服务器端 Blazor 已完成！

出于上述原因，我们决定保留 .razor 扩展名。 我们对这个决定的反馈意见不一。 虽然我们很欣赏 Blazor 对所有事情的渴望，但我们认为当前的扩展已经足够了，我们更愿意集中精力让 Blazor 准备好发布，而不是搅动文件扩展名。 鉴于此决定，我将继续并关闭此问题。

请将标签 feature-Components 也重命名为 feature-Blazor。

亲爱的，我正在使用 vs 2019，我已经安装了 Blazor 上一个版本，我有核心 3 预览版 4，我已经创建了一个 Blazor 项目，现在所有页面都使用 .razor 扩展名而不是 .cshtml，我运行了该应用程序，但给了我正在加载...无需移动到 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 不同的扩展名，即使它没有计划”？

“伟大的技术伴随着巨大的名称混淆”