Aspnetcore: Follow links when disconnecting

[cores-system]

As soon as you have lost contact with blazor.server.js, any transition to the links of the prejudice causes the error 'blazor.server.js:1 Uncaught (in promise) Error: Cannot send data if the connection is not in the 'Connected' State.'

I suggest in the absence of communication with the server to perform the usual transition by reference, without using server rendering. In this case, you do not need to display a window about disconnect, and the normal reconnection will be performed with the page reloading.

[SteveSandersonMS]

@pranavkm This is a good idea. Since you're working on the navigation handling, do you know how feasible it would be to add the further rule "if the client is unable to send the navigation event to the server for the router to handle, just do a full page load directly"?

[SteveSandersonMS]

BTW I don't mind whether it still logs an error too. Perhaps it's best if it does, since it is an error case. Real-world users would not see anything go into the console anyway.

[cores-system]

@SteveSandersonMS , The ability to catch the error is needed so that the user knows why the button / form/ etc etc not work. But if a user is a guest viewing a blog / news for example https://devblogs.microsoft.com/aspnet/, then it is more logical to make a transition to a new page.

That is, the navigation itself should not depend on whether the user is connected to a socket or not.

[SteveSandersonMS]

Navigation has to depend on the socket connection, because the .NET code in the Router makes the choice about how navigation is handled. My suggestion above only applies in the case where the connection is broken and we are just trying to recover the situation for the user.

[cores-system]

I mean links without logic <a href="/conter">conter</a>, during disconnect, we can make a simple transition.

[SteveSandersonMS]

Yes, we're saying the same thing :)

[SteveSandersonMS]

Pranav, this is related to the routing stuff you're currently working on (and disconnection you previously worked on). Do you think this is reasonable to do?

[pranavkm]

Just saw @SteveSandersonMS's comments further up, but this looks like a reasonable implementation. SignalR can tell us of the connection's state and that can be used to determine what to do here.

[JuanRegistry]

This sound interesting but I have some thoughts:

Does this only apply when the user clicks on a link just before you lose the connection? or do you mean that we should be able to click link even if the disconnection has already happened a time ago?

• Currently a disconnection blocks the UI completely and I believe that is on purpose as the server could had being save the user state and if the user continues modifying it then after reconnection there will be some kind of rollback in the data