Signal passed as component prop gives error 'Type 'ReadonlySignal<number>' is not assignable to type 'number'.ts(2322)'

[darioRandazzoAccedo]

Hello everyone,
I am ramping up with preact and signals and after using them for same days I encountered this TS error:

Type 'ReadonlySignal<number>' is not assignable to type 'number'.ts(2322)

This is happening because I am now passing a signal as a prop to something that used to be a simple number.
I am passing directly the signal since the optimization section says to not pass the .value, but the signal itself.
I suppose this can be easily solved for my own components (by changing their prop type from a simple <T> to be something like <T | Signal<T> | ReadOnlySignal<T>), but what for external components that I cannot edit?
At the moment I am using a dirty workaround by casting to unknown and then to T , but I assume this is not as it was designed to be used.

Example:

import { computed } from '@preact/signals';
...
const progressValue = computed(() =>  getProgressTimeInteger(playbackTimeline.value, playerData.value) )
...
<ProgressBar progress={progressValue as unknown as number} />

How should I properly handle this kind of scenario?
Thanks

ps: I found this other discussion, but I am not sure that helps me because I am NOT using React, but just Preact, so I don't think I need the mentioned babel plugin.

[rschristian]

but what for external components that I cannot edit?

You must unwrap the signal then. The optimization can only work if the consuming component uses signals, if it doesn't, there's no way around unwrapping.

At the moment I am using a dirty workaround by casting to unknown and then to T , but I assume this is not as it was designed to be used.

This will break the second the component tries to use that prop in an expression, definitely don't do that. Silly example:

function MyComponent({ foo }: { foo: number }) {
    if (foo == 3) return <p>Is 3</p>;
    return <p>{foo}</p>;
}

[darioRandazzoAccedo]

Thanks for the warning! I suppose you meant unwrapping functions like the ones suggested by @predaytor , right?
Using this kind of function will mantain the optimization suggested here?

[predaytor]

I think for rendering signals in JSX, an additional optimization involves not accessing .value, but rather reading the signal as-is.

[rschristian]

No, the optimization will be dead. Unwrapping the signal kills it.

Without knowing the internals of the component (how it uses the prop), you cannot get the optimized rendering behavior from a component that does not take a signal.

[predaytor]

you can use this functions to unwrap the signals for consumption?

import { Signal } from '@preact/signals';
import type { JSX } from 'preact';

export function access<T extends unknown>(value: JSX.Signalish<T>): T {
	return value instanceof Signal ? value.value : value;
}

export function accessArray<T extends unknown>(list: ReadonlyArray<JSX.Signalish<T>>): Array<T> {
	return list.map((value) => access(value));
}

[darioRandazzoAccedo]

So, the unwrap functions are a standardized way to access things that "may" be signals or not.
Isn't this something that will add a lot of overhead to the codebase?
Why not coding in a explicit way signal.value or signal.peek() or just the signal at that point?

[rschristian]

Isn't this something that will add a lot of overhead to the codebase?

No

[darioRandazzoAccedo]

I consider this:
const classVal = signalMaybeUnwrapper(props.class);

or something like this
return <MyOtherComponent myProps={access(mySignal)} />

as overhead. Don't you?

[rschristian]

A function call containing only a ternary w/ an instanceof check is not overhead, no.

But if it's unacceptable to you, feel free to restrict your company types to only accept primitive values and no signals. You wouldn't get any rendering optimizations but I guess you'll get to skip a function call?

[darioRandazzoAccedo]

our main focus is rendering optimizations, of course. I was just trying to find out what is actually needed and use the most elegant solution that the state of art offers.

thanks a lot for answers!