mirror of
https://github.com/leptos-rs/leptos
synced 2024-11-10 06:44:17 +00:00
docs: add examples of synchronizing signal values (#1121)
This commit is contained in:
parent
af7e1d6a0f
commit
1c236d74b6
1 changed files with 42 additions and 0 deletions
|
@ -2,6 +2,8 @@
|
|||
|
||||
So far we’ve used some simple examples of [`create_signal`](https://docs.rs/leptos/latest/leptos/fn.create_signal.html), which returns a [`ReadSignal`](https://docs.rs/leptos/latest/leptos/struct.ReadSignal.html) getter and a [`WriteSignal`](https://docs.rs/leptos/latest/leptos/struct.WriteSignal.html) setter.
|
||||
|
||||
## Getting and Setting
|
||||
|
||||
There are four basic signal operations:
|
||||
|
||||
1. [`.get()`](https://docs.rs/leptos/latest/leptos/struct.ReadSignal.html#impl-SignalGet%3CT%3E-for-ReadSignal%3CT%3E) clones the current value of the signal and tracks any future changes to the value reactively.
|
||||
|
@ -62,3 +64,43 @@ if names.with(Vec::is_empty) {
|
|||
```
|
||||
|
||||
After all, `.with()` simply takes a function that takes the value by reference. Since `Vec::is_empty` takes `&self`, we can pass it in directly and avoid the unncessary closure.
|
||||
|
||||
## Making signals depend on each other
|
||||
|
||||
Often people ask about situations in which some signal needs to change based on some other signal’s value. There are three good ways to do this, and one that’s less than ideal but okay under controlled circumstances.
|
||||
|
||||
### Good Options
|
||||
**1) B is a function of A.** Create a signal for A and a derived signal or memo for B.
|
||||
|
||||
```rust
|
||||
let (count, set_count) = create_signal(cx, 1);
|
||||
let derived_signal_double_count = move || count() * 2;
|
||||
let memoized_double_count = create_memo(cx, move |_| count() * 2);
|
||||
```
|
||||
> For guidance on whether to use a derived signal or a memo, see the docs for [`create_memo`](https://docs.rs/leptos/latest/leptos/fn.create_memo.html)
|
||||
>
|
||||
**2) C is a function of A and some other thing B.** Create signals for A and B and a derived signal or memo for C.
|
||||
|
||||
```rust
|
||||
let (first_name, set_first_name) = create_signal(cx, "Bridget".to_string());
|
||||
let (last_name, set_last_name) = create_signal(cx, "Jones".to_string());
|
||||
let full_name = move || format!("{} {}", first_name(), last_name());
|
||||
```
|
||||
**3) A and B are independent signals, but sometimes updated at the same time.** When you make the call to update A, make a separate call to update B.
|
||||
```rust
|
||||
let (age, set_age) = create_signal(cx, 32);
|
||||
let (favorite_number, set_favorite_number) = create_signal(cx, 42);
|
||||
// use this to handle a click on a `Clear` button
|
||||
let clear_handler = move |_| {
|
||||
set_age(0);
|
||||
set_favorite_number(0);
|
||||
};
|
||||
```
|
||||
### If you really must...
|
||||
**4) Create an effect to write to B whenever A changes.** This is officially discouraged, for several reasons:
|
||||
a) It will always be less efficient, as it means every time A updates you do two full trips through the reactive process. (You set A, which causes the effect to run, as well as any other effects that depend on A. Then you set B, which causes any effects that depend on B to run.)
|
||||
b) It increases your chances of accidentally creating things like infinite loops or over-re-running effects. This is the kind of ping-ponging, reactive spaghetti code that was common in the early 2010s and that we try to avoid with things like read-write segregation and discouraging writing to signals frome effects.
|
||||
|
||||
In most situations, it’s best to rewrite things such that there’s a clear, top-down data flow based on derived signals or memos. But this isn’t the end of the world.
|
||||
|
||||
> I’m intentionally not providing an example here. Read the [`create_effect`](https://docs.rs/leptos/latest/leptos/fn.create_effect.html) docs to figure out how this would work.
|
||||
|
|
Loading…
Reference in a new issue