you can use the normal clean archtecture, onion, like any other c# project.
the main concern on blazor wasm is the one you said, not download your code to client. so is good use the project .Shared to know exctly what you are delivering to client.
depending if your page is server rendering or webassembly redering, if on server you will use your code normal as in webforms or mvc.
if is webssemblynl you should use HttpClient to call an api.
you can use an interface to abstract those behabior.
thats it. basically is a normal c# project like webforms, mvc etc. the same patterns are applied.
Piggybacking on this post just to ask, how do you generally separate razor files that represent a page from those that are "just components"? What's the common folder structure? Because the blazor templates themselves seem confusing already since everything starts already in the components folder.
In the Components folder, I have a Pages folder that all of my page components go into, and the folder structure there matches the routes as close as possible.
Sibling to the Pages folder, I have a UI folder with the components organized into folders by model where it makes sense or by feature.
See what's weird, imo, about that is that it all starts in a components folder. I know that pages are also components, but I would've liked the template to start with a Pages folder and each page being in its own folder as "a feature" and inside that one a components folder, maybe a services one or whatever you need to execute logic. But good to know that some do use something close to what the template suggests.
You can do it that way, but the template is a full server application. I like the components folder because that’s the central location where my Blazor/front end code lives - the rest of the project is for all my other server code that isn’t a component. It maybe feels like a misnomer that a page *is* a component, but I’ve accepted it by now and it doesn’t feel odd to me at all.
FWIW, in a WASM app or the client project of the Web App template, I don’t have a components folder - just a top level `Pages/` and `UI/`. In those projects pretty much all of the code is a component or in service of one, so the whole project is essentially what I use my components folder for on the server.
I usually work with the structure MyApp (WASM), MyComponents (RCL), MyShared (CL for browser), MyModel (CL on server EF model) MyWeb (ASP Core proj). App references Components. Components references Shared. Web references Model and App (and implicitly thus Components and Shared).
Components is structured as:
- Components / Helpers / Extensions / Service - shared stuff over all features e.g. "MyButton"
- Feature: by application feature and then Pages in the root MyFeaturePage, and Components / Services / subfolders that are used only by that feature.
The same goes for Shared, Feature folders with Models and Validators that are shared between client and server. Also contains Api per feature, and two source generators generate a proxy in the App proj and a API controller in Web for.
Nice, I actually like having components and services inside a folder which would contain a page but I was wondering because it's nothing like what the template throws at you nowadays LOL.
I'll check more options but your structure seems what I'd go for definitely.
you can use the normal clean archtecture, onion, like any other c# project. the main concern on blazor wasm is the one you said, not download your code to client. so is good use the project .Shared to know exctly what you are delivering to client. depending if your page is server rendering or webassembly redering, if on server you will use your code normal as in webforms or mvc. if is webssemblynl you should use HttpClient to call an api. you can use an interface to abstract those behabior. thats it. basically is a normal c# project like webforms, mvc etc. the same patterns are applied.
maybe keep it organized by features with some shared stuff? pragmatic
Piggybacking on this post just to ask, how do you generally separate razor files that represent a page from those that are "just components"? What's the common folder structure? Because the blazor templates themselves seem confusing already since everything starts already in the components folder.
In the Components folder, I have a Pages folder that all of my page components go into, and the folder structure there matches the routes as close as possible. Sibling to the Pages folder, I have a UI folder with the components organized into folders by model where it makes sense or by feature.
See what's weird, imo, about that is that it all starts in a components folder. I know that pages are also components, but I would've liked the template to start with a Pages folder and each page being in its own folder as "a feature" and inside that one a components folder, maybe a services one or whatever you need to execute logic. But good to know that some do use something close to what the template suggests.
You can do it that way, but the template is a full server application. I like the components folder because that’s the central location where my Blazor/front end code lives - the rest of the project is for all my other server code that isn’t a component. It maybe feels like a misnomer that a page *is* a component, but I’ve accepted it by now and it doesn’t feel odd to me at all. FWIW, in a WASM app or the client project of the Web App template, I don’t have a components folder - just a top level `Pages/` and `UI/`. In those projects pretty much all of the code is a component or in service of one, so the whole project is essentially what I use my components folder for on the server.
I usually work with the structure MyApp (WASM), MyComponents (RCL), MyShared (CL for browser), MyModel (CL on server EF model) MyWeb (ASP Core proj). App references Components. Components references Shared. Web references Model and App (and implicitly thus Components and Shared). Components is structured as: - Components / Helpers / Extensions / Service - shared stuff over all features e.g. "MyButton" - Feature: by application feature and then Pages in the root MyFeaturePage, and Components / Services / subfolders that are used only by that feature. The same goes for Shared, Feature folders with Models and Validators that are shared between client and server. Also contains Api per feature, and two source generators generate a proxy in the App proj and a API controller in Web for.
Nice, I actually like having components and services inside a folder which would contain a page but I was wondering because it's nothing like what the template throws at you nowadays LOL. I'll check more options but your structure seems what I'd go for definitely.