dsuryd / dotNetify

Simple, lightweight, yet powerful way to build real-time web apps.
https://dotnetify.net
Other
1.17k stars 164 forks source link

Navigation to 404 when reconnect #275

Closed DG4ever closed 3 years ago

DG4ever commented 3 years ago

Since Version 3.7 I have the problem, that the my app will navigate to 404, when dotnetify reconnects to the server. Do you have any ideas why this could be happening?

It happens on .NET Core 2.2 as well as on .NET 5.0.

With 3.6.2 everything is fine.

image

dsuryd commented 3 years ago

The routing logic was tightened up since v3.7. Paths that don't match the route templates will redirect to 404.html when previously it just halts. If you're not using dotnetify-router, make sure you're using version 3.7.1 (#246). You can also disable the 404 behavior by adding this to the main js: dotnetify.react.router.notFound404Url = null;

DG4ever commented 3 years ago

Thank you for the fast response.

I am using dotnetify routing and on initial load or on reload it is working as expected. But when server connection is lost and the hub is reconnected, it gets routed to 404.

With dotnetify.react.router.notFound404Url = null; it reconnects correctly, but I would like to undestand the problem.

dsuryd commented 3 years ago

Let's add dotnetify.debug = true to get more info from the router.

DG4ever commented 3 years ago

Ok here the output:

image

This seems okay to me until the page get's routed to 404.

BTW: Is there a way to access route param directly? Currently I am accessing it via

this.vm = dotnetify.react.connect('ReworkPage', this, {
    headers: { GroupName: props.vmArg["RoutingState.Origin"].split("/").pop() }
});

I then pass the header via custom Middleware to MultiVM Instance in order to fill the GroupName with the route param.

hubContext.CallerContext.Items.TryAdd("Headers", hubContext.Headers);

Not sure if this is the correct way.

dsuryd commented 3 years ago

The reconnect triggers the routing, but, and this looks like a bug, it uses the base URL instead of the URL from the address bar. You didn't specify the route template for path ="", so it's going to go to 404.

Can you try adding this and reenable the 404:

dotnetify.connectionStateHandler = state => {
  if (state == "connected") dotnetify.react.router.urlPath = document.location.pathname;
};

BTW: Is there a way to access route param directly?

That, or use document.location.pathname.

The way you use the headers is fine, ~but there's a simpler way: add a new property, let's say "MyGroup", then implement public GroupName => MyGroup;. Pass the group name through connect option vmArg: { MyGroup:<group name> }.~

DG4ever commented 3 years ago

Can you try adding this and reenable the 404

Thank you, this fixes the reconnect problem

That, or use document.location.pathname.

Yes I know that method, but I was thinking of something like this: https://ui.dev/react-router-v5-url-parameters/ So that I can access the id from the pattern /rework(/:id) directly. BTW: Is the syntac of the UrlPattern explained somewhere?

The way you use the headers is fine, but there's a simpler way: add a new property

I am aware of this method, but this won't work for the GroupName of the MulticastVM as the GroupName needs to be set before creating the viewmodel instance. So I think the middleware is the correct solution here?

dsuryd commented 3 years ago

Yes I know that method, but I was thinking of something like this: https://ui.dev/react-router-v5-url-parameters/ So that I can access the id from the pattern /rework(/:id) directly.

Thanks, I'll consider this.

BTW: Is the syntac of the UrlPattern explained somewhere?

It was briefly mentioned in the routing doc. It seems common and intuitive that I didn't elaborate more, but let me know if it needs more write-up.

I am aware of this method, but this won't work for the GroupName of the MulticastVM as the GroupName needs to be set before creating the viewmodel instance. So I think the middleware is the correct solution here?

You're right, I stand corrected. I'll consider extending the connect options to pass group names so it won't require writing your own middleware.