Decouple Data Retrieval from Views in Blazor WASM?

[SerratedSharp]

When using a Blazor Standalone WASM app, how do I decouple data retrieval for a particular route from the view?

When using non-Blazor WASM I usually would handle a client side route by first retrieving data, then passing it as a model to the Razor view, and this allows the view to be used in a variety of scenarios and simplifies the view so it isn't having to parse route parameters that are purely needed for the data.

public class CardController(LuceneSearch luceneSearch, CardDatabase cardDatabase)
{
    public async Task<string> GetCardSummaryList(string query = null, int page = 0)
    {
        // retrieve model data from API
        List<CardSummaryModel> cards = await GetCardSummaryModels(query, page);
        // Render to HTML using Razor template
        var html = await View.Render<RclViews.CardSummaryList>(
            new() {
                ["Cards"] = cards
            });
        return html;
    }

I have been down the path of using non-Blazor WASM for a couple years, but I thought I'd give Blazor Standalone a try as my prototype WASM MVC framework seemed like it was starting to converge with Blazor functionality. I was surprised that all the examples I see are retrieving data inside the view through Initialize.

I know controllers seem like a server only concept to some people, but if you look at other client-side MVC frameworks, client-side controllers still have a role in ensuring logic, data, and views are composable.

In the example, the controller action decides for this given route and route parameters how to retrieve and compose the data, and can orchestrate which view should be displayed. The View doesn't need to care about the query parameter, which may or may not be fairly complex(in this case it's a Lucene search query, so requires some dedicated code to handle), all it needs to know is what data it should display. This makes it easier to break the problem into little acorns and not have anything dealing with more than it needs to.

Certainly the view could take a query parameter, and call GetCardSummaryModels itself, and that might seem simple, but now that view is only appropriate whenever the cards it needs to display are defined by a query. Other scenarios define a different list of cards that isn't generated from a query, and if the View is defined by a query parameter, it can't be reused in those scenarios. It seems like I have to create fake parent views for different routing scenarios, who's purpose is to act as a controller action for these different scenarios, and have no content other than holding a <CardSummaryList>(or whatever the view it routes to is) and containing @code that would usually be in a controller action. That approach means one *.razor file per route, instead of allowing a Controller to define actions that handle mutliple routes, which seems a little bloaty. In MVC there's a right sizing of these kinds of things that balances controllers that aren't too big and focused on a topic with not having a proliferation of many controllers.