[SmartComboBox] Allow ItemsProvider-like (delegate) way to provide items instead of Url

[hakenr]

Feedback:

While I understand the Url parameter approach you've implemented, it seems to excessively enforce the application's structure. I believe using a traditional ItemsProvider delegate (similar to Virtualize or QuickGrid) and helper services for delegate implementation (such as FindClosest etc.) would be more aligned with Blazor's philosophy. This approach gives developers the flexibility to choose their method of data transportation to the component.

[SteveSandersonMS]

That's certainly a reasonable suggestion.

I did implement it this way at one point, but it can only work with Blazor interactive rendering (not with Blazor SSR, or with MVC/Razor Pages). And even within Blazor, it's pretty much only useful for Server and not for WebAssembly, because on WebAssembly you'd almost always just have to make an HttpClient call to the server to get the items anyway.

Despite the limitations, I do still agree that there are cases where developers would want to do this so I'll put it on the backlog.

[hakenr]

And even within Blazor, it's pretty much only useful for Server and not for WebAssembly, because on WebAssembly you'd almost always just have to make an HttpClient call to the server to get the items anyway.

Yes, you need to make an HttpClient call to the server in WASM, but it should be up to the developer to choose how to do it. For instance, we use generated client proxies where the Blazor client communicates with server facades via gRPC. The MapSmartComboBox() endpoint seems to be an "alien element" in such applications.