❔ Blazor .NET 8 RenderModeInteractiveAuto - fetch data via API
Blazor WASM: use
HttpClient to call service (co-hosted or external)
Blazor Server: interactivity invokes code on server, virtual DOM, blah blah
Ok so how do I write a component that can fetch data for both modes?
Component authors should avoid coupling a component's implementation to a specific render mode. Instead, component authors should typically design components to support any render mode or hosting model...https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0 two ideas: 1. read some static property at runtime to determine the mode (or a hacky equivalent of this) Good: doesn't couple component to a dependency Bad: doing control flow like this means some path will always be unused in a component, looks kinda hacky and probably bug prone 2. inject an interface instead to do data fetching into a component, one with a server concrete implementation and a client concrete implementation, and register the client service in the wasm Client project and the server service in the Server project Good: seems like the "right" way to do it Bad: couples to an interface (not a huge problem since im not a component library author and still I imagine component library authors don't need to have a concrete fetch from web api impl that often). im gonna jump in and try #2 but i thought i'd ask first because I thought I'd see this in docs or a sample or something, but the samples still just have hardcoded data
ASP.NET Core Blazor render modes
Learn about Blazor render modes and how to apply them in Blazor Web Apps.
25 Replies
a fair response would be to ask "ok so what is the question here?" but I kinda just want a sanity check that #2 makes sense and is something you'd do if you were greenfielding a project
I'm really not following here
you're asking about render modes
but then somehow we hop over to questioning how to communicate with the server?
or, just, how to fetch data, in general?
server and client have different ways to fetching data, and when you use auto-mode the mode being used is not determinely known
but it's also convenient to write components in a way that supports both modes
for the basic Counter interactivity example, it's pretty simple, since the framework handles all of the complexity for you
A) why should server and client have different ways of fetching data?
B) why are you mixing server and client in the first place?
A) client uses
HttpClient to fetch data from a web API. client parses data, uses it to update DOM. with server, the DOM diff is calculated on the server and then sent to the client to process, so DOM calculation and fetch/persist service don't have to be on different machines, so you don't need to make fetches in the browser and you don't need HttpClient.
for example, if you have a blazor wasm app that calls a web API method that retrieves data from a database with EF core, with blazor server, you could just inject the DbContext and use it directly in a componentwhy wouldn't you need to use
HttpClient?
ah, okay
yeah, that seems a little silly to mebecause the browser receives DOM diffs over a signalR connection
you're gonna create double the work for yourself to make two implementations of all your data fetching logic
sorry didn't mean to cut u off
nah, it's fine
yeah true but im converting a blazor wasm static site to be a subapp on my blazor .net 8 in a container site so I don't rlly wanna discard the logic for the existing components i've built for wasm
you don't have to discard anything
just
you have an API
and you have a Blazor projects
in fact, i actually have a weird setup where i reuse some of the components for a browser extension, so there's a chance i'll be having both in wasm and server in prod
there's no reason the Blazor project can't call into the API
whether it's server-side or client-side
if you really wanna put in the extra work for this "optimization" then yeah, your option #2 is the right one
me, I'm not convinced it's worth it
ur not wrong
but since my endpoints basically just call C# code
im like
why not
but I'm also not convinced that Blazor Server deserves to exist
so, maybe I'm a little biased
i started on this because I got some whatever IJSRuntime error using my code used for my wasm static site in my .net 8 blazor site but i probably just need to change a lifecycle method or two. and then if I get the time maybe i'll try #2
but tbf
this is a personal project
and I think #2 does seem pretty cool lol
that's how other client/server protocol libraries work
gRPC for example
just, not in the context of mixing client and server code in the same app
sorry but what is "that" in this sentence?
separate client/server implementations of an interface, injected via DI
oh wow, crazy
I always assumed it was something more insane
gRPC?
well, those in general, but yeah
I remember Unity has some type of crazy thing with Attributes and requiring you to end your method with certain names
I don't see how that's related
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.