Why not use RwSignal everywhere?

[RandomInsano]

Hey there! I'm new to Leptos and enjoying the documentation so far. Though, I had a big question hit me when iterators came up:

Note here that instead of calling signal() to get a tuple with a reader and a writer, here we use RwSignal::new() to get a single, read-write signal. This is just more convenient for a situation where we’d otherwise be passing the tuples around
(from https://book.leptos.dev/view/04_iteration.html)

The big thing that hit me is that it looks a lot nicer to use the RwSignal in say, this example:

#[component]
pub fn Button(increment: i32) -> impl IntoView {
    // was the following:
    // let (count, set_count) = signal(0);
    // let click = move |_| set_count(count() + increment);

    // Now I've gone and mooshed it into this:
    let count = RwSignal::new(0);
    let click = move |_| count.set(count.get() + increment);

    view! {
        <div>
            <button on:click=click>"Click me: " {count} " times"</button>
            <p>"Increment: " {increment}</p>
        </div>
    }
}

Now, my big guess here is that if you're only sending a read signal it's more explicit that the component can't update that value. It may be worth covering that in that paragraph because at first glance I thought "Why, that's a really easy way to have ergonomics and not use +nightly.

Am I wrong here? Maybe the paragraph could read:

Note here that instead of calling signal() to get a tuple with a reader and a writer, here we use RwSignal::new() to get a single, read-write signal. This is just more convenient for a situation where we’d otherwise be passing the tuples around. Passing a RwSignal to a component would also allow that component to update the value held by the signal.

Thanks!

[gbj]

Pretty straightforward: the read-write separation is useful as the default because it encourages the pattern of only passing a ReadSignal to components or functions that only need read access, and specifically needing to pass a WriteSignal if a component is able to update something. Because UI doesn't have the benefit of the borrow checker, this can be helpful for debugging as applications scale up: if something appears to be updating a signal you're not expecting to be updated, it is useful to know that (for example) of the 10 components that have access to this signal, 9 only have a ReadSignal and so can't be the source of the update, which must be coming from the other component. On this theory, the trade-off is between "feels nice for small examples" (RwSignal) vs. "helps enforce better patterns for normal-sized applications."

[RandomInsano]

Thanks! That confirms my guess. Should I open a PR that reads like so?

Note here that instead of calling signal() to get a tuple with a reader and a writer, here we use RwSignal::new() to get a single, read-write signal. This is just more convenient for a situation where we’d otherwise be passing the tuples around. The read-write separation we have been using so far is useful as the default because it encourages only passing a ReadSignal to components or functions that only need read access, and specifically needing to pass a WriteSignal if a component is able to update something. Because UI doesn't have the benefit of the borrow checker, this can be helpful for debugging as applications scale up: if something appears to be updating a signal you're not expecting to be updated

[gbj]

Sounds good to me! Thanks for offering.