I really enjoy leptos and I've really enjoyed your videos. I hope you will find the time to create more content like this in the future. WRT your discussion of using effects to update signals: Essentially timing issues with event spaghetti lead to undefined UI states. This can be prevented by data flowing in only one direction: event -> signal -> effect -> dom. Updating signals in effects violates this one-way data flow rule. This is the motivation behind the Elm architecture and tools like redux.
thank you for the video Greg! Please do more. As a beginner in Leptos, it is helpful to get further context and examples in addition to what the book provides.
I have a question, where is information about deploying a leptos development on an IIS server? it does require any special configuration or just up and run? how to set the handlers?
What would you do if you need an effect for doing a side effect that in the end provides some information which you want to get into the reactive system, i.e. pass to a signal?
I think it depends… if it’s some kind of async action where a signal changes, you do something in response, and some time later that returns a new value you want in a signal, then an effect is reasonable (or create_resource or create_action) This also avoids the synchronous gotchas in that Show example where you can’t reason about the order it’s rendering. If it’s synchronous then it sounds like the second signal could be derived.
Is this unsub resub pattern still true with effects in the latest leptos? I know that you were in the stream when milo and ryan were going over some of the algorithm optimizations milo had done in reactively. And looking into the leptos source code, I can see some of the same wording/patterns. AFAIK, solidjs doesnt follow this full unsub resub pattern and it is tracked in another way - but I could be wrong. I am also not sure if these patterns directly apply when using rust instead of being forced to use JS. Great video btw
Do you mean on the NodeRef::get() calls? It's safe to .unwrap() or .expect() there in an event listener - they are filled during the `view` macro itself - but if you're really unwrap averse you could do something like match (first(), last(), use_last()) { (Some(first), Some(last), Some(use_last)) => ... _ => {} } The other unwraps are coming from a `use_context` that I know I provided, and from a user's code that was buggy! If you mean the unwrap in the user code then yes, a safe version of this would've been to use .unwrap_or(), but I still wouldn't recommend the "write to a signal from an effect" approach because it adds the overhead of creating an extra signal and extra effect.
I really enjoy leptos and I've really enjoyed your videos. I hope you will find the time to create more content like this in the future. WRT your discussion of using effects to update signals: Essentially timing issues with event spaghetti lead to undefined UI states. This can be prevented by data flowing in only one direction: event -> signal -> effect -> dom. Updating signals in effects violates this one-way data flow rule. This is the motivation behind the Elm architecture and tools like redux.
thank you for the video Greg! Please do more. As a beginner in Leptos, it is helpful to get further context and examples in addition to what the book provides.
Thanks. This makes much clearer what are the distinct purposes of "signals" and "effets", what they are meant for.
dude youre a machine! Thanks for everything youre doing!
This video is very informative on not just create_effect, but effects in a reactive system in general, both fine and course grained.
Good job Greg! I learned stuff today ☺️
This was such a well presented video and very insightful
keep up the great work
"Do people read docs, idk"
The Leptos book sent me here lol
this framework is insanely powerful, almost a paradigm shift.
great presentation, sounds best to avoid calling set_signal inside an effect
Thanks for the explanation of how create_effect works 🤗
14:55 Exactly, that's what I thought the whole time you coded the memoization. 😅
I have a question, where is information about deploying a leptos development on an IIS server? it does require any special configuration or just up and run? how to set the handlers?
What would you do if you need an effect for doing a side effect that in the end provides some information which you want to get into the reactive system, i.e. pass to a signal?
I think it depends… if it’s some kind of async action where a signal changes, you do something in response, and some time later that returns a new value you want in a signal, then an effect is reasonable (or create_resource or create_action) This also avoids the synchronous gotchas in that Show example where you can’t reason about the order it’s rendering. If it’s synchronous then it sounds like the second signal could be derived.
Is this unsub resub pattern still true with effects in the latest leptos? I know that you were in the stream when milo and ryan were going over some of the algorithm optimizations milo had done in reactively. And looking into the leptos source code, I can see some of the same wording/patterns. AFAIK, solidjs doesnt follow this full unsub resub pattern and it is tracked in another way - but I could be wrong. I am also not sure if these patterns directly apply when using rust instead of being forced to use JS. Great video btw
How could this be written without the unwrap() at all? unwrap_or() would cause unnecessary re-rendering, right?
Do you mean on the NodeRef::get() calls? It's safe to .unwrap() or .expect() there in an event listener - they are filled during the `view` macro itself - but if you're really unwrap averse you could do something like
match (first(), last(), use_last()) {
(Some(first), Some(last), Some(use_last)) => ...
_ => {}
}
The other unwraps are coming from a `use_context` that I know I provided, and from a user's code that was buggy! If you mean the unwrap in the user code then yes, a safe version of this would've been to use .unwrap_or(), but I still wouldn't recommend the "write to a signal from an effect" approach because it adds the overhead of creating an extra signal and extra effect.
❤️
😂 No effects is like saying no event handlers and no callbacks. Do people really not see the similarity?
This guy does not do well with being wrong lol lots of rage