Should EffeKt have signals?

[bendgk]

The discussion at the table is whether I should introduce a new reactive primitive called a signal. A signal consists of a getter and a setter:

Heres an example of a signal that tracks an integer count

val (count, setCount) by signal(0)

you would then use count to get the current up to date value, or setCount(count + 1) to cause an update to this signal (increment).

Ideally signals are compatible to be used as a dependency for a computed primitive, or for watchEffect

[bendgk]

This twitter discussion about signals by Evan You may provide insight to the discussion, and I recommend anyone who wants to contribute to this discussion to give it a quick read.

[notKamui]

I saw this thread a few days ago.

Unfortunately this only works in JS, not in Kotlin ; because in JS you can add functions to the prototype of another function, but that's not the case in Kotlin (you can create extensions, but they affect the entire file when imported, and are not specific to a single instance, but to a type.

If one would want signals, you would need to create a new primitive with an inner type that would look like

interface Signal<T> {
    operator fun invoke(): T

    fun get(): T = invoke()

    fun set(value: T)

    fun update(updater: (T) -> T)

    fun mutate(mutator: (T) -> Unit)
}

[notKamui]

Heres an example of a signal that tracks an integer count

val (count, setCount) by signal(0)

The discussion was about Angular signals, this is a Solid signal

[bendgk]

Yeah I know, but they're quite similar. Regardless I will most likely not be considering adding signals to EffeKt

[notKamui]

Following the thread that Evan You participated in, I think either Angular nor Solid signals are necessary for the API. The semantic is the same, and it would just add different ways to accomplish the same thing. This would create a chasm in how people will use the library, and will force you to work a lot to maintain compatibility for something that is very superficial in the end.

[bendgk]

I completely agree. This was actually kinda the point I was trying to make, is that the proposed signal api is pretty much just that of ref Lots of people on twitter feel similarly about that too.

edit: oh looks like I accidentally forgot to post one of my replies, but the gist as as above.