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
Copy file name to clipboardExpand all lines: packages/action-listener-middleware/README.md
+18-17Lines changed: 18 additions & 17 deletions
Original file line number
Diff line number
Diff line change
@@ -59,7 +59,7 @@ The Redux community has settled around three primary side effects libraries over
59
59
60
60
- Thunks use basic functions passed to `dispatch`. They let users run arbitrary logic, including dispatching actions and getting state. These are mostly used for basic AJAX requests and logic that needs to read from state before dispatching actions
61
61
- Sagas use generator functions and a custom set of "effects" APIs, which are then executed by a middleware. Sagas let users write powerful async logic and workflows that can respond to any dispatched action, including "background thread"-type behavior like infinite loops and cancelation.
62
-
- Observables use RxJS obesrvable operators. Observables form pipelines that do arbitrary processing similar to sagas, but with a more functional API style.
62
+
- Observables use RxJS observable operators. Observables form pipelines that do arbitrary processing similar to sagas, but with a more functional API style.
63
63
64
64
All three of those have strengths and weaknesses:
65
65
@@ -167,7 +167,7 @@ The return value is a standard `unsubscribe()` callback that will remove this li
167
167
168
168
The `listener` callback will receive the current action as its first argument, as well as a "listener API" object similar to the "thunk API" object in `createAsyncThunk`.
169
169
170
-
The listener may be configured to run _before_ an action reaches the reducer, _after_ the reducer, or both, by passing a `when` option when adding the listene. If the `when` option is not provided, the default is 'afterReducer':
170
+
The listener may be configured to run _before_ an action reaches the reducer, _after_ the reducer, or both, by passing a `when` option when adding the listener. If the `when` option is not provided, the default is 'afterReducer':
171
171
172
172
```ts
173
173
middleware.addListener({
@@ -228,7 +228,7 @@ The `listenerApi` object is the second argument to each listener callback. It co
228
228
229
229
-`unsubscribe: () => void`: will remove the listener from the middleware
230
230
-`subscribe: () => void`: will re-subscribe the listener if it was previously removed, or no-op if currently subscribed
231
-
-`cancelPrevious: () => void`: cancels any previously running instances of this same listener. (The cancelation will only have a meaningful effect if the previous instances are paused using one of the `job` APIs, `take`, or `condition` - see "Job Management" in the "Usage" section for more details)
231
+
-`cancelPrevious: () => void`: cancels any previously running instances of this same listener. (The cancelation will only have a meaningful effect if the previous instances are paused using one of the `job` APIs, `take`, or `condition` - see "Cancelation and Job Management" in the "Usage" section for more details)
232
232
233
233
Dynamically unsubscribing and re-subscribing this listener allows for more complex async workflows, such as avoiding duplicate running instances by calling `listenerApi.unsubscribe()` at the start of a listener, or calling `listenerApi.cancelPrevious()` to ensure that only the most recent instance is allowed to complete.
234
234
@@ -289,39 +289,40 @@ This middleware lets you run additional logic when some action is dispatched, as
289
289
290
290
This middleware is not intended to handle all possible use cases. Like thunks, it provides you with a basic set of primitives (including access to `dispatch` and `getState`), and gives you freedom to write any sync or async logic you want. This is both a strength (you can do anything!) and a weakness (you can do anything, with no guard rails!).
291
291
292
-
As of v0.4.0, the middleware does include several async workflow primitives that are sufficient to write equivalents to many Redux-Saga effects operators, like `takeLatest`, `takeLeading`, and `debounce`.
292
+
As of v0.4.0, the middleware does include several async workflow primitives that are sufficient to write equivalents to many Redux-Saga effects operators like `takeLatest`, `takeLeading`, and `debounce`.
293
293
294
294
### Standard Usage Patterns
295
295
296
296
The most common expected usage is "run some logic after a given action was dispatched". For example, you could set up a simple analytics tracker by looking for certain actions and sending extracted data to the server, including pulling user details from the store:
You could also implement a generic API fetching capability, where the UI dispatches a plain action describing the type of resource to be requested, and the middleware automatically fetches it and dispatches a result action:
The provided `listenerPredicate` should be `(action, currentState?, originalState?) => boolean`
324
-
325
326
The `listenerApi.unsubscribe` method may be used at any time, and will remove the listener from handling any future actions. As an example, you could create a one-shot listener by unconditionally calling `unsubscribe()` in the body - it would run the first time the relevant action is seen, and then immediately stop and not handle any future actions.
326
327
327
328
### Writing Async Workflows with Conditions
@@ -400,7 +401,7 @@ test('condition method resolves promise when there is a timeout', async () => {
400
401
})
401
402
```
402
403
403
-
### Cancelation, and Job Management
404
+
### Cancelation and Job Management
404
405
405
406
As of 0.4.0, the middleware now uses a `Job` abstraction to help manage cancelation of existing listener instances. The `Job` implementation is based on https://github.com/ethossoftworks/job-ts .
0 commit comments