Rules to Better Blazor - 3 Rules
Get started with Blazor here https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor
When creating Blazor components that communicate with web APIs it is often tempting to inject the
HttpClientand use it directly to send requests. While this is quick and easy to accomplish, this tightly couples the component to the
HttpClientand the specific implementation of the web API. The downside of this tight coupling is that the component cannot be easily refactored for breaking changes (e.g. routes, payloads, querystrings, auth, etc) then the blast radius of changes can be quite substantial. The problem grows even further if accessing the API from multiple components. Another downside is that the component is no longer unit testable. Integration tests will be necessary which will require more effort to implement.
Following the Dependency Inversion Principle (DIP) from the SOLID principles means that we should favour coding towards an interface rather than concrete implementations.
Using an abstract client interface to interact with a web API has multiple benefits. One major benefit is that the component is decoupled from the concrete implementation of the web API client. Decoupled Blazor components can be unit tested with a mock implementation of the web API client. The decoupled concrete implementation of the web API client can also be tested in isolation without any UI concerns, and the code is more reusable in that it could be packaged and reused in other applications without any code duplication.)
Due to Blazor using C#, your client and server can share the same model library - sharing behavior and data.
This will reduce the amount of code you need to write, and make it easier to maintain.
To share your classes between the client and server, just create a class library and reference it in your client and server projects.
See https://github.com/bradystroud/BlazorCodeSharingExample as an example.