The effects of Blazor component size on maintenance and reusability
When I first started working with Blazor I loved the fact that everything in Blazor was a component and components could be nested in one another. It seemed like a great way to organize a page, keeping the code cleaner and easier to maintain. However I hadn’t developed a strategy for applying it.
The team I was working with had a complicated page to build. It seemed like we could divide it up into functional sections and create a component for each. We took this approach and it allowed us to divide the work between team members, however there was something we didn’t consider. The components needed to interact with each other, that is changes in one component needed to trigger changes in another component on the same page. Of course there is a way to do it using callback parameters in the child components that triggered methods in the parent component which then triggered methods in the other child components. This approach worked however it wasn’t all that easy to follow so maintenance was not as easy as we had hoped.
The problem with this approach was it was harder to follow the path through the code as the complexity of the components and parent page grew. Also the big components were fairly complex and very specific so there was a very low chance of reusing them. Which is something you hope to be able to do with a component. So, other than having a fairly clean looking parent page and allowing multiple developers to work on parts of the page at the same time without fear of having a merge conflict when checking in, there wasn’t a strong benefit to this approach.
This experience has led me to believe that components should be kept small. That is they should encapsulate markup and code that is likely to appear in many places in the application. A simple example would be a label combined with an input such as a label and a specific type of input like an integer input. Add some code you would commonly use with an integer input like code to enforce minimum and maximum values. Then include minimum and maximum parameters and you have a nice reusable component that can provide some handy additional features.
I’ve been applying this small component strategy with good success. It has reduced the time it takes to build a page, reduced the noise on the page, and made the application easier to maintain. I plan on creating a number of future posts on the design of some narrowly targeted simple components with handy time saving features.
