jetli/yew-hooks

UseAsyncOptions::enable_auto() can lead to none of the options set

Ekleog opened this issue · 2 comments

Hey!

I wanted to try out use_async with UseAsyncOptions::enable_auto. So I wrote code like:

    let db = use_async_with_options(
        [...],
        UseAsyncOptions::enable_auto(),
    );
    if db.loading {
        html! {
            <h1>{ "Loading…" }</h1>
        }
    } else if let Some(err) = &db.error {
        panic!("Unexpected error loading database:\n{err}");
    } else {
        let db: &Rc<basic_api::db::Db> = db.data.as_ref().unwrap();
        [...]
    }

As, intuitively, given the async is triggered ASAP, then at least one of the three options must be true.

However, it looks like there is a one-frame delay, and db.loading is set to false at the first run, along with error and data both being set to None.

I'm pretty new to yew_hooks, but… why is db.loading not set to true from the beginning if running with enable_auto? Is that a missing-feature oversight, a bug, or just something that's out of scope?

The initial state is loading=false, data=None, error=None, this is by design for now.

I see, so a PR to change the initial state to be loading = true, data = None, error = None if auto-mount is enabled would be rejected.? (Possibly that'd have needed to go through replacing loading with a function if the false is required for internal purposes)

Well, thank you for yew-hooks anyway! :)

(BTW, I'm also not entirely sure I understand why there's both data and error types, so for the next major version bump I'd also suggest considering just having loading and data fields where if the user wants to return a Result, they'd just have data: Result to match on — or even better, having the returned data be an enum of exactly all the possible states for the future)