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
{{ message }}
This repository was archived by the owner on May 17, 2019. It is now read-only.
Provides a higher order component that connects RPC methods to Redux as well as React component props
5
+
Provides a higher order component that connects RPC methods to Redux as well as
6
+
React component props
6
7
7
8
RPC is a natural way of expressing that a server-side function should be run in response to a client-side function call. Unlike [RESTful architectures](https://en.wikipedia.org/wiki/Representational_state_transfer), RPC-based architectures are not required to conform to statelessness constraints and are free to return session-scoped data. Additionally, the semantics of RPC calls are not constrained by the availability of suitably-descriptive HTTP methods and RPC calls can express complex state change requests more naturally as verbs (e.g. `returnProduct(id)`) rather than object-orientation (e.g. `PATCH /api/orders/:id`).
8
9
@@ -18,6 +19,7 @@ RPC is a natural way of expressing that a server-side function should be run in
18
19
*[Dependencies](#dependencies)
19
20
*[`withRPCRedux`](#withrpcredux)
20
21
*[`withRPCReactor`](#withrpcreactor)
22
+
*[`ResponseError`](#responseerror)
21
23
*[`mock`](#mock)
22
24
*[Other examples](#other-examples)
23
25
@@ -117,21 +119,24 @@ export default () => {
117
119
importRPCfrom'fusion-plugin-rpc-redux-react';
118
120
```
119
121
120
-
The plugin. Typically it should be registered to [`RPCToken`](#rpctoken). Installs an RPC provider at the root of the React tree.
122
+
The plugin. Typically it should be registered to [`RPCToken`](#rpctoken).
123
+
Installs an RPC provider at the root of the React tree.
The canonical token for the RPC plugin. Typically, it should be registered with the [RPC](#rpc) plugin.
131
+
The canonical token for the RPC plugin. Typically, it should be registered with
132
+
the [RPC](#rpc) plugin.
129
133
130
134
#### Dependencies
131
135
132
136
##### `UniversalEventsToken`
133
137
134
-
Required. See [https://github.com/fusionjs/fusion-plugin-universal-events#api](https://github.com/fusionjs/fusion-plugin-universal-events#api)
type RPCHandlers = {[string]: (rpcArgs: Object, ctx: Context) => Promise<Object>}
148
153
```
149
154
150
-
You can register a value of type `RPCHandlers` or a Plugin that provides a value of type `RPCHandlers`.
155
+
You can register a value of type `RPCHandlers` or a Plugin that provides a value
156
+
of type `RPCHandlers`.
151
157
152
158
##### `FetchToken`
153
159
154
-
Required. Browser-only. See [https://github.com/fusionjs/fusion-tokens#fetchtoken](https://github.com/fusionjs/fusion-tokens#fetchtoken)
Creates a higher order component with a prop mapped to the given RPC method. It can additionally configure the mapped method with parameters from state or from a transformation function.
181
+
Creates a higher order component with a prop mapped to the given RPC method. It
182
+
can additionally configure the mapped method with parameters from state or from
[`redux-reactors`](https://github.com/ganemone/redux-reactors) is a library that allows you to colocate Redux actions and reducers
279
+
[`redux-reactors`](https://github.com/ganemone/redux-reactors) is a library that
280
+
allows you to colocate Redux actions and reducers
237
281
238
-
The `fusion-plugin-rpc-redux-react` package provides a `withRPCReactor` HOC which facilitates implementing a Redux store using reactors.
282
+
The `fusion-plugin-rpc-redux-react` package provides a `withRPCReactor` HOC
283
+
which facilitates implementing a Redux store using reactors.
239
284
240
-
To use it, register the `fusion-plugin-react-redux` plugin with `reactorEnhancer` from `redux-reactors`:
285
+
To use it, register the `fusion-plugin-react-redux` plugin with
286
+
`reactorEnhancer` from `redux-reactors`:
241
287
242
288
```js
243
289
// src/main.js
@@ -276,7 +322,9 @@ export default {
276
322
}
277
323
```
278
324
279
-
Because `redux-reactors` is implemented as a Redux enhancer, it doesn't require building reducers in the traditional Redux way. Thus, the root reducer can simply be the identity function:
325
+
Because `redux-reactors` is implemented as a Redux enhancer, it doesn't require
326
+
building reducers in the traditional Redux way. Thus, the root reducer can
`incrementReactor:Component=> Component` is a React HOC. It defines three actions: `start`, `success` and `failure`, which correspond to the respective statuses of a HTTP request.
347
+
`incrementReactor:Component=> Component` is a React HOC. It defines three
348
+
actions: `start`, `success` and `failure`, which correspond to the respective
349
+
statuses of a HTTP request.
300
350
301
-
In the example above, when `increment` is called, the `start` action is dispatched, which runs a reducer that sets `state.loading` to true, `state.error` to false and keeps `state.count` intact. If the request completes successfully, `state.loading` is set to false, and `state.count` is updated with a new value. Similarly, if the request fails, `state.error` is set.
351
+
In the example above, when `increment` is called, the `start` action is
352
+
dispatched, which runs a reducer that sets `state.loading` to true,
353
+
`state.error` to false and keeps `state.count` intact. If the request completes
354
+
successfully, `state.loading` is set to false, and `state.count` is updated with
355
+
a new value. Similarly, if the request fails, `state.error` is set.
302
356
303
-
In addition to defining action/reducer pairs, the `incrementReactor` HOC also maps RPC methods to React props.
357
+
In addition to defining action/reducer pairs, the `incrementReactor` HOC also
358
+
maps RPC methods to React props.
304
359
305
-
Reactors typically need to be used in conjunction with `connect` from `react-redux`, in order to map state to React.
360
+
Reactors typically need to be used in conjunction with `connect` from
361
+
`react-redux`, in order to map state to React.
306
362
307
-
Below is an example of consuming the state and RPC methods that are made available from the Redux store and the RPC plugin.
363
+
Below is an example of consuming the state and RPC methods that are made
364
+
available from the Redux store and the RPC plugin.
### Differences between reactors and vanilla Redux
337
394
338
-
Redux colocates all valid actions in a respective "slot" in the state tree, and colocates the structuring of the state tree via helpers such as `combineReducers`. This means that a reducer can be unit tested by simply calling the reducer with one of the valid actions, without having any effect on any other state that might exist in the app. The downside is that if an action needs to modify multiple "slots" in the state tree, it can be tedious to find all transformations pertaining to any given action.
339
-
340
-
Another point worth mentioning is that with traditional reducers, it's possible to refactor the state tree in such a way that doesn't make any changes to reducers or components (albeit it does require changing the reducer composition chain as well as all relevant `mapStateToProps` functions).
341
-
342
-
Reactors, on the other hand, colocate a single reducer to a single action, so all state transformations pertaining to any given action are handled by a single function. This comes at the cost of flexibility: it's no longer possible to refactor the shape of the state tree without changing every affectd reducer, and it's also possible to affect unrelated parts of the state tree, for example missing properties due to an overly conservative object assignment.
343
-
344
-
However doing large refactors to the shape of the state tree isn't necessarily all that common and it's often more intuitive to see all possible state transformations for a given action in a single place. In addition to creating less boilerplate, this pattern leads to similarly intuitive tests that are also colocated by action.
395
+
Redux colocates all valid actions in a respective "slot" in the state tree, and
396
+
colocates the structuring of the state tree via helpers such as
397
+
`combineReducers`. This means that a reducer can be unit tested by simply
398
+
calling the reducer with one of the valid actions, without having any effect on
399
+
any other state that might exist in the app. The downside is that if an action
400
+
needs to modify multiple "slots" in the state tree, it can be tedious to find
401
+
all transformations pertaining to any given action.
402
+
403
+
Another point worth mentioning is that with traditional reducers, it's possible
404
+
to refactor the state tree in such a way that doesn't make any changes to
405
+
reducers or components (albeit it does require changing the reducer composition
406
+
chain as well as all relevant `mapStateToProps` functions).
407
+
408
+
Reactors, on the other hand, colocate a single reducer to a single action, so
409
+
all state transformations pertaining to any given action are handled by a single
410
+
function. This comes at the cost of flexibility: it's no longer possible to
411
+
refactor the shape of the state tree without changing every affectd reducer, and
412
+
it's also possible to affect unrelated parts of the state tree, for example
413
+
missing properties due to an overly conservative object assignment.
414
+
415
+
However doing large refactors to the shape of the state tree isn't necessarily
416
+
all that common and it's often more intuitive to see all possible state
417
+
transformations for a given action in a single place. In addition to creating
418
+
less boilerplate, this pattern leads to similarly intuitive tests that are also
0 commit comments