-
|
Hello. The book touches on the question of how to write complex client applications in leptos. There are 3 options for dynamic collections with complex structures (which make up any even slightly complex client web application). Of which only option No. 2 (Nested Signals) seems good. I'm sorry, but I just don't understand how to write complex web applications in Leptos. I only had experience with React and Dioxus, and there dynamic collections are described directly and naturally.
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
The I've done some pretty significant work to minimize the need to manually dispose signals in 0.7, so compare to those examples on the Oh I've also done some very major work in 0.7 on nested reactivity in general. See the For 3) the answer is "yes" and the mechanics just depend on the details. |
Beta Was this translation helpful? Give feedback.
-
Thanks. Can you at least give me a hint on how to do this?) |
Beta Was this translation helpful? Give feedback.
-
|
Sure! So, all rendering is handled individually by effects that read from signals -- when you pass something reactive into the view (whether that's a single signal or By default every signal read is tracked and every signal write notifies any subscribers, including the renderer, to ensure consistency between the data and the view. If you explicitly want to "tear" (i.e., have the view show something that is different from what the data contains) you can do that by using untracked reads ( let trigger = Trigger::new();
let some_signal = RwSignal::new(13);
view! {
<p>
{move || {
trigger.track();
some_signal.get()
}}
</p>
<button on:click=move |_| some_signal.update(|n| *n = 1)>" 1"</button>
<button on:click=move |_| trigger.notify()>"Show changes"</button>(I just typed this in, apologies for any errors but hopefully it illustrates what I mean) If this isn't what you mean, then give more details about what you're talking about and I'm happy to try to help. |
Beta Was this translation helpful? Give feedback.
Sure! So, all rendering is handled individually by effects that read from signals -- when you pass something reactive into the view (whether that's a single signal or
move || ...closure that reads from a signal), the renderer wraps it in a render effect that will react to any signal reads inside it.By default every signal read is tracked and every signal write notifies any subscribers, including the renderer, to ensure consistency between the data and the view.
If you explicitly want to "tear" (i.e., have the view show something that is different from what the data contains) you can do that by using untracked reads (
.get_untracked()etc) combined with some "trigger" signal that you will…