Support Result type in Html rendering functions?

[Hpmason]

Question
As far as I can tell, there's no support for Result types in HTML rendering functions. A large majority of Rust's ecosystem is built around Result types, so I feel adding support for return Result types would make things more ergonomic and avoid tons of .unwrap()s in rendering functions. If Rust panics, it crashes the program and stops any rendering. The only thing that tells you there was a panic is in the dev tools console.

I think to improve ergonomics and the development process, it would be beneficial to provide Result based versions of these functions. The functions could either convert the error to Html or use that error for displaying the error on the page instead of the log to console. I personally think using the error to generate Html is the most useful and flexible way.

Maybe I'm thinking about this in the wrong way since I don't have a lot of experience with frameworks like React, but from the other things I've used in Rust, it just seems to conflict with other libraries I'm used to.

Questionnaire

• I'm interested in fixing this myself but don't know where to start*
• I would like to fix and I have a solution
• I don't have time to fix this right now, but maybe later*
  *Depends on the method and complexity of changes needed

[WorldSEnder]

Unless some recipe comes along that everybody can agree on, I don't see a one-way-fits-all solution to this. Besides, I also don't think it would save too much code overall. In nightly, you can enabled try_blocks to write something like

#![feature(try_blocks)]

#[function_component]
fn MyComponent() -> Html {
    let html_result: Result<Html, MyError> = try {
        let some_api = maybe_failing()?;
        todo!("normal display")
    };
    html_result.unwrap_or_else(|err| {
        todo!("display error")
    })
}

similar workarounds should be possible with a stable rust compiler (although I have not tested how this interacts with hooks, to be fair. It would be interesting to know if they still just work as expected).

[futursolo]

Maybe I'm thinking about this in the wrong way since I don't have a lot of experience with frameworks like React, but from the other things I've used in Rust, it just seems to conflict with other libraries I'm used to.

Allowing returning errors from components means that error handling no longer needs to be handled on the spot but to be delegated to a specific parent component in the component tree. I think this helps to reduce the boilerplate in the application and we should eventually support this.

There have been some discussions around allowing returning errors in components and adding error boundary component to Yew between maintainers and contributors on discord.
However, there were some unsolved questions on the design of the error boundary / result.

Consider the following code:

#[function_component]
pub fn Comp() -> HtmlResult {
    let user = use_user()?;

    Ok(<div>{format!("Hello, {}!", user.name)}</div>)
}

#[function_component]
pub fn App() -> Html {
    let on_catch = |e, reset| {
        log::error!("{:?}", e);
        reset();
    };

    html!{
        <Catch<E> oncatch={on_catch} fallback={html!{<div>{"Something went wrong."}</div>}}>
            <Comp />
        </Catch<E>>
    }
}

1. Should errors should be typed or allow any error?

   • If the error should be typed, how do we convert errors from third-party libraries to be the error type of the application?
   • If any error is allowed, how does the user exhaustively match all error kinds?

2. Should the error boundary be catch all or only catches specific type?

   • If the error boundary is typed, it means that it could be painful to use as you may need many error boundaries.
   • If the error boundary is any typed, how do we allow specific errors to be passed through (not catching)?