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
@@ -360,6 +361,9 @@ By default it's configured to intercept actions for fetching data following the
360
361
361
362
`queueReleaseThrottle`: waiting time in ms between dispatches when flushing the offline queue. Useful to reduce the server pressure when coming back online. Defaults to 50ms.
362
363
364
+
`shouldDequeueSelector`: function that receives the redux application state and returns a boolean. It'll be executed every time an action is dispatched, before it reaches the reducer. This is useful to control if the queue should be released when the connection is regained and there were actions queued up. Returning `true` (the default behaviour) releases the queue, whereas returning `false` prevents queue release. For example, you may wanna perform some authentication checks, prior to releasing the queue. Note, if the result of `shouldDequeueSelector` changes *while* the queue is being released, the queue will not halt. If you want to halt the queue *while* is being released, please see relevant FAQ section.
365
+
366
+
363
367
##### Thunks Config
364
368
For `redux-thunk` library, the async flow is wrapped inside functions that will be lazily evaluated when dispatched, so our store is able to dispatch functions as well. Therefore, the configuration differs:
// After rehydration completes, we detect initial connection
597
600
checkInternetConnection().then(isConnected=> {
598
-
store.dispatch({
599
-
type:offlineActionTypes.CONNECTION_CHANGE,
600
-
payload: isConnected,
601
-
});
601
+
store.dispatch(connectionChange(isConnected));
602
602
callback(); // Notify our root component we are good to go, so that we can render our app
603
603
});
604
604
});
@@ -641,25 +641,32 @@ export default App;
641
641
642
642
This way, we make sure the right actions are dispatched before anything else can be.
643
643
644
-
#### How to intercept and queue actions when the server responds with client (4xx) or server (5xx) errors
645
-
You can do that by dispatching yourself an action of type `@@network-connectivity/FETCH_OFFLINE_MODE`. The action types the library uses are exposed under `offlineActionTypes` property.
644
+
#### How do I stop the queue *while* it is being released?
645
+
646
+
You can do that by dispatching a `CHANGE_QUEUE_SEMAPHORE` action using `changeQueueSemaphore` action creator. This action is used to manually stop and resume the queue even if it's being released.
646
647
647
-
Unfortunately, the action creators are not exposed yet, so I'll release soon a new version with that fixed. In the meantime, you can check that specific action creator in [here](https://github.com/rgommezz/react-native-offline/blob/master/src/actionCreators.js#L18), so that you can emulate its payload. That should queue up your action properly.
648
+
It works in the following way: if a `changeQueueSemaphore('RED')` action is dispatched, queue release is now halted. It will only resume if another if `changeQueueSemaphore('GREEN')` is dispatched.
0 commit comments