Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Navigation to 404 when reconnect #275

Closed
DG4ever opened this issue Feb 21, 2021 · 7 comments
Closed

Navigation to 404 when reconnect #275

DG4ever opened this issue Feb 21, 2021 · 7 comments

Comments

@DG4ever
Copy link

DG4ever commented Feb 21, 2021

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
Copy link
Owner

dsuryd commented Feb 21, 2021

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
Copy link
Author

DG4ever commented Feb 21, 2021

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
Copy link
Owner

dsuryd commented Feb 21, 2021

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

@DG4ever
Copy link
Author

DG4ever commented Feb 21, 2021

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
Copy link
Owner

dsuryd commented Feb 21, 2021

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
Copy link
Author

DG4ever commented Feb 22, 2021

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
Copy link
Owner

dsuryd commented Feb 22, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants