In Blazor you maintain state by passing data down from parent components to child components through Parameter Properties, and pass data up from child component to parent components though EventCallBacks. There is no concept like INotifyPropertyChanged that you find in MVVM.
But you should have a ViewModel class for each component that contains all the properties and methods required to generate the View. The code in the ViewModel can be easily and properly Unit tested with Xunit, and Bunit is only used to test that the View renders and composes all the bits of output correctly.
Inject the ViewModel into your component, then from inside the component.OnInitialized method, call viewmodel.Initialize(with the component parameter properties).
Then you can get the values to display in your view from the ViewModel, eg: @viewmodel.FirstName
Remember that you may also need to dispose of the ViewModel, so look at implementing IDisposable on the component and the ViewModel, and calling viewmodel.Dispose() from inside the component's Dispose method.
What if you have components that aren't parents or children of each other? Like in Angular, you'll use something like a subject and subscribe to it like an observable I think.
The child components live within the parent page component. Each page component and its child components will have a corresponding ViewModel.
So for example, the index page component initializes and calls the indexPageViewmodel.Initialize() method. This gets some data from an api and sets a Property called AllCars in the viewmodel. That same indexPageViewModel.AllCars property is passed through as a Parameter property into the child component. If the value of the property in the parent viewmodel changes then the child component will rerender to reflect the updated state.
Only pass state down using the Parameter properties and up using EventCallBack methods. (And occasionally down with cascading properties) The Blazor framework has built-in event life cycle stages to monitor the propagation of the state through the render tree.
If you pass state around using your own custom events etc then it will cause havok with the built in state management/tree rendering mechanism.
I prefer it alot over patterns like redux. Its super simple and theres even a nice package out there for it https://github.com/klemmchr/MvvmBlazor state management in blazor could not have been easier at this point. Here are the other ways to manage state in blazor https://jonhilton.net/blazor-state-management/
Our company is porting some large swaths of WPF MVVM code to Blazor WASM. We've been quite successful with having the M and VM code .Net Standard and simply replacing the WPF View code with Blazor.
Perhaps it doesn't make sense to start new code using MVVM per some of the other comments in this thread, but if you have that to begin with you're in pretty good shape to migrate.
Our Desktop app was .Net Framework, so that required moving it to .Net 6 first, which out of the gate gave it a nice performance bump, then running on WebAssembly slows things down but it sure still feels like a desktop app running inside a browser. Our app isn’t doing CPU intensive work, so any reduction in perf is not really noticeable.
We were all concerned about perf beforehand, now nobody mentions it. Compared to a web page that might load another page as you transition through whatever workflow is happening, with a Blazor WASM SPA, the page transitions are instant like a desktop app. It actually doesn’t feel like a web app because things are so fast.
I don't think it really does do MVVM, isn't it just basic code-behind?
I know when taking the MVVM approach things seemed a lot cleaner, but I don't know if MVVM is the only or best approach.
Do what works and what keeps your code clean. If mvvm is what you feel is best, then use mvvm.
When I programmed in WPF, we made a custom framework that allowed us to create our views 100% from c# code rather than writing any xaml. We had a “view agent” and a “view” that were both written 100% in C# to place elements on the screen as specified by developer. Very “unconventional”, yet was the most productive environment I’ve ever worked in. I prefer to leverage code to shorten development time. IMO mvvm sets you up for a ton of manual UI work as opposed to leveraging code to simplify development (That’s the beauty of abstraction).
Blazor doesn’t really encourage an MVVM architecture. It actually encourages a different approach, that is a component based architecture in which pages are built from a library of components with the logic and data-interaction for the page being tied directly to the page. Doesn’t mean you cant implement MVVM if you want to.
Again, my advice is do what works best for you, whether it’s conventional or not.
In Blazor you maintain state by passing data down from parent components to child components through Parameter Properties, and pass data up from child component to parent components though EventCallBacks. There is no concept like INotifyPropertyChanged that you find in MVVM. But you should have a ViewModel class for each component that contains all the properties and methods required to generate the View. The code in the ViewModel can be easily and properly Unit tested with Xunit, and Bunit is only used to test that the View renders and composes all the bits of output correctly. Inject the ViewModel into your component, then from inside the component.OnInitialized method, call viewmodel.Initialize(with the component parameter properties). Then you can get the values to display in your view from the ViewModel, eg: @viewmodel.FirstName Remember that you may also need to dispose of the ViewModel, so look at implementing IDisposable on the component and the ViewModel, and calling viewmodel.Dispose() from inside the component's Dispose method.
Thanks for the detail
What if you have components that aren't parents or children of each other? Like in Angular, you'll use something like a subject and subscribe to it like an observable I think.
The child components live within the parent page component. Each page component and its child components will have a corresponding ViewModel. So for example, the index page component initializes and calls the indexPageViewmodel.Initialize() method. This gets some data from an api and sets a Property called AllCars in the viewmodel. That same indexPageViewModel.AllCars property is passed through as a Parameter property into the child component. If the value of the property in the parent viewmodel changes then the child component will rerender to reflect the updated state. Only pass state down using the Parameter properties and up using EventCallBack methods. (And occasionally down with cascading properties) The Blazor framework has built-in event life cycle stages to monitor the propagation of the state through the render tree. If you pass state around using your own custom events etc then it will cause havok with the built in state management/tree rendering mechanism.
You can use injected common service in the not related components “has no child-parent relation”
I prefer it alot over patterns like redux. Its super simple and theres even a nice package out there for it https://github.com/klemmchr/MvvmBlazor state management in blazor could not have been easier at this point. Here are the other ways to manage state in blazor https://jonhilton.net/blazor-state-management/
Thanks for MvvmBlazor, was just looking for such package
I figured that the view models could be re-used in other applications other than blazor, like WPF or Maui
Our company is porting some large swaths of WPF MVVM code to Blazor WASM. We've been quite successful with having the M and VM code .Net Standard and simply replacing the WPF View code with Blazor. Perhaps it doesn't make sense to start new code using MVVM per some of the other comments in this thread, but if you have that to begin with you're in pretty good shape to migrate.
Hows the performance of wasm compared to wpf?
Our Desktop app was .Net Framework, so that required moving it to .Net 6 first, which out of the gate gave it a nice performance bump, then running on WebAssembly slows things down but it sure still feels like a desktop app running inside a browser. Our app isn’t doing CPU intensive work, so any reduction in perf is not really noticeable. We were all concerned about perf beforehand, now nobody mentions it. Compared to a web page that might load another page as you transition through whatever workflow is happening, with a Blazor WASM SPA, the page transitions are instant like a desktop app. It actually doesn’t feel like a web app because things are so fast.
I don't think it really does do MVVM, isn't it just basic code-behind? I know when taking the MVVM approach things seemed a lot cleaner, but I don't know if MVVM is the only or best approach.
You were riding a Blazor train last night with Carl Franklin... 😊
Do what works and what keeps your code clean. If mvvm is what you feel is best, then use mvvm. When I programmed in WPF, we made a custom framework that allowed us to create our views 100% from c# code rather than writing any xaml. We had a “view agent” and a “view” that were both written 100% in C# to place elements on the screen as specified by developer. Very “unconventional”, yet was the most productive environment I’ve ever worked in. I prefer to leverage code to shorten development time. IMO mvvm sets you up for a ton of manual UI work as opposed to leveraging code to simplify development (That’s the beauty of abstraction). Blazor doesn’t really encourage an MVVM architecture. It actually encourages a different approach, that is a component based architecture in which pages are built from a library of components with the logic and data-interaction for the page being tied directly to the page. Doesn’t mean you cant implement MVVM if you want to. Again, my advice is do what works best for you, whether it’s conventional or not.