With this fix, doing
```
const stores= [writable(0), writable(1)]
derived(stores, ([a,b,c]) => {});
```
works without type errors. The propblem with the previous type signature was that it's too strict for TypeScript's suboptimal inference of the value `stores` in that example, which is `Array<Readable<any>>`, which does not convey the info "at least one element", which the old Stores signature required.
Runtime-wise, it's no problem passing an empty array to derived.
The new signature is only appended to, not replaced, because the old signature is able to correctly infer the values of each array entry: For `derived([writable(0), writable('foo')], ([a, b]) => {});` the parameters `a` and `b` are correctly inferred as `number` and `string`. If the type would be changed to `type Stores = Readable<any> | Array<Readable<any>>` that would be no longer the case.
Fixes #6178
A recent refactoring commit where the constructor definition was moved to an interface disconnected the props relationship of the props that are passed in the constructor and the instance props
Fixes #6291
Fixes #6345
Both writable and readable initialized without any arguments are already valid, but TS complains about it. This makes both allowed to be emptily initialized. It's also possible to invoke readable with one argument only.
* Improve SSR hydration performance
- Fixes #4308 by avoiding de- and reattaching nodes during hydration
- Turns existing append, insert and detach methods into "upserts"
The new "hydration mode" was added in order to maintain the detach by
default behavior during hydration. By tracking which nodes are claimed
during hydration unclaimed nodes can then removed from the DOM at the
end of hydration without touching the remaining nodes.
Co-authored-by: Jonatan Svennberg <jonatan.svennberg@gmail.com>
