Function Component and Hooks V2

[futursolo]

I am creating this as a discussion as I need to prioritise SSR Hydration and I would appreciate some feedback before working on this.

Rationale

The Function Component and Hooks v2 tries to solve the following issues:

• Hooks are not enforced in order / calling position
  (The calling position lint should apply to not only inside of function components, but also inside of user defined hooks)
• Hooks can be called anywhere (with runtime panic when called outside of a hook.)
• Function Component uses thread local / globals in rendering
• use_ prefix is not enforced.

There're still issues to be solved (mainly around macros) but in general should be an improvement over the issues stated above.

Design

The following trait will be added:

pub trait Hook {
    type Output;

    fn run(self, state: &mut FunctionComponentState) -> Self::Output;
}

To define a hook, one must use the #[hook] attribute macro:

#[hook]
pub use_my_data() -> Data {
    ...
}

The #[hook] macro rewrites the hook to: (similar to how async fn works)

pub use_my_data() -> impl Hook<Output = Data> {
    ...
}

This renders hook calls outside of a function component or user defined hook useless as a hook is not run until run is called and it's not possible to acquire FunctionComponentState without the help of procedural macros.

When hooks are used inside a function component or a user defined hook, #[function_component] or #[hook] macro checks if it's possible to call the hook in its defined position, it will output a compile error if it's not possible to call a hook in that position.

If it's possible, the hook call will be rewritten:

fn run(&self, props: &Self::TProps) -> HtmlResult {
    // state is borrowed once during the rendering cycle.
    let mut state = self.state.borrow_mut()

    // original call
    let data = use_my_data();

    // after rewrite
    // Compiler will complain type mismatch if use_my_data() is not tagged with `#[hook]`
    let data = ::yew::functional::Hook::run(use_my_data(), &mut state);

    // ...
}

state is only acquired once as a mutable reference in the fn run of a function component and will be defined with Span::mixed_site() so it's not accessible from outside of the procedural macro.

How to handle macros

This design has elected to not apply any special handling with macros (with the exception to the macro-style hooks) until proc_macro_expand stabilises.

Hence, it's currently possible to write code like the following:

#[function_component]
fn Comp() -> Html {
    // macros can emit a return statement and it's not visible to parent macros as it's evaluated after parent macros.
    maybe_return!();
    let data = use_my_data();

    todo!()
}

See: rust-lang/rust#90765

Compatibility with macro-style hooks

This design also is also compatible with macro-style hooks.
The only requirement is that the macro-style hook must define a normal hook call at the end of their emitted token stream so they can be evaluated like function-based macros:

let data = ::yew::functional::Hook::run(use_my_data!(), &mut state);

[voidpumpkin]

Thank you for writing all this down. Looks good, cant wait for the future PR!

[ranile]

I like this approach. We can even sneak in file!(), etc for diagnostics in debug mode. How would this look like from the call site? Just a call to use_my_hook() in a function component will work?

One implementation detail to note here is that all of the hooks tests will need to be refactored as they don't use the proc-macro.

[futursolo]

The only user visible change should be the #[hook] attribute.

[ZainlessBrombie]

Random little idea: How about rewriting hook calls so that they create a struct Marker; inside a block scope and use the type_id to uniquely identify the call site? Since each Marker would get it's own unique type id.

That would allow them to be freely placed and would alleviate the need to move the calls.

self-written hooks would do the same, and there would be a sort of "hook TypeId-Marker stack"

[WorldSEnder]

This still has one challenge: Identifying hooks.

Yes, this currently done by assuming all (unqualified) function calls starting with use_ are hooks. Not optimal, but it's simple enough to work around the edge cases.

[futursolo]

Unfortunately, this wouldn't work. Unlike other dynamic language that structs (classes) are defined at runtime when the code is executed, Rust structs and type ids are determined at compile time.

For the following code:

use std::any::TypeId;

fn main() {
    for _ in 0..5 {
        let type_id = {
            struct MyStruct;
            TypeId::of::<MyStruct>()
        };

        println!("{:?}", type_id);
    }
}

The output is:

TypeId { t: 15862695144524765897 }
TypeId { t: 15862695144524765897 }
TypeId { t: 15862695144524765897 }
TypeId { t: 15862695144524765897 }
TypeId { t: 15862695144524765897 }

So it's not possible to distinguish each call in a loop.

[ZainlessBrombie]

To make sure I am not misunderstanding you:

As I understand, you'd like to make a macro that does two things to the function, it checks if all hook calls are legal in their position (not in a loop, not conditional) and then transform them to ensure they are called as hooks.

I suggest that if we identify the hook invocation uniquely, it is alright to call it conditionally or in a loop. Calling them in a loop would always reach the same macro state, since it is the same line - this is not possible in e.g. react so there is no expectation for another behavior.

One way to achieve this is to rely on Rust's unique TypeId
Since we are transforming Code using a proc macro, we could just use a different number as an identifier each time too. This may even be better since now no map is needed, indexing into an array is enough.

[futursolo]

As I understand, you'd like to make a macro that does two things to the function, it checks if all hook calls are legal in their position (not in a loop, not conditional) and then transform them to ensure they are called as hooks.

Affirmative.

I suggest that if we identify the hook invocation uniquely, it is alright to call it conditionally or in a loop.

Negative.

There're (at least) 2ways to interpret a hook in a loop:

1. Hooks in the same position are treated as the same state for each iteration.
2. Hooks in the same position are treated as different states for each iteration.

However, disregard which way should be picked (which seems to be a difficult decision), both ways have flaws:

Hooks in the same position are treated as the same state for each iteration.

Like demonstrated above, for all 5 iterations, the state is identified as to have the same TypeId, which means that they are the same state. So this design is achievable with TypeId.

However, if hooks are allowed inside the loop, then it will be allowed to capture the control variable:

for i in 0..5 {
    // This same state has been called 5 times in the same render function call.
    // How does it function? Do we just initialise it once and return the value for subsequent calls?
    let content = use_state(|| i);

    // This effect has been called 5 times before a render can happen.
    // Which previous state should `i` be compared with?
    // Should the effect be refreshed for all iteration?
    // (a.k.a: run destructor and constructor for all iterations)
    // if so, when?
    // Usually an effect will not be called until the component becomes rendered.
    use_effect_with_deps(|| { ... || {} }, i);
}

Hooks in the same position are treated as different state for each iteration.

A way to reliably differentiate the state in the same position for each iteration is needed. This is not possible to do with TypeId.

A counter is not reliable:

for i in 0..5 {
    if (0..10).choose(&mut rng) % 2 == 0 {
        continue;
    }

    // how to determine if states are the same or not for subsequent renders
    // if whether and how many times this piece of code will be called is random?
    let content = use_state(|| i);
}

BTW, this proposal has been implemented in the master branch already.

[ZainlessBrombie]

BTW, this proposal has been implemented in the master branch already.

Oh ok! Sorry, I saw this conversation and thought this was still ongoing 😄
Well that resolves that. A macro that checks if the position is definitively not wrong / it's a solid solution. I think it is possible to allow hook usage outside of loops but conditionally in a branch, but I don't think it's a fundamental feature :)
Thank you for taking the time to write that down!