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
Core Flux has a relatively simple data model that you should understand when writing state bindings.
60
-
61
-
Here is how state looks in all cases:
62
-
63
-
```js
64
-
Store {
65
-
state: { ... },
66
-
67
-
subscriptions: [
68
-
[subscriber, data],
69
-
[subscriber, data],
70
-
[subscriber, data],
71
-
// ...
72
-
]
73
-
}
74
-
```
75
-
76
-
Each item in `subscriptions` contains a `subscriber` and some form of `data` that informs a relationship between `state` and `subscriber`. See [`createStore`](#createstore) on how to add subscriptions.
77
-
78
-
`state` is the object you define as your store's initial state value.
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.
83
61
@@ -108,50 +86,23 @@ Once a store is created, you'll be able to add subscriptions with `subscribe` an
108
86
109
87
Here's a breakdown of each binding needed when initializing a new store:
110
88
111
-
```js
112
-
/**
113
-
* Receives a `payload` and returns a new version
114
-
* of `state` based on the given `type`. Similar to
115
-
* the likes of redux and other tools.
116
-
*
117
-
* @param{string}type
118
-
* @param{object}state
119
-
* @param{object={}}payload
120
-
* @returns{object} state
121
-
*/
122
-
functionreducer(type, state, payload) {
123
-
// ...
124
-
}
89
+
#### `reducer(type, state, payload = {})`
125
90
126
-
/**
127
-
* Receives a new subscription as provided by the `subscribe`
128
-
* function, along with the current state. The subscription
129
-
* will have been automatically added to the store when this
130
-
* function is called.
131
-
*
132
-
* @param{[object, *]}subscription
133
-
* @param{object}state - immutable copy of state
134
-
*/
135
-
functionbindSubscriber(subscription, state) {
136
-
// ...
137
-
}
91
+
> `type (string)`: The action dispatched.<br/>`state (object)`: A copy of the current state object.<br/>`payload (object={})`: The payload given during dispatch.
138
92
139
-
/**
140
-
* Bind the new state value to your subscribers.
141
-
*
142
-
* Receives the next version of state. Unlike `bindSubscriber`,
143
-
* this function does not automatically update the store
144
-
* beforehand, and requires you to manually do so
145
-
* via the `setState` helper.
146
-
*
147
-
* @param{Array.<[object, *]>}subscriptions - array of all subscriptions
148
-
* @param{object}nextState - the version of state given by your reducer
149
-
* @param{Function}setState - binds state to the store
> `subscriptions (subscription[])`: An array containing all subscriptions.<br/>`nextState (object)`: The state object as returned by the reducer.<br/>`setState (function)`:
104
+
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.
155
106
156
107
### subscribe
157
108
@@ -195,8 +146,8 @@ class FooItems {
195
146
returnthis.foo
196
147
}
197
148
198
-
setaddItem(item) {
199
-
dispatch("ADD_FOO_ITEM", { item })
149
+
addItem(item) {
150
+
dispatch("ADD_ITEM", { item })
200
151
}
201
152
}
202
153
@@ -206,8 +157,37 @@ fooBar.addItem("bop")
206
157
207
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.
208
159
209
-
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.
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).
210
161
211
162
Finally, the result would then be handed over to `bindState`.
212
163
213
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.
165
+
166
+
## Data model
167
+
168
+
Core Flux has a relatively simple data model that you should understand when creating your bindings.
169
+
170
+
Here is how state looks in all cases:
171
+
172
+
```js
173
+
Store {
174
+
state: { ... },
175
+
subscriptions: [
176
+
[subscriber, data],
177
+
[subscriber, data],
178
+
[subscriber, data],
179
+
// ...
180
+
]
181
+
}
182
+
```
183
+
184
+
Each item in `subscriptions` contains a `subscriber` and some form of `data` that informs a relationship between `state` and `subscriber`.
185
+
186
+
NOTE: You define `data` in the above model, be it an object, array, string; it can be anything you want. Ultimately, you're responsible for communicating state relationships to subscribers.
187
+
188
+
## Data flow
189
+
190
+
Here is the general lifecycle of subscribing to the store & dispatching a state update.
0 commit comments