createRouteAction doesn't do a replace navigation for a redirect to the same URL

[pauloevpr]

When using createRouteAction or createServerAction$ to handle forms, if the server action issues a redirect, the client-side code will always perform a new navigation even if the redirect is to the same URL.

I would think redirects to the same URL would trigger a replace navigation client-side instead.

This seems to be the line of code handling it:

https://github.com/solidjs/solid-start/blob/c1b0b13ee7ed1a52743d68ea4c195876a4c75493/packages/start/data/createRouteAction.tsx#L249

I would imagine this would be the expected behavior instead:

navigate(locationUrl, { replace: window.location.pathname === locationUrl })

[nksaraf]

Should they both be replace?

[pauloevpr]

It seems reasonable to do a new navigation by default for redirects to different URLs. But it would be great if that behaviour could be configurable.

[ryansolid]

I think the problem is a redirect to the same location feels like a reload. So I can see an argument for replace. But I wonder if we should follow what the browser does with a typical Form post to a different URL that redirects back to the page that instantiated it.

[pauloevpr]

For my particular use case, a page reload wouldn't be desirable as it would mean losing the in-memory cached state. But I do see a page reload being useful in other cases.

Perhaps make it configurable?

[ryansolid]

I don't mean an actual page reload. I mean conceptual one. I find it helps to think about these things by looking at native browser behavior. Not that we'd actually reload the whole page.

I guess the problem with this is the browser would add the whole thing to the history, and pressing back would try to submit the form again. I think what is expected here might be no push state. Not even a replace. Just a basic ignore + full page invalidate as the default. Of course it would only invalidate what the action defines if that is provided.

[pauloevpr]

For my particular use case, a simple replace navigation would be good enough.

[ryansolid]

As far as I can tell we fixed this in the router? Navigating to the same URL is a no-op as far as I can see. Trying the TodoMVC example in the repo doesn't produce browser history when JS is turned on. If this is still an issue let me know.