Passing signal as prop

[yonathan06]

Assuming I have a signal in a parent comp, and I want to pass the signal value to a child comp, what is the difference, in term of performance/behavior, between passing the signal value as props vs passing the signal getter function as props

for example:

passing signal getter as props

function DisplayCount(props) {
  return <div>Count: {props.count()} </div>
}

function Counter() {
  const [count, setCount] = createSignal(0);
  setInterval(() => setCount(count() + 1), 1000);
  return <DisplayCount count={count} />;
}

passing signal value

function DisplayCount(props) {
  return <div>Count: {props.count} </div>
}

function Counter() {
  const [count, setCount] = createSignal(0);
  setInterval(() => setCount(count() + 1), 1000);
  return <DisplayCount count={count()} />;
}

[lxsmnsyc]

There's some difference but this might not be intuitive to some users:

• With count={count}, the expression is treated as "static" therefore isn't wrapped into a getter and is never considered as reactive. With this in mind, props.count can be safely destructured without losing reactivity (since it wasn't there, in the first place).
• With count={count()}, the expression is treated as "reactive" and is therefore wrapped into a getter. This, however, cannot be destructured outside of reactive scopes (e.g. createEffect) without losing reactivity.

Accessing their values (calling the signal prop vs accessing the reactive prop) should be the same however a "reactive prop" isn't always about signals.

[yonathan06]

From what I understand from you the following effect in the child comp should be triggered only once, because it doesn't have reactivity:

function DisplayCount(props) {
  createEffect(() => { console.log(props.count) });
  return <div>Count: {props.count} </div>
}

function Counter() {
  const [count, setCount] = createSignal(0);
  setInterval(() => setCount(count() + 1), 1000);
  return <DisplayCount count={count()} />;
}

but it is called every time count updates. What am I missing?

[lxsmnsyc]

it must be destructured first to lose it

const { count } = props;
createEffect(() => {
  console.log(count);
});

[yonathan06]

got it, thanks

[atk]

If you want to make it obvious, you could also use untrack(props.count).

[ryansolid]

Yeah the reason I designed it was to be uniform when people passed literal values. Generally passing the signal value is what we recommend because it mirrors passing any value. You consume it the same way inside your component. No checking for isFunction etc.. However, there is a tiny bit of overhead in that adds an additional function wrapper(object getter) added for dynamic expressions. This is pretty cheap compared to the convenience this adds.

[yonathan06]

So if passing prop as static value <DisplayCounter count={count()} /> it will be wrapped by a Proxy object inside DisplayCounter for reactivity?

[ryansolid]

Yeah a getter. You will see this in the compiled output it will look like:

DisplayCounter({
  get count() { return count(); }
})

Generally speaking, on access a getter is about 3x slower than a function and a proxy is about 10x slower. However, as I've shown in the JS Framework benchmark a full proxy solution is still only maybe 5-7% slower in a fairly intensive benchmark and still in a range of performance that is really nice and getters would be less. Proxy version even is indistinguishable in animation demos I do, so I imagine most of the cost is in the overhead of creating proxies (extra memory allocations). So honestly I don't think I'd be super worried about performance here. If I'm doing a benchmark I might pass a signal to eek out the absolute but truth be told it's unlikely it even makes a measurable difference.

[EnkeyMC]

Why not go the other way around where every prop would be treated as if it's reactive and would be a function, even when you pass a constant (compiler would wrap the constant into function). This way we could still destruct the props object like people are used to, without loosing reactivity. I can imagine that it may be slower, but is it slower than getters? Or is there other reason?

[ryansolid]

Yeah thought about this a bit. You'd need to wrap every value with a function pretty much which in some ways consistent. It does opt people out of optimization though. Like consider passing a signal intentionally.

<MyComp someProp={someSignal} />

Currently we know that isn't a reactive expression so we pass it through. This would have to be function wrapped since we don't know if it is a function. So you'd access it like props.someProp()() which is probably fine if this is what you intended anyway. It promotes the same pass as value mentality we currently have.

But then I start think about all the places you intend to pass functions. Things like event handlers and it's like that too. So you'd have to write your eventHandlers like:

<div onClick={props.onClick()} />

I mean maybe that is fine but I'm not sure it's better. When you are passing by value it feels like you should be getting that value on the other side. I understand there is a getter involved sometimes but seems more natural to access it as such.

Other reasons come around the dynamic nature of props. Things like spreads or like checking if a prop exists. In cases where proxies can be involved it is a bit my bulky still since any potential prop would need to be a function that can be called to know if it is present or not. Basically the moment dynamic spreads are involved on the component a proxy much return a function for any potential property of props. And can you spread that again? Like any processor would have to be aware of function properties of objects. I actually think that is ambiguous. Right now with Solid you don't worry about that because it's assumed that when you spread you are passing in a value. I suppose you could force all spreads to have a helper and tell it which keys because without telling it you'd need to call any function on the object and it could be mixed.

<MyComp {...{...props, onClick() { console.log("hello") } } } />

Are supposed to call onClick as part of the spread? Props has functions on it do we know what to call and what to leave?

Maybe a helper:

<MyComp {...{...resolve(props), onClick() { console.log("hello") } } } />

Anyway it there are a number of edge cases like this.