Working with Signalish props

[rawrmonstar]

Basically all the html attributes are typed as Signalish<T>, for example aria-disabled is Signalish<Booleanish | undefined>. Do you need to check if a prop is a signal every time you do something with it in a component? It seems kinda cumbersome and I feel like I'm missing something.

Below is an example

export type ButtonVariant = "solid" | "outline" | "outline-subtle" | "ghost";
export type ButtonSize = TextHeadingSize;

export interface ButtonProps extends ComponentProps<"button"> {
	onSoftDisabledClick?: ComponentProps<"button">['onClick'],
	variant?: ButtonVariant;
	size?: ButtonSize;
}


export function Button({
	variant = "solid",
	size = "md",
	type = "button",
	onClick,
	onSoftDisabledClick,
	...props
}: ButtonProps): JSX.Element {
	// props["aria-disabled"] can be a signal or a plain value
    // is there a convenient way to work with these values or
    // do you need to check if something is a signal every time
    // you want to do something with the value. 
	const isSoftDisabled = fromBooleanish(props["aria-disabled"])

	return (
		<button
			{...props}
			type={type}
			class={buttonRecipe({ variant, size }, props.class)}
			disabled={props.disabled}
			aria-disabled={props["aria-disabled"]}
			data-disabled={props.disabled || isSoftDisabled}
			onClick={isSoftDisabled ? onSoftDisabledClick : onClick}
		/>
	);
}

[rschristian]

Do you need to check if a prop is a signal every time you do something with it in a component?

Only if you want to accept signals & unwrapped values both, and need to consume the raw value in some way (i.e., not passing it straight on into a JSX attribute or as a JSX child).

If it's too much of a hassle for you then you don't need to accept signals of course, though you won't be able to piggyback our types as much. I realize that's probably not the answer you're hoping for but there's not much in the way around it if you want to accept both & have to read the value; gotta check & unwrap.

[rawrmonstar]

OK Thanks.

Is there a recommended way to determine if a prop is a signal or a plain value?

[rschristian]

There are two options, using instanceof Signal or using duck typing:

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

function isSignal(x) {
    return x instanceof Signal;
}

If this is for a library, and you don't want to depend on @preact/signals, duck typing might be a better option:

function isSignal(x) {
    return (
        x !== null &&
        typeof x === 'object' &&
        typeof x.peek === 'function' &&
        'value' in x
    );
}

[tegan-rbi]

@rschristian do you know, is it normal to have components using signals to only accept a signal props? TBH dealing with both wrapped and unwrapped props is pretty painful...

I wonder if it would be possible to hook into preact internals and make all props signals (if they aren't passed in as signals)...

[rschristian]

I'm not sure I'd say it's "normal" but it certainly wouldn't be "abnormal"; it really comes down to who you want to use these components and what kind of experience you want to offer. Having users pass in signals will almost certainly let you, the component author, provide components that perform better & ship less code and so "forcing" them to give data in the form of a signal might be a very reasonable & fair trade off. On the other hand, you may have some folks adamantly against signals (for whatever reason, we see a few folks that are very much against any other state primitive) and so you might turn them away. I'm usually team "go for it!" but that's just me/my requirements.

I don't think hooking into internals would offer any better solutions than just creating a wrapper component to massage everything into signals, either by creating new signals from non-signal data or unwrapping & rewrapping existing signals. Ergonomics aren't great here, I completely agree.

Our slack has a #signals channel (looks like you joined recently?) which might have some folks w/ better ideas/patterns for you, though admittedly it's not the most active.