RFC: Intent to implement stable Svelte bindings

[kitten]

Summary

Currently I see our current @urql/svelte package and its past and current implementation as nice experiments which helped check the boundaries of Svelte and test APIs and the understanding of users.

The latest PR allowed all modes of Svelte's stateful stores to be used somehow, with similar semantics to the other bindings, See #862

It's becoming increasingly clear that this is confusing and doesn't feel idiomatic to Svelte.
The next implementation of @urql/svelte should start from a clean slate and be idiomatic to Svelte and intuitively avoid confusion. It is allowed to stray away from feeling like the urql and @urql/preact bindings, even forgoing permanent state memory if necessary.

Problems with the approach

The current approach attempts to allow three modes of usage:

• Store usage without memoised state
• Store usage with memoised state via an intermediate factory function
• Async-await/Promise usage

The last option of these feels idiomatic to Svelte but should be discouraged. We never aim to show results that can never reactively update. This is objectively bad.

The memoised usage is confusing and Svelte simply does not have a full reactivity model that allows us to observe changes. The user can do this manually and this may feel wrong to us, trying to implement complex hooks flows in Svelte, however this is not our problem to solve.

Bugs to avoid

• Unmounting issues, which may be inherent to our implementation: svelte: subscriptions can not be terminated #948, svelte: infinite polling even if the component self-destructs! #979
• Incorrect promise behaviour svelte: await query() should really await #932

[frederikhors]

❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️

[kitten]

An update has been published as @urql/[email protected]