Template per Response Code

[hblunck]

Hey,

would it be possible to define a template per response code? This would make it easier, to render a different template, e.g. in case of validation errors of API input or other situations (e.g. item not found ...).

I understand that it would likely also be possible to have that logic within the template (if the response object is made available), but it might be need lees boilerplate code to be able to see that directly in the Python code.

Henning

[volfpeter]

Hi,

I'd recommend implementing an exception handler middleware that converts exceptions to HTML responses. The middleware has access to the request, it can check whether it was an hx-request or not if it matters for your use-case.

---

FastAPI must resolve dependencies (and validate the route's data inputs) before calling the route, so if the API's input is incorrect, FastAPI will raise an HTTPException with 422 status code before calling the route (and its fasthx wrapper). As the fasthx decorator is not executed, it can not solve such an issue.

Regarding the response code: if your route returns a Response object, FastHX decorators will simply return it without doing anything. If your route doesn't return a Response object and you define status codes in the FastAPI path operation decorator, that's out of of reach for FastHX, so it can't do anything.

---

I assume you only want to differentiate between a successful response and error cases. If the returned error HTML is fairly generic (part of its content could come from HTTPException or a custom subclass with extra properties), then a middleware would be a good solution for you. This lib could implement a generic, ready to use middleware, but I'd need more user feedback (and some consensus) on how it should work. This could also be an APIRouter-specific thing, then again, a specialized APIRouter subclass could be added to the lib, but without input from several users on how it should work, I'm hesitant to add such a feature. And finally, as outlined above, a route-specific decorator couldn't handle input errors, because the request doesn't reach the decorator, so it can not be a complete solution on its own.

Peter

[volfpeter]

Closing for lack of response.