Why hooks?

[remram44]

Taking a quick look, I see that this library uses hooks:

fn app(cx: Scope) -> Element {
    let count: &UseState<i32> = use_state(&cx, || 0);
    // ...
    *count.modify() += 1;

However this is Rust, and we have static typing and traits. A common way to solve a similar problem (e.g. in the various ECS libs) is to simply use arguments, for example for Bevy:

fn print_position_system(query: Query<&Transform>, asset_server: Res<AssetServer>) {
    // not: query = use_query::<Transform>();
    for transform in query.iter() {
        println!("position: {:?}", transform.translation);
    }
}

Wouldn't it be possible to do this for dioxus, like so:

fn app(count: &UseState<i32>) -> Element { // uses Default impl for i32 in this case
    // ...
    *count.modify() += 1;
}

Apologies if this has been discussed, or if you get a lot of critics targeted at hooks already (I know they are a polarizing issue). I thought it was worth discussing.

[autarch]

Your two examples aren't the same thing. In the first, app creates the count state and it's entirely contained in the app component. In the second, something else creates it. By leaving out the "something else", you've elided the key decision of which components create and manage state.

[remram44]

In both cases you are requesting it from the framework. Whether you are declaring it via a function argument or a call to a "context" object, something else is holding it and is in charge of giving it back to you and managing its lifecycle.

[autarch]

In both cases you are requesting it from the framework. Whether you are declaring it via a function argument or a call to a "context" object, something else is holding it and is in charge of giving it back to you and managing its lifecycle.

Are you saying that the framework would create the &UseState<i32> in the second case? That may be possible, but it'd require macros, since Rust doesn't have any sort of compile-time or runtime reflection (AFAIK).

[remram44]

bevy doesn't need procedural macros as you can see.

There is currently a need for a little macro, to generate the trait impl for different numbers of arguments, but it's otherwise plain Rust traits.

[autarch]

I don't think I'm following what you're proposing clearly enough, and I don't have any experience with Bevy.

[remram44]

How could I make it clearer? I posted example before/after snippets.

[jkelleyrtp]

Hooks are a natural progression React - we want people familiar with React to save their knowledge. It's also useful for chaining result into eachother and writing new hooks without the NewType pattern.

It does have its downsides - IE there's no typesafe way of writing components that use hooks.

Particular for the example you posted, there's no way of setting an initial value that depends on another value.

[remram44]

The argument type using Default for the initial value is just an example -- it could be initialized from props. That does require a newtype as you note.

If imitating React as closely as possible is a goal, then looking for alternative doesn't make sense I guess.

[jkelleyrtp]

The argument type using Default for the initial value is just an example -- it could be initialized from props. That does require a newtype as you note.

If imitating React as closely as possible is a goal, then looking for alternative doesn't make sense I guess.

I will mention that a lot of Dioxus 0.1 is about getting React parity - but I would love to see new patterns evolve that solve some of the common problems people have with React. I know some people have been experimenting with a "type safe Scope" that transforms between use_ calls that enforce the rules of hooks.

We could also do something that combines a bunch of hooks together to enforce better safety. So, it's not to say that we don't want alternatives, but they would need to fit into the structure's we've built already.

For instance, I want to add signals into Dioxus so you can drop in SolidJS/Sycamore style components alongside regular react components. This would need to integrate into the existing framework but would be an improvement in many ways.