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.
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.