Conversation
|
Thanks. I think it makes sense to split the connect into components / svelte as discussed in slack and a peer dependency feels right for people who aren't using svelte. I'd still like to work with svelte more before adding this to rdx though - the connect layer is pretty small but I want to validate the patterns a bit more first. For instance, instead of doing the connect in each component, it seems to work well to just create and import a connected 'state' and also use that to access the dispatch methods as well (which is why I originally added it instead of it just returning the subscribe method). |
|
🤔 // src/state/state-store.ts
import { connect } from '@captaincodeman/rdx/svelte'
import { store } from './store'
export const stateStore = connect(store)And then use it like this: <!-- src/ui/Foo.svelte -->
<script lang="ts">
import { stateStore } from '../state/state-store'
import { fooSelectors } from '../state/models/foo'
$: numberOfFoos = fooSelectors.fooCount($stateStore)
</script>
<h1>There {numberOfFoos === 1 ? 'is' : 'are'} {numberOfFoos} {numberOfFoos === 1 ? 'foo' : 'foosens'}</h1>
<button on:click={stateStore.dispatch.foo.addFoo()}>Add a foo</button>The one thing I really dislike about the snippets I just wrote is, that both Rdx and Svelte use the term "store" and it means something different. That does feel like an invitation for misunderstandings (and difficult to write or very wordy docs). Then, again, if it was So, to sum it up: Maybe best just to provide read access to the Rdx store's state through a custom Svelte store, and have |
A first shot at implementing the changes required for addressing issue #26
I am not sure, if making Svelte a peerDependency is the right move. There are pros and cons to it, as per this article on peerDependencies
This ☝️ is not the case here, as Rdx will work just fine without svelte. But then in that same article it is written:
If merged:
closes #26