You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The one and only export of Core Flux. Use it to create a store instance. You can create as few or as many stores as your heart desires! They will all be independent from one another.
Once a store is created, you'll be able to add subscriptions with `subscribe` and request state updates with `dispatch`.
86
87
88
+
#### Bindings
89
+
87
90
Here's a breakdown of each binding needed when initializing a new store:
88
91
89
-
#### `reducer(state, { type, payload } = action)`
92
+
**`reducer(state, action)`**
90
93
91
-
> `state (object)`: A copy of the current state object.<br/>`action ({ type, payload })`: The dispatched action type and its payload.
94
+
> `state (object)`: A _copy_ of the current state object.<br/>`action ({ type: string, payload: object })`: The dispatched action type and its payload.
92
95
93
-
Creates a new version of state and returns it, based on the `type` and `payload`. If the return value is falsy, nothing happens.
96
+
Creates a new version of state and returns it, based on the `type` and `payload`. If the return value is falsy, the update process ends.
94
97
95
-
#### `bindSubscriber(subscription, state)`
98
+
**`bindSubscriber(newSubscription, state)`**
96
99
97
-
> `subscription (array)`: A tuple containing the subscribed object and its relational data.<br/>`state (object)`: A copy of the current state object.
100
+
> `newSubscription ([subscriber, data])`: A tuple containing the subscribed object and its state-relational data.<br/>`state (object)`: A _copy_ of the current state object.
98
101
99
-
Called after a new `subscribe` call is made and a subscription has been added to the store. Use it to set initial state on the new subscriber.
102
+
Called after a new `subscribe` call is made and a subscription has been added to the store. Use it to set initial state on the new subscriber based on the `data` defined by your subscriber.
> `subscriptions (subscription[])`: An array containing all subscriptions.<br/>`nextState (object)`: The state object as returned by the reducer.<br/>`setState (function)`:
106
+
> `subscriptions (subscription[])`: An array containing all subscriptions.<br/>`reducedState (object)`: The state object as returned by the reducer.<br/>`setState (function)`:
104
107
105
-
Called after the reducer has processed the next state value. Use it to set the new state back to subscribers **and** back to the store.
108
+
Called after the reducer has processed the next state value. Use it to set the reduced state back to subscribers **and** back to the store.
Adds a subscription to your store. It will always be tied to a single store, and subsequently state object.
110
113
@@ -122,20 +125,20 @@ class FooItems {
122
125
}
123
126
```
124
127
125
-
In the above example, we've designed our subscriber, the `FooItems` class, to declare an array of strings correlating to properties in the store's state. If you're from the Redux world, this is akin to "connecting" a consumer to a provider.
128
+
In the above example, we've designed the subscriber, the `FooItems` class, to declare an array of strings correlating to properties in the store's state. If you're from the Redux world, this is akin to "connecting" a consumer to a provider via higher-order function/component.
126
129
127
-
Additionally, when this `subscribe` call is made, the`bindSubscriber` function will be called where the result of a subscription can be defined. E.g., assigning a default value from state into the subscriber.
130
+
After the subscribe call is made, your`bindSubscriber` function will be called where you can pass along the default values as you see fit.
128
131
129
132
> In general, you should try to use a simple data structure as the second argument to `subscribe`; this ensures your bindings have generic and consistent expectations.
Let's say you have some subscriptions in your store. How do you kick off a state update for subscribers? That's where `dispatch` comes into play.
136
+
Requests a state change in your store.
134
137
135
-
Let's extend the previous example:
138
+
We can extend the previous example with a setter to call `dispatch`:
136
139
137
140
```js
138
-
import { subscribe } from"./foo-store"
141
+
import { subscribe, dispatch } from"./foo-store"
139
142
140
143
classFooItems {
141
144
constructor() {
@@ -155,13 +158,25 @@ const fooBar = new FooItems()
155
158
fooBar.addItem("bop")
156
159
```
157
160
158
-
Now when the `addItem` method is called, `dispatch` will tell your store to begin the state update process. Your reducer receives the action type and payload.
161
+
Now when the `addItem` method is called, Core Flux will pass along the action type and payload to your reducer.
162
+
163
+
The reducer could have a logic branch on the action type called `ADD_ITEM` which adds the given item to state, then returns the resulting new state (containing the full items list).
164
+
165
+
Finally, the result would then be handed over to your `bindState` binding.
166
+
167
+
> Much like in `subscribe`, it's best to maintain data types in the payload so your reducer can have consistent expectations.
159
168
160
-
The next step being that your reducer could have a logic branch on the action type called `ADD_ITEM` which adds the given item to state, then returns the resulting new state (containing the full items list).
169
+
## Exposing the store
161
170
162
-
Finally, the result would then be handed over to `bindState`.
171
+
For utility or debugging reasons, you may want to look at the store you're working with. To do so, you can use the `__data` property when creating a store.
163
172
164
-
> Any data type can be used as the payload, however, much like in `subscribe`, it's best to keep your data consistent so your reducer can have reliable expectations.
0 commit comments