Seems like it would not be hard to extend the props macro to recognize Signal/ReadOnlySignal and adjust the default accordingly. Something sort of similar is done for optionals.

If this is a something the team wants handled in the macro I can send a PR for it.

Seems like it would not be hard to extend the props macro to recognize Signal/ReadOnlySignal and adjust the default accordingly. Something sort of similar is done for optionals.

If this is a something the team wants handled in the macro I can send a PR for it.

That sounds like a good extension. If you want to work on a PR, keep in mind the signal we create in the props macro needs to be owned by the child component which means we need to call new inside of an owner in the builder. We have some logic for this already for converting T to ReadOnlySignal<T> here

Interesting. I think there may be a bug related to defaults for ReadOnlySignal and Callback types then. When using the builder functions the value is owned but the child props, but there is not such logic for defaults.

Here is an example of how the default needs to be written currently and the build() method it expands to.

#[derive(Props)]
pub struct FormProps {
    #[props(default = ReadOnlySignal::new(Signal::new(false)))]
    pub read_only_signal: ReadOnlySignal<bool>,
}

#[allow(dead_code, non_camel_case_types, missing_docs)]
impl<
    __read_only_signal: FormPropsBuilder_Optional<ReadOnlySignal<bool>>,
> FormPropsBuilder<(__read_only_signal,)> {
    pub fn build(self) -> FormPropsWithOwner {
        let (read_only_signal,) = self.fields;
        let read_only_signal = FormPropsBuilder_Optional::into_value(
            read_only_signal,
            || ReadOnlySignal::new(Signal::new(false)),
        );
        FormPropsWithOwner {
            inner: FormProps { read_only_signal },
            owner: self.owner,
        }
    }
}

If I understand this right, the default value will be owned by the component where this is expanded. I think I actually encountered this bug last week using default Callbacks but didn't realize the cause and assumed I was misusing something. The callback would log a warning because it used a Signal owned by the child scope, but the callback itself was owned by the parent scope.

I opened a PR for this. Because it's only building off the existing behavior of when a prop's builder method is called, it only applies to ReadOnlySignal and Callback types. I did not want to mess around with things too much for my first change.

If I understand this right, the default value will be owned by the component where this is expanded. I think I actually encountered this bug last week using default Callbacks but didn't realize the cause and assumed I was misusing something. The callback would log a warning because it used a Signal owned by the child scope, but the callback itself was owned by the parent scope.

I realized I was conflating Owner and Scope. The issue I was encountering is that when a Callback is executed it uses the scope it was created in, regardless of which owner it gets assigned. This is a separate issue (if it's an issue at all) and I've worked around it for now by creating by own callback type that always executes in the current scope, rather than its origin scope.