Is early breaking in components using hooks possible?

[tdooms]

I am struggling to properly implement the following pattern inside a component.

pub fn component() -> Html {
    let user = use_login() {
        Some(user) => user,
        None => return html!{ <Redirect />}
    }
    let result = use_some_expensive_computation_or_sensitive_data(user);
}

What is the intended way of "early" breaking when using hooks? When I logout from such a component, it raises an error that the order is violated. The documentation states that this can only happen if a Suspense is returned but it seems very inelegant to define a "placeholder" use_future and then redirect in the fallback. This design is also only possible if the fallback is not used for intended purposes such as loading screen etc..

Furthermore, the harsh restrictions on hooks are (afaik) not properly documented. From some digging around it seems to be related to restricting users from using hooks in loops and so forth but no real reasoning is given.

[kirillsemyonkin]

Real reasoning behind hook limitations is that they are attached to the component in question, and have to know the order they are called in.

You can think of each hook call being indexed like in following pseudo-rust-code:

let a: A = use_a(); // 0 stores A
let b: B = use_b(); // 1 stores B
let c: C = use_c(); // 2 stores C

If we break the order, the system will not be able to reason about the types of the values that get stored:

let a: A = use_a(); // 0 stores A
if something {
    let b: B = use_b(); // 1 stores B
}
let c: C = use_c(); // 2 stores C, but when `!something`, this would be 1, except 1 sometimes stores B, not C...

Macros #[hook] and #[function_component] operate in statements and would not be able to reason about loops, even if its range goes from constant to a constant, which means it is unable to deduce indices of hook calls inside loops. If you were to write a macro like for_const!, which would unroll the loop into simple statements as a result, you would be able to call a hook in your pseudo-loop.

I believe early exits should be a thing. If they are not, this is what this discussion/issue is about.

#[hook]
fn use_short_circuit() -> Result<(), HError> {
    let h1 = use_h()?;
    let h2 = use_h()?;
    do_something(h1, h2);
    Ok(())
}

[tdooms]

Indeed as you mentioned, my main point was about the lack early breaking.

Early breaking, as far as I understand, is prohibited at runtime. The code snippet you provided does not work. I have created a small toy example below in which there are technically no conditional hooks but gives an error that each operation is not in order.

The use_hook hook uses the first hook result to return early if its value is odd.
When the button from the main component is pressed, the following issue is raised.

As this behaviour is already accepted when using a suspense, I feel like this should be always accepted, or maybe I am missing a technical detail. Should I create an issue about this or what do you think?

use yew::*;

#[hook]
pub fn use_maybe(value: u32) -> Result<(), ()> {
    match value % 2 {
        0 => Err(()),
        1 => Ok(()),
        _ => unreachable!()
    }
}

#[hook]
pub fn use_hook(value: u32) -> Result<u32, ()> {
    use_maybe(value)?;
    let internal = use_state(|| 42);
    Ok(*internal)
}

#[function_component(Component)]
pub fn component() -> Html {
    let state = use_state(|| 0);
    let value = use_hook(*state).unwrap_or(*state);

    let onclick = {
        let state = state.clone();
        Callback::from(move |_| state.set(*state + 1))
    };

    html! {
        <>
        <button {onclick} text="increment" />
        <div> {value.to_string()} </div>
        </>
    }
}

fn main() {
    yew::Renderer::<Component>::new().render();
}

[kirillsemyonkin]

The error mentioned in your comment lead me to the assert that it is checked. Right under it is the assert for suspense, which is different from regular behavior. The comment above all checks is a bit hard to understand, but I think it means that Err(_) is expected behavior in some cases (I don't think you can return Result from a component other than HtmlResult?).

My brain is making connections that the counter is global for current component for all hook calls, so if there is a conditional check inside the hook, it won't be able to reason about the call indices like I previously mentioned:

#[hook]
fn use_short_circuit() -> Result<(), HError> {
    let h1 = use_h()?; // 1
    let h2 = use_h()?; // 2
    do_something(h1, h2);
    Ok(())
}

#[function_component]
fn SomeComponent() -> Html {
    let _ = use_short_circuit(); // 0
    use_something_else(); // 3 if nothing failed or h2 failed, 2 if h1 failed
    html! {}
}

The reason suspense works seems to be the fact that a suspense at any hook call should stop the entire component from proceeding, killing the hook counter at some point. Failing this condition may lead to some asserts to be triggered.

Leading from this discussion is the clearly the problem with a total counter being used (if that's the case, all my thoughts here are just a hunch), rather than a per-hook counter, latter allowing for hooks to short-circuit.

[hamza1311]

You can write short circuiting with a wrapper component:

#[component]
pub fn Parent() -> Html {
    match use_login() {
        Some(user) => html! { <WithUser {user} />,
        None => html! { <Redirect />}
    }
}

#[derive(PartialEq, Properties)]
pub struct WithUserProps {
    user: User
}

#[component]
pub fn WithUser(props: WithUserProps) -> Html {
    todo!()
}

You may want to use a higher order component that is generic and can be used anywhere short circuiting with the user is required. That can be done by having the component take in a generic component and props for that component, matching against the user and calling that component.

#[component]
pub fn WithUser<C: Component>(props: C::Properties) -> Html {
    let user = use_user();
    match user {
       Some(user) => html! { <C ..props },
       None => html! { <Redirect /> }
    }
}

[kirillsemyonkin]

@futursolo

welcome to express your opinion in discussions

We are in discussions. If you meant for me to send a PR renaming that concept to "Wrapper Components" or something (as per the article I linked), well, then I understood you now.

does not help with the situation and discredits the original contributor's work.

I actually linked my sources as to why one should refrain from using such code (although it is true that many of their things are React quirks, most common problem I heard is "HOCs are really hard to debug"). I don't really know what "discrediting" means in here, if we are discrediting the solution then I think that might've been my goal, but if you mean I'm trying to offend someone or something of the sort then sorry, I believe nobody would take "cursed" as something serious/non-humorous in any context lol. I do not want any beef with any of the Yew's maintainers or contributors (although Mr. Torvalds somehow does fine with it lol), so let's be friends, okay?

[hamza1311]

html! { <C ..props /> }

Actual HOC and not whatever is mentioned in Yew docs. Absolutely cursed.

The article describes the solutions more than the problem. Can you explain how HOC are bad in Rust? Remember: Rust's type system offers much better guarantees than what JS/React can provide.

[futursolo]

"Actual HOC and not whatever is mentioned in Yew docs."

I feel you wanted something to be done or wish to express a strong opinion about this feature or documentation.
However, I cannot tell what you wish to achieve from the sentence alone is "renaming that concept to 'Wrapper Components'". (If it was.)

The line you quoted is props spreading and it is not required to use props spreading in HOC.

I actually linked my sources as to why one should refrain from using such code

The original comment didn't include any links to "absolutely cursed", so I can only interpreted this as a comment to the documentation or feature itself.

Actual HOC and not whatever is mentioned in Yew docs. Absolutely cursed.

If you didn't mean to be offensive, then all good. However, it is important to understand that all other contributors and maintainers are volunteering in their free time to contribute to Yew. Regardless of whether their solution is good or bad, ideal or less so, we should still be respectful to the effort they put into making these contributions.

[tdooms]

Thanks so much for the solution @hamza1311 ! I hadn't thought of that. This is probably due to the fact that this section is under "struct components" which I hadn't read as I thought it wouldn't be useful to me. It actually seems that the whole advanced/struct_components section is filled with pages that are more generally useful. If you want I can make a PR that "modernizes" these pages by updating the examples to function components and putting them under a better-named section.

However, your solution works for my simple example. But in my case, I actually have lots of consecutive fallible operations: verify user, and then two fetch requests. The first fetch request requires the user data and the second depends on data from the first. In this case, using three wrappers becomes cumbersome and less readable (both fetch requests have different dependencies, so I cannot fuse them into one future). I think @kirillsemyonkin was also referring to this issue with his statement that the ? operator solves this in a more elegant manner.

Sadly, I lack the knowledge to propose a straightforward solution for this kind of pattern.

[kirillsemyonkin]

@futursolo

The line you quoted is props spreading and it is not required to use props spreading in HOC.

I quoted the <C> bit, as well as props spreading. This is what Higher Order Components represent - a component that takes in component definition (a component type) and makes a component out of that. Props spreading kind of result from that, since you gotta pass the props somehow to the child of the type C. It is similar to Higher Order Functions, where a function takes in another function, here - a component takes in another component (I'm trying hard to make the distinction that what it takes in is not HTML).

The original comment didn't include any links to "absolutely cursed"

My fault, although I really expected that an edit would show up ASAP, as well as somehow put an expectation that everyone would be reading and replying to latest version of the comment. This is not Discord with their real-time edits, but I don't know if I should really blame GitHub here, since they are trying to solve kind of different problems.

I can only interpreted this as a comment to the documentation or feature itself

No, not at all. We are having a discussion related to the problem posed and the solution suggested, current Yew documentation barely has anything to do with that.

[kirillsemyonkin]

@hamza1311 Actually, I can't, so I was really shocked when you did at least something that resembled React HOCs. Rust type system guarantees that they do not happen, since you cannot split props into two halves and give one half for the HOC to consume and the other half for the child components or child HOCs. If you really wanted that React HOC behavior, you would have to use something like HashMap<String, Box<dyn Any>>, which... clearly shows that its not a good idea.

I can imagine that passing a function which would let user manually build props from whatever HOC gives could be a solution:

#[derive(Properties, PartialEq)]
pub struct WithUserProps<C: Component> {
    pub id: UserID,
    pub props: Callback<User, C::Properties>,
}

#[component]
pub fn WithUser<C: Component>(WithUserProps { id, props }: &WithUserProps<C>) -> Html {
    let user: User = use_user(id);
    match user {
       Some(user) => { // i noticed your example ignored `user` - this is the part of the problem
           let props = props.emit(user);
           html! { <C ..props /> }
       },
       None => html! { <Redirect /> },
    }
}

But for this, a better solution might be using Render Props:

#[derive(Properties, PartialEq)]
pub struct UserSwitchProps {
    pub id: UserID,
    pub render: Callback<User, Html>, // consider calling this `children` in Yew 0.21, as it is supposedly possible to write the render callback as a child
}

#[component]
pub fn UserSwitch(UserSwitchProps { id, render }: &UserSwitchProps) -> Html { // i couldnt think of a better name
    let user: User = use_user(id);
    match user {
       Some(user) => render.emit(user),
       None => html! { <Redirect /> },
    }
}

Another solution might be using contexts (letting children to do use_context::<User>() themselves):

#[derive(Properties, PartialEq)]
pub struct WithUserProps<C: Component> {
    pub id: UserID,
    pub props: Callback<(), C::Properties>,
}

#[component]
pub fn WithUser<C: Component>(WithUserProps { id, props }: &WithUserProps<C>) -> Html {
    let user: User = use_user(id);
    match user {
       Some(user) => {
           let props = props.emit(); // we gotta make props somehow
           html! {
               <ContextProvider<User> context={ user }>
                   <C ..props />
               </ContextProvider<User>>
           }
       },
       None => html! { <Redirect /> },
    }
}

But for this, a better solution might be using Wrapper Components (called HOCs in the docs, I kinda wanna name them Provider Components though):

#[derive(Properties, PartialEq)]
pub struct UserProviderProps {
    pub id: UserID,
    pub children: Children,
}

#[component]
pub fn UserProvider(UserProviderProps { id, children }: &UserProviderProps) -> Html {
    let user: User = use_user(id);
    match user {
       Some(user) => {
           html! {
               <ContextProvider<User> context={ user }>
                   { children.clone() }
               </ContextProvider<User>>
           }
       },
       None => html! { <Redirect /> },
    }
}

[kirillsemyonkin]

Wow, my GitHub is really broken lmao
It showed me two empty comment boxes whenever it felt like it, both being a new comment rather than a reply