Microsoft should either make adding a .razor file more automatic or change its recommendations

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

If I am mistaken, I would like to know. But I understand that Microsoft recommends Blazor programmers have a separate .razor, .cs, and .css files for each Razor component. The separate files separate concerns (SoC) and fulfill the single responsibility principle (SRP). I think even with a Razor file having HTML, CSS, and @code all in the same file, Blazor supports SoC and SRP. The automatically linking separate .cs and .css files to a .razor file carries SoC and SRP further.

However, what happens when you add a .razor file in Visual Studio Community is a contradiction. When you add a .razor file, you get just one file set up to contain CSS (you have to add <style>), HTML, and CS (@code). Furthermore, if you want the automatic linking in Blazor Webassembly, you have to uncomment a line in the index.html file.

To go with the higher level of SoC and SRP, you add a .cs file and a .css file in two additional steps. And then, you always have to add the word "partial" before the class keyword.

So, if Microsoft indeed promotes SoC and SRP to a higher degree, all three files should be added in one step when you add a .razor file. The keyword partial should already be inserted. You should have @code in the .razor file, but it should be commented out. If a programmer wants @code, they can comment it out. And the programmer can optionally optimize by deleting code-empty .css and .cs files. The automatic linking should not be commented out in the index.html file. Instead, it should be a comment explaining that you can disable the linking by commenting out or deleting "the following line." And, very importantly, CSS in the linked .css file should override styling in all Blazor built-in components.

But let us say Microsoft recommends using Blazor in a very simple way. Then, Visual Studio Community should do precisely what it does: Generate one .razor file that is ready to go. But it should also have <style></style> already included in the file. Then, programmers writing more complex code can enable the three separate files to link automatically.

I favor the second approach of promoting Blazor as a simple way to accomplish most things, with Blazor satisfying the needs of more advanced programming wherever needed or desired.

So, I would sum up that if Microsoft recommends the simple, all-in-one .razor file (when simple will do), Microsoft should express it more. Or Microsoft could keep the SoC and SRP as the well-known Microsoft recommendations and make some important enhancements ((1) Blazor components affected by CSS in a separate file, (2) get all three files ready to go when you add a .razor file).

Thank you for providing this feature request facility.

---

Original Comments

Feedback Bot on 12/17/2024, 06:17 AM:

Thank you for taking the time to provide your suggestion. We will do some preliminary checks to make sure we can proceed further. You will hear from us in about a week on our next steps.

[javiercn]

Thanks for contacting us and thank you for bringing up this important discussion about Blazor component organization and file structure. Your observations highlight an interesting conversation around developer experience and architectural choices.

It's important to clarify that Blazor offers the ability to use code-behind files primarily because some developers prefer to separate their code into different files, but the framework doesn't promote or enforce one organizational style over another. The decision to support both approaches reflects our commitment to accommodating different developer preferences and project needs.

The separation of CSS and JavaScript into individual files isn't driven by a desire to promote any particular architecture, but rather because it significantly simplifies the complexity of creating and maintaining the associated tooling. When CSS and JavaScript are embedded within Razor files, the compiler would need to deeply understand these languages to process features like scoped CSS effectively. Currently, the build system handles this by using a dedicated CSS parser that operates independently from the Razor compiler - the Razor compiler treats CSS and JS as text content and only needs to identify the appropriate boundaries.

Regarding the partial keyword requirement you mentioned, this exists because the Razor language compiles to C# code and must follow C# language rules. Without the partial modifier, you would end up with two separate classes sharing the same name, which would create conflicts. The partial keyword enables the compiler to merge class definitions across multiple files. The compiler doesn't distinguish between Razor-generated code and manually written code, and we don't plan to create a separate mechanism for this.

We genuinely don't favor the "everything in one file" approach over separate files, nor do we recommend sprinkling style tags throughout your components. The CSS associated with components and views is scoped to that specific file, and you would typically place your general styles in regular CSS files while reserving .razor.css files for component-scoped styles.

I believe there is currently an issue tracking the potential addition of an item template that includes a code-behind file, which represents the kind of enhancement we'd be willing to consider. This would address your concern about making the multi-file approach more convenient.

Regarding scoped CSS, it's worth noting that this feature generates some debate within the community. CSS already provides existing mechanisms for handling scope

• cascade layers help avoid specificity conflicts.
• @scope rules enable applying styles to specific portions of the DOM tree.

These native CSS features make scoped CSS somewhat redundant in modern development.

Ultimately, the ability to collocate CSS and JavaScript with your Razor markup is a convenience we offer for developers who prefer that organizational style, rather than an explicit recommendation. We generally avoid prescribing specific approaches to code organization beyond providing options that support popular development patterns. Our goal is to give you the flexibility to structure your applications in the way that works best for your team and project requirements.

I hope this helps clarify our position.

[indinfer]

@javiercn

Thanks for the detailed explanation. It definitely broadened my perspective.

On reflection, I think that having to remove partial when it’s not needed would be worse than the current requirement to add it for code-behind. Perhaps a middle ground could be to offer both “Class...” and “Partial Class...” options in the Add menu. Then again, I realize that adding more options to the menu risks cluttering the UI. An alternative might be to keep the menu as-is but include a checkbox (unchecked by default) to insert the partial keyword if desired.

Stepping back, I now see this isn’t about Microsoft promoting one architectural approach—it’s more about enabling a range of developer preferences. I suspect my earlier impression came from the specific courses and videos I used to get up to speed with Blazor, which may have emphasized their preferences in style and architectural choices. So, after taking this broader view, the issue matters much less to me now.