The Client project of the Blazor Web App template should also have a Components folder

[danroth27]

The Client project of the Blazor Web App template still has a root level Pages folder. For consistency, it should have a root level Components folder that contains any components in the project.

[SteveSandersonMS]

I looked into doing this, but after looking closely at the templates, I don't think it should have an extra level in the folder hierarchy for Client. It wouldn't serve any purpose.

The reason the server project has this extra level is because it's not a Blazor-specific project - it's an "anything from the whole space of ASP.NET Core", so the Components subdir is to fit in alongside all the unrelated stuff from other tech. The Client project, however, is necessarily purely a Blazor project since it exists for WebAssembly.

If you feel strongly, let me know, but I think things are arranged as well as they can be without making this change.

[gragra33]

@SteveSandersonMS I generally have components that are helpers for pages that would live in the main project. For example, I would break a page into multiple parts and pass the model. I usually have these in a \Component folder. Now, with .Net 8.0 and the new structure, they would live in the 'Component\Component' folder if I kept my current structure when ported over.

Would it not be better to rename \Component to \Blazor so that we can keep our current naming convention? This would avoid any confusion about what the folder is for.

This change would meet current folder naming conventions. For example:

• wwwroot for all things static
• in wwwroot there is a \css folder for all CSS. There is a subfolder \bootstrap for all CSS that is Bootstrap
• in wwwroot we would typically have a \js folder for all things javascript
• in wwwroot we would typically have a \img folder for images
• for Typescript, we would use a \ts folder
• for Sass, we would use a \sass or \scss folder

So for Blazor, IMHO, we should have a \blazor folder for all things Blazor.

Sample structure with the change:

Solution
 |
 +-- wwwroot
 |    |
 |    +-- css
 |    |    |
 |    |    +-- bootstrap
 |    |
 |    +-- img
 |    |
 |    +-- js
 |         |
 |         +-- bootstrap
 |
 +-- Blazor
 |    |
 |    +-- Components (for devs)
 |    |
 |    +-- Layout 
 |    |
 |    +-- Pages
 |
 +-- Controllers
 |
 +-- Pages
 |    |
 |    +-- Shared
 |
 +-- scss
 |
 +-- ts

[danroth27]

I looked into doing this, but after looking closely at the templates, I don't think it should have an extra level in the folder hierarchy for Client. It wouldn't serve any purpose.

The reason the server project has this extra level is because it's not a Blazor-specific project - it's an "anything from the whole space of ASP.NET Core", so the Components subdir is to fit in alongside all the unrelated stuff from other tech. The Client project, however, is necessarily purely a Blazor project since it exists for WebAssembly.

If you feel strongly, let me know, but I think things are arranged as well as they can be without making this change.

I think we still want to add the Components folder. While the client project is Blazor specific it will contain more than just components. It will also contain services, data models, etc. Note that we already update the Blazor WebAssembly project template to have the Components folder, which is similar in many ways to the client project. Also, once we do #46398 the browser build will presumably get the Components folder anyway.

[danroth27]

@gragra33 It actually sounds like the new template folder structure aligns with your current practices. The Components folder that you've been adding is now setup and ready for you in the project templates. It's intended that users will put helper components directly in the Components folder. It sounds like the main difference for you will be that the Pages folder is now also a child of Components instead of a sibling. But note that pages in a Blazor app are components too.

If you're unconvinced and you prefer to use your existing folder structure, you can still switch back to the earlier folder structure if you want. There's no requirement to use the folder structure setup in the templates. The Components folder isn't special - it's just a template convention.

Regarding the proposal to add a Blazor folder, we try to avoid putting the name "Blazor" in APIs and artifacts we ship because names are determined by marketing, and you never know when they are going to want to do a rebranding. So, at least on the Blazor team, we try to insulate ourselves and our users as much as possible from the whims of marketing and use descriptive names instead.

[SteveSandersonMS]

While the client project is Blazor specific it will contain more than just components. It will also contain services, data model, etc

When people add more stuff, they can add whatever folder structure they want. I would strongly recommend organizing by functional area rather than by file type. For example, adding a UserProfile or CheckoutWizard folder containing the combination of services, components, data models, JS files, etc that are specific to that feature. Having a "by file type" view is the sort of mechanical thing an IDE could offer if it wanted.

We're always free to change this later, but it seems nonsensical to put in an unnecessary extra level in the directory hierarchy that doesn't communicate anything and suggests that people are required to organize by file type when they are not.

[gragra33]

When people add more stuff, they can add whatever folder structure they want.

That is true. It's usually the case. I answer lots of questions on programming websites and was just thinking about new developers more so than more experienced ones.

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.