Embracing Component Architecture

Embracing Blazor means accepting a new paradigm for developing web applications. Traditional web development revolved around the MVC (Model-View-Controller), MVVM (Model-View-ViewModel), or some slight variation of them. These paradigms still exist as viable options for developing web applications. Blazor and other modern component frameworks, such as Angular or React, are component-based. This type of architecture blends certain responsibilities that would traditionally be isolated. Employing Blazor means letting go of traditional development methodologies by cementing the component as the key first-class citizen in your application.

When I first ventured into component-based frameworks, I made the mistake of forcing old architectural ideas. I learned that components have no real parity to older concepts. This stems from the idea that Blazor, like Angular and React, is stateful, whereas MVC or Razor Pages is stateless. Trying to force stateless architecture into something that assumes state obviously does not work well. I attempted to pull out logic into "handlers" or controllers and, moreover, to create View-Models for each component. It was messy, convoluted, and ineffective. It was then I began to embrace components as isolated and self-contained. Suddenly, everything made sense.

You can imagine your application as a jig-saw puzzle. Each piece can live separately. But each can be combined with other pieces that fit together to create small understandable sections. When the puzzle is completed, every piece comes together to create the final product. The puzzle is a composition of all its individual pieces. Component-based frameworks are no different than a jig-saw puzzle. Each component can live by itself. You can pass data to it via its parameters and it may render said parameters, it may render a button to be clicked, or it may fetch some data that may be passed to another component. The key idea is that every component contains all of its logic necessary to perform its intended purpose.

The glaring issue with components is that while separation of concerns is less of an issue, it still is an issue. The biggest complication arises when components are too big and have too many responsibilities. It takes some experience to determine what should be and should not be an individual component, and this is where science becomes art. Some general rules to follow: (1) even though Blazor is a stateful framework, most components should be stateless; (2) stateless components are simpler and, therefore, easier to test; and (3) components that deal with fetching or posting data from an API are typically separate from components that deal with the UI. I recommend instilling a culture of adaptability and a willingness to learn and refactor accordingly.

Component-based architecture can be a frustrating concept to grasp initially. If your development history is based in traditional web development methods (where separation of concerns is supreme) thinking in terms of components can feel strange. But like learning anything new and valuable, the time saved in the long-run is worth the awkward first steps. The best action is to embrace this new architecture without trying to force incompatible or outdated methods. Embrace components as self-contained units of work that can live alone with cats, but also can place nicely with humans. The more you become comfortable with this new methodology, the more you will understand how to structure and balance your components. Blazor is great when you keep to the design intent of the framework.