2 ms·
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
by yellowsink 7mo 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)
- sacdenoeuds-dev 7mo agoThanks for your feedback! 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.