-
-
Notifications
You must be signed in to change notification settings - Fork 732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nonreactive examples for hooks were not compilable as written #2337
base: main
Are you sure you want to change the base?
Conversation
59e683d
to
4b096ee
Compare
Notably: for the example, I did not call |
} | ||
|
||
#[component] | ||
fn Blog(id: i32) -> Element { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really good use case for ReadOnlySignal<i32>
. We automatically convert T
to ReadOnlySignal<T>
in the props so it will work out of the box with the router and it will be reactive without the extra use_reactive
hook
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use_reactive is good for non-reactive state that is created in the middle of a component like this:
let state = use_signal(|| 0);
let doubled = state() * 2;
use_effect(use_reactive((&doubled,), |(doubled,)| println!("Manually manipulate the dom")));
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that makes sense, however 2 questions then:
- Is that distinction documented somewhere? After this PR gets merged (in some form), I already intend to update https://dioxuslabs.com/learn/0.5/reference/use_resource with a link to the example and an explanation
- If it is already done with props, so should it happen with the
#[component]
approach as well? As in, should this just work without theuse_reactive
or explicitReadOnlySignal
at all? -- Oh wait, or do you mean if I markReadOnlySignal<T>
in the component args, I just don't have to wrap it withReadOnlySignal
when passing in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Is that distinction documented somewhere? After this PR gets merged (in some form), I already intend to update https://dioxuslabs.com/learn/0.5/reference/use_resource with a link to the example and an explanation
Not yet 🙂
- If it is already done with props, so should it happen with the
#[component]
approach as well? As in, should this just work without theuse_reactive
or explicitReadOnlySignal
at all?
The conversion happens when you use the component if you explicitly use ReadOnlySignal<T>
in your props or #[component]
.
// Because value is a signal, it is reactive and any reads will automatically add the signal as a dependency to use_effect, use_resource, etc
#[component]
fn Comp(value: ReadOnlySignal<i32>) -> Element {None}
Comp {
// A new signal is created here
value: 0
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will update the example, and also add documentation around this.
My code was out of date, so I missed b6d3da2 -- but I still caught one more, and added an example. Also tweaked the comments.