signals icon indicating copy to clipboard operation
signals copied to clipboard

The parameter of `singal()` can be omitted, just like `useState()`.

Open cnbebop opened this issue 1 year ago • 11 comments

Think about this, create a issue signal, and it's initial is undefined, then you should pass undefined to both generic parameter and function parameter.

const issue = signal<Issue | undefined>(undefined);

We can see that it leads to boilerplate code and the development experience is reduced.

The signal() can be defiened like this:

function signal<T>(value: T): Signal<T>;
function signal<T = undefined>(): Signal<T | undefined>;

cnbebop avatar Mar 18 '24 10:03 cnbebop

I don't think it's a problem. Better to keep function with the same amount of arguments (it's better for performance)

XantreDev avatar Mar 18 '24 12:03 XantreDev

I don't think it's a problem. Better to keep function with the same amount of arguments (it's better for performance)

Even if you're right, but the class Signal has an optional parameter constructor, how to explain it?

cnbebop avatar Mar 19 '24 00:03 cnbebop

Looks reasonable to me, if you want to PR it.

rschristian avatar Mar 19 '24 06:03 rschristian

I don't think it's a problem. Better to keep function with the same amount of arguments (it's better for performance)

Even if you're right, but the class Signal has an optional parameter constructor, how to explain it? It's not for public usage. But I see, probably it will think that it can have 0 params https://github.com/preactjs/signals/blob/58befba577d02c5cac5292fda0a599f9708e908b/packages/core/src/index.ts#L531

Anyway I think it should be benchmarked. Check for deoptimizations and how much it slows other benchmarks

XantreDev avatar Mar 19 '24 07:03 XantreDev

Anyway I think it should be benchmarked. Check for deoptimizations and how much it slows other benchmarks

This should be a type signature-only change. There will be no effect on the benchmarks

rschristian avatar Mar 19 '24 07:03 rschristian

@XantreGodlike This is in relation to an already allowed paradigm, signals can be initiated with undefined or a missing initializer as you yourself link to for the Computed.prototype. This can't possibly affect benchmarks as it's merely a change in how the generic infers the starting value.

JoviDeCroock avatar Mar 19 '24 07:03 JoviDeCroock

It's not we are starting to provide interface that allows different amount of args. It can cause performance slow down, depending on usage https://jsbench.me/7slty3mtij/1 image

XantreDev avatar Mar 19 '24 08:03 XantreDev

But probably impact will be insignificant

XantreDev avatar Mar 19 '24 08:03 XantreDev

Did you read my comment? It's already ? allowed to be not there https://github.com/preactjs/signals/blob/main/packages/core/src/index.ts#L277

JoviDeCroock avatar Mar 19 '24 08:03 JoviDeCroock

It's not we are starting to provide interface that allows different amount of args

We are not. This usage has always been valid.

I don't think that benchmark is displaying what you think it is. Trying to do math with undefined is indeed going to be slower than adding two numbers together. This isn't going to be an issue here.

rschristian avatar Mar 19 '24 08:03 rschristian

Did you read my comment? It's already ? allowed to be not there https://github.com/preactjs/signals/blob/main/packages/core/src/index.ts#L277

Got it. Sorry

XantreDev avatar Mar 19 '24 09:03 XantreDev

Woo-hoo, thanks for resolving this 🎉 Glad to see my PR #116 doesn't need to celebrate its 2nd birthday.

kidonng avatar Jul 08 '24 14:07 kidonng