redirect to different route_handler from a route_handler

[krikkiteer]

Often i find myself after processing some user-request that i want to return a different page
than the one the user is on right now.

for example, after editing a user (/usermanagement/{uid:int}/edit ) i want to redirect to the usermanagement-index-page, which i can do with a redirect of course...

However - i'd like to "internally" reference the other routehandler and spare myself the unnecessary overhead of redirecting, and making the user retrieve more files than necessary again to load the whole page.. (especially since im using htmx to only return the necessary bits and pieces.)

Is there some internal_redirect function which i just overlooked ? Before i just added some route_handler_cb-function which i referenced then from all http_route handlers, but this is very repetetive and every call needs to be adapted to changes introduced by dependency-injections or other parameters..

Anyone can point me in the right direction ?

[provinzkraut]

There's no "internal redirect", but you can use app.route_reverse to retrieve the path for a route handler by its name, and supply that to your redirect.

[krikkiteer]

first of all - thanks for the very quick reply...

yes - i found that already. i just hoped there was a better solution ;)
since there is the dict of current-routehandlers in the app ( or rather one can get the handler by name via get_handler_index_by_name ) i'm only missing some way getting that handler to handle() the current request instead...

that's where i got stuck though...

[provinzkraut]

No, there isn't, and there's a good reason for that as well. It's actually not as simple as you're making it sound, and offering such a capability would probably introduce a lot of unexpected behaviour.
There's a whole lot more that happens between making a request and calling your handler function (middlewares, dependencies, all that stuff), and calling one handler with the context of the other would likely cause a lot of issues.

There's also the aspect that redirects are more transparent, both to the user and the developer, and that using a lot of "internal redirects", I would say, is indicative of improper design of an application. If I am on /usermanagement/1234/edit, and save my changes, being served the content of /usermanagement under the same URL, is not only confusing, but also messes with e.g. browser history and caching. You actually do want a redirect there.

---

For your specific problem, I'd recommend 2 things:

• Design your HTMX such that it does not require a full page reload after receiving a fragment. For example, instead of doing a redirect, you could initialise a load from the appropriate endpoint to only get the fragment you need
• Don't put the logic in your route handlers. This makes it easier to reuse the logic part, e.g. rendering some fragment based on a set of inputs, across different route handlers

[krikkiteer]

thanks - i agree that a lot more is happening here ( dependencies and middleware and so on).. that's exactly why i was looking for a way to jump into that resolution of the responsehandler..

however i do not agree that a redirect is "better" here.. it introduces a lot more overhead in regards of communication.
if it is done like you describe it - yes - than its bad.. but with htmx you push the respective resulting url into cache and so on, to no history or caching problems arise if used correctly.

i will go back to having separate functions which i call from the routehandlers (as i did before). i guess i just have to live with the adaptions necessary which i was trying to avoid.

thanks in any case for diving into this and trying to provide a solution - much appreciated.