Side APis to adapt

[y-nk]

I'm thinking that, this would be great if only it was used in existing primitives such as fetch. i can see easily a scenario where the loading of the request is a computed which drives ui change.

This may lead to a lot of changes in the way current stateful objects are used, and i do wonder why these core objects would not deserve a native implementation too: is it true that you can "wrap" fetch with a library-made "fetch-signals" but why should you need a 3rd party package if both the things are native to the language? (this could extend to everything stateful and native, which would somehow involve Promise at some point since the settlement of a promise is a stateful property which could be reacted to)

[littledan]

I think this would be good to develop in another package which uses Signals. @NullVoxPopuli has started developing this kind of thing at https://github.com/NullVoxPopuli/signal-utils . This proposal is trying to start with something minimal which is purely representing the dependency graph and not any particular I/O (or even data structures).

[y-nk]

but why should you need a 3rd party package if both the things are native to the language?

if the package is built in npm, why then add this whole thing to the language? signals could also be a package then? where do we draw the line? and what argument aside from "i think this would be good"? dependency graph does necessarily need to be native, does it?

EDIT: not being hostile, but rather challenging the whole thing. i'm huge fan of reactivity but i'm worried of the ramification this will create, and the light mindset around them.

[NullVoxPopuli]

. i'm huge fan of reactivity but i'm worried of the ramification this will create, and the light mindset around them.

All the more reason to have a solid, pay-as-you-go-works-with-everything utils library.

ignals could also be a package then? where do we draw the line? and what argument aside from "i think this would be good"? dependency graph does necessarily need to be native, does it?

it's more a forcing function for enhancing interop across the ecosystems -- folks are hesitant to adopt libraries because "what if ecosystem X doesn't use it?" and then one thing leads to another, and we have 15 competing standards -- through platform standardization (rather than library standardization), my personal motivation and hope is that we start eliminating these competing standards (or at least making them compatible with one another, rather than competing -- yay collaboration!)

I don't know how many signals implementations we have today, but there are many -- Idk if anyone has put together a list yet, but I think it'd be good to have as a reference/appendix entry somewhere or something.

[y-nk]

@NullVoxPopuli i doubt it.

i mean, i understand what you're saying but at the same time, the proposal aims to be the most convenient for frameworks. there's the subtle namespace, and features aren't really usable "as a noob". one should either use a framework which simplified it, or else know the internals and be advanced for a vanilla usage. there's no "w3schools copypasta implementation" which can be done, and it kills a bit the mindset around javascript being something to tinker with.

i dont know for sure, but it's unlikely you'll see Vue or Solid change their upper level API to this as well. They'll more likely wrap it which may introduce some level of collaboration but in the end will remain different in the implementation for the end user. The concept are known to be the same, and it helps engineers transfer from one framework to another, but they will continue to have to learn the different vocabulary and implementation.

The only thing that may end up is, next time framework X wants to fork it out because they have a need, they'll create yet another "15th competing standard", which this time will raise again concerns because "it derivates away from the standard" (i'm looking at you, React).

it's an endless loop, hence i think trying to make a dent on it is pretty pointless.

this just looks like trying to softly bruteforce "an 15th competing standard" as the standard even if, from recollection of discussion on X and here, it looks like it's been done gently and from good intentions (with the consultation of framework core engineers).

Note that my primary thought on the thread was rather that such a convenient api would soon find itself everywhere in every layer of the stateful objects of the api. competing with promises, mainly ; and that, having this as a signal-utils implies a missing layer in the initial implementation, and also introduce yet another library trying to be standard, and which may most likely find competition.