Better developer experience when using State in error code paths

[matze]

While the current transformation of Err(impl IntoResponse) into a valid response works well for API-like use cases it is less suitable for old school multi page applications. In those use cases both successful and error response contain rendered HTML which often requires access to the state in order to render appropriately (e.g. required templates, template data etc.).

As of now, handlers would have to do something along these lines to use ergonomic ? together with template rendering:

pub async fn some_page(State(state): State<AppState>) -> Result<impl IntoResponse, impl IntoResponse> {
    async {
        // some fallible operation
        let _ = tokio::fs::read_to_string("foo").await?;
        Ok::<_, anyhow::Error>(GoodPage::from(state))
    }
    .await
    .map_err(|err| {
        ErrorPage::from(state, err)
    })
}

This is an eye sore and just boilerplate. I know of HandleErrorLayer but I have a hard time getting it to work, i.e. extract the State and return some rendered page.

[matze]

@jplatte you asked me on Reddit to open a discussion here. Is there anything on the roadmap?

[jplatte]

Sorry, life has been very busy. I think what @mladedav wrote is the sort of thing I'd recommend here, since there is nothing on the roadmap for now in terms of new features / changes to make something like this easier.

In particular, you could have your error type (assuming you use a single error type across your application) insert a response extension, with a middleware then using that to replace the response (body) the handler generated with the rendered error template.

[matze]

Thanks for the feedback (also to @mladedav). I guess that could work but it also feels slightly icky but I guess all possible solutions are icky to some degree.

[mladedav]

The current design calls the provided handler and immediately turns the returned value into Response so if you want to construct something like this, you'll probably want to do that directly in the handler.

You can create something to wrap your handlers to construct the responses to have less boilerplate, but then you have to still call that on each handler.

One thing I can think of you could theoretically do is to create a dummy Response and put any information you need inside its Extensions and then have a middleware convert all Responses with this extension into rendered pages.