How are we supposed to leverage InteractiveServer ?

[DavidThielen]

According to @javiercn (thank you for the feedback) in this post, the purpose of InteractiveServer is to get as much of the page up as quickly as possible from the first call to OnInitializedAsync(), and then on the second call, then populate the page with the data in the DB.

This way the user gets a page in under ½ second. All the lists and grids are empty, all the fields have prompts but no data. But the page framework is displayed as they wait for it to be populated.

Ok, great idea. Except...

According to this (also asked here - no answer yet), it may not be called twice. It may only call OnInitializedAsync() once. This means on any call to OnInitializedAsync(), I must read the DB and build a fully populated page.

Which brings me back to my original question - what is the value/purpose of InteractiveServer? It may change how Blazor builds & renders a page. But there is no change on the programming side, except we lose cascading parameters.

And it means it will take longer to deliver the final page because when OnInitializedAsync() is called twice, then all those DB calls are called twice and that's slower.

To sum up, I understand and agree with your point that there's value in delivering a data free page very quickly. I just don't see how InteractiveServer delivers that. Can you please explain how this delivers the empty page faster? (I can see how you could do it if OnInitializedAsync() was always called twice - but it isn't.)

??? - thanks - dave

[MariovanZeist]

the purpose of InteractiveServer is to get as much of the page up as quickly as possible from the first call to OnInitializedAsync(), and then on the second call, then populate the page with the data in the DB.

Let me try and clarify this a bit
The main difference between InteractiveServer, InterActiveWebAssembly and InteractiveAuto is where the HTML content is generated.

Interactive Server will mean that HTML content is generated on a server (which then while using a SignalR connection will send updates to a browser to update that HTML) So most (if not all) of your UI code is running on a server

Interactive WebAssembly will mean that HTML content is generated inside a web browser (which then uses API calls for example to retrieve the data to display), In this mode most of your UI code will run inside a web browser

InteractiveAuto is a hybrid of these two approaches.
More details here

When using Interactive Server or Interactive Auto You do have 2 modes, either with Prerendering enabled (the default) or Prerendering disabled.
And you can get a quicker response when you enable prerendering, but this is not the main purpose of using Interactive Server

[DavidThielen]

@MariovanZeist Again thank you. So Interactive Server is basically Blazor server side. New name, same thing (mostly). And prerendering is an option to get the skeleton HTML up sooner.

But I'm still left struggling with it will call OnInitializedAsync() twice, I'll be reading from the DB twice, and so my initialization will take twice as long.

I'm clearly missing something because this makes no sense to me. Why does it call OnInitializedAsync() twice? Not it calls twice because the rendering engine needs it, but why a design where the database loading will be called twice?

thanks - dave

ps - I have a feeling that someone will eventually explain how there's a big win in calling OnInitializedAsync() twice and then it will all make sense (and the heavens will open up, the angels will sing, ...)

[MariovanZeist]

@DavidThielen
Let me clarify a bit more.

OnInitializedAsync() isn't called twice, it's called once per component instantiation. So what you see is in the "prerender" stage the component is created, and the normal life cycles are called (including OnInitializedAsync()).
Then after prerendering is over, the component gets destroyed, and the component gets recreated, and again the normal life cycles are called (including again a call to OnInitializedAsync()
So this gives the illusion of it being called twice, but it gets called once per component instance.

Also this "prerendering" only takes place when the user initially starts the application (by entering its URL) or when the developer calls NavigationManager.NavigateTo() with the parameter forceReload set to true.
When inside the Blazor application and navigating to other pages inside the application the runtime will not do any prerendering.

This might not answer your question directly but hopefully gives a little more insight into the inner workings.

[DavidThielen]

@javiercn So is InteractiveServer the ver 6/7 server side or the ver 6/7 WASM? Or is it some hybrid? I am presently using server side and I see advantage in having a session/circuit for the life of a user's session, keeping all the authorization on the server, instantiating a DbContext on every event, etc. I understand why some people prefer WASM, but I personally prefer server side.

I've been assuming InteractiveServer is the new server side - is that wrong?

thanks - dave

[javiercn]

InteractiveServer + Global interactivity = ServerPrerendered (in 6/7)
InteractiveServer(prerender: false) + Global interactivity = Server in (6/7)

Anything where Global interactivity is disabled, is a new SSR + Enhanced navigation + "Component Islands" mode, where we only start a circuit when you decide to render a server component (and we remove it after you navigate away)

[javiercn]

I am presently using server side and I see advantage in having a session/circuit for the life of a user's session, keeping all the authorization on the server, instantiating a DbContext on every event, etc.

This is a list of all the reasons why Blazor Server is great, but has other trade-offs, hence why there's also wasm. Up to 8.0 you made this decission upfront and at build time. In 8.0 you get the choice to mix and match, and make the decision at runtime.

[MariovanZeist]

@javiercn

There is a bit of missing context, I think @MariovanZeist is referring to it in the context of client side navigation (classic blazor wasm/server) while Blazor Web also offers a mode where navigation is handled on the server (enhanced nav)

You are correct. I hadn't thought of enhanced navigation, as all my Blazor apps are SSR (with prerendering disabled 😊btw), and I hadn't delved into the new bits as much as I should.
And yes @DavidThielen I now see what you mean, sorry for that.

[DavidThielen]

@MariovanZeist No need to apologize. I think we're all trying to figure out exactly what is going on and to a greater or lesser degree guessing as best we can. Thank you for your guidance.

[javiercn]

Reading the same data from the database twice, not only slows down the final complete render, but it slows down the static rendering. There's no win to doing this that I can see and a big loss.

You still get to see the content faster than if you render a page, download the script, negotiate the connection and start a new circuit. One is doing 2 steps (initial request + db query) vs 4 steps (initial request, script, negotiate, websocket, db query), it's physically impossible for it to be faster.

[DavidThielen]

@javiercn (moved prev reply up where it was intended).

Yes I agree on static being faster and a great thing to push up as quickly as possible. Everything around this all makes a ton of sense to me except that it calls OnInitializedAsync() for the first pass static rendering. If that first pass had a new event OnStaticInitializedAsync() called and only the second pass called OnInitializedAsync() then this would all make beautiful sense to me.

Does my question on this one very specific issue make sense? What am I missing here? Why did they call OnInitializedAsync() for the static rendering?

thanks - dave

[javiercn]

Because having 2 separate events will make components not work by default in static rendering, which is not what you want the majority of the time.

If you don't want to render anything during prerendering you can detect that condition and avoid querying your DB. For example you can use [CascadingParameter] public HttpContext { get; set; } and do something like:

if (HttpContext is not null) {
_queryResult = await db.EntitySet....;
}

and handle _queryResult being null within your view code to render Loading... or some other placeholder.

It's up to what your app wants to do.

[DavidThielen]

@javiercn Is the cascading parameter being null guaranteed to work ongoing? I assumed that was the way it's presently implemented but not a specified part of the implementation and therefore might not be true in the future. One thing I've learned over my decades programming - don't depend on side effects of an implementation because that will almost always bite you in the ass.

But if that is guaranteed, then I have a solution that makes me happy. I still don't like the way they did this, but I can then work around it and not read the DB twice.

thanks - dave

[javiercn]

I've also learned to never say never, but for the foreseeable future, we don't plan to make that work on wasm or interactive server scenarios.

We are also likely adding an API to make the context the component is running in available via a cascading parameter explicit, so that you can pivot on it as part of 9.0 instead.

[DavidThielen]

We are also likely adding an API to make the context the component is running in available via a cascading parameter explicit, so that you can pivot on it as part of 9.0 instead.

That will make me very very happy - and that's what matters :)