|
|
|
|
|
|
by yellowsink
90 days ago
|
|
|
I don't really see that this actually implements it's proposal. The State class is still a custom thing and you could implement that however you want (Indeed a working signal implementation can be made in under a hundred lines) |
|
|
Sorry if I was unclear, the main point is not about the implementation detail nor size, although it's always a nice to have.
The State class is just one piece of it, you are free to not use it at all: for instance in the todo-fetcher, the State class does not even need to be used.
That's the point I tried to make: the rendering deals with a built-in API, not a special library's reactivity system.
Every time a new reactivity system appears, you need to learn how to compose states together.
Here since it's a built-in API, learning state composition is literally learning about async iterables, learnings which are also applicable in other fields than frontend reactivity.