Is there a way to create an RwSignal from a get signal and a set signal, like the opposite of RwSignal::split?

[ChocolateLoverRaj]

I want to "derive" a RwSignal by combining the outputs of Signal::derive and SignalSetter::map

[gbj]

No. In theory you could recombine a ReadSignal<T> and WriteSignal<T> (but only those) into an RwSignal<T>, but it might fail at runtime.

[ChocolateLoverRaj]

Is it possible / does it make sense to add a feature to Leptos to be able to join a signal and signal setter into a single variable that implements SignalGet and SignalSet?

[gbj]

It seems like a feature that would be very easy to use incorrectly...

// 1. incorrectly merging two unrelated signals
 
// create two signals
let a = RwSignal::new(1);
let b = RwSignal::new(2);

// make a Signal from one, and (by a typo) a SignalSetter from the other
let getter = Signal::from(a);
let setter = SignalSetter::from(b);

// re-merge the signals
// this is one way of using it incorrectly -- the two halves are totally unrelated
let merged = MergedRwSignal::from((a, b));

// 2. confusing semantics around get/set
 
let a = RwSignal::new(1);

// the setter is a plain setter 
let setter = SignalSetter::from(b);
// the getter is a Signal, which can be made from any readable signal type
let getter = Signal::from(Memo::new(move |_| {
  a.get() * 5
});

// merge the signals
let merged = MergedRwSignal::from((a, b));
merged.set(5);
merged.get(); // returns... 25?

[ChocolateLoverRaj]

What about the ability to create a derived RwSignal in one function by providing a get function and a set function? Would that be less likely to be used incorrectly?

[qidian99]

@gbj The MergedRwSignal::from is exactly what I need as described in #2358. Could you provide some naive implementaion of MergedRwSignal?

[qidian99]

Some naive impl is like below:

use leptos::{create_effect, prelude::*};

// Here's a hypothetical definition of the `MergedRwSignal` struct.
// You would need to define this struct based on your specific needs and the context you're working with.
pub struct MergedRwSignal<T: 'static> {
    getter: Signal<T>,
    setter: SignalSetter<T>,
}

impl<T> MergedRwSignal<T> where T: 'static + Clone {
    pub fn from(getter: Signal<T>, setter: SignalSetter<T>) -> RwSignal<T> {
        let signal = create_rw_signal(getter.get_untracked());
        
        create_effect(move |_| {
            let new_value = getter.get();
            signal.set(new_value);
        });

        signal
    }
}


#[cfg(test)]
mod tests {
    use super::*;
    use leptos::*;

    #[derive(Clone, Debug, PartialEq)]
    struct StructA {
        b: StructB,
    }
    
    #[derive(Clone, Debug, PartialEq)]
    struct StructB {
        value: i32,
    }

    #[test]
    fn test_merged_into_rw_signal() {
        let runtime = create_runtime();

        let signal_a = create_rw_signal(StructA { b: StructB { value: 10 } });
        let (read_a, write_a) = slice!(signal_a.b);

        let signal_b = MergedRwSignal::from(read_a, write_a);

        signal_b.update(|b| { b.value = 11 });

        assert_eq!(signal_a.get_untracked().b.value, 11);

        runtime.dispose();
    }
}

RN the two way binding between the parent signal and derived signal is still missing. Will figure it out later..

[ChocolateLoverRaj]

I don't think it's a good idea to create an effect. Directly getting and setting the underlying signals through traits would make more sense.

[gbj]

There are three senses in which you might re-merge two halves of something into an RwSignal

1. merge a ReadSignal and WriteSignal that come from a single create_signal call or from a single RwSignal back into a single RwSignal? or
2. merge an arbitrary Signal and SignalSetter so they are synchronized
3. access nested fields of a struct (as seen in the example given by @qidian99 above)

Option 1 is possible to add and I'd be open to a PR adding something like impl<T> TryFrom<(ReadSignal<T>, WriteSignal<T>)> for RwSignal<T>. If the two halves have the same ID they are trivial to merge, but this needs to be checked at runtime.

Option 2 is fundamentally broken, in the ways I described above, and is not a good idea.

Option 3 is similar to the concept of a reactive "store," i.e., a struct with deeply nested reactivity without needing to wrap each field in a signal separately. See additional discussion in #2042 and #2046. I do have something similar planned for the next release. At present I don't intend to add something like the re-merged signals described above to the library, but they can be implemented in userland as you've seen.