Skip to content

Commit fe9642c

Browse files
author
Niall Brennan
committed
add flush policy docs
1 parent 06de547 commit fe9642c

File tree

1 file changed

+70
-0
lines changed
  • src/connections/sources/catalog/libraries/mobile/react-native

1 file changed

+70
-0
lines changed

src/connections/sources/catalog/libraries/mobile/react-native/index.md

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -339,6 +339,76 @@ If you don't do this, the old client instance would still exist and retain the t
339339

340340
Ideally, you shouldn't have to use this method, and the Segment client should be initialized only once in the application lifecycle.
341341
342+
## Controlling Upload With Flush Policies
343+
To more granurily control when events are uploaded you can use `FlushPolicies`
344+
A Flush Policy defines the strategy for deciding when to flush, this can be on an interval, on a certain time of day, after receiving a certain number of events or even after receiving a particular event. This gives you even more flexibility on when to send event to Segment.
345+
To make use of flush policies you can set them in the configuration of the client:
346+
```ts
347+
const client = createClient({
348+
// ...
349+
flushPolicies: [
350+
new CountFlushPolicy(5),
351+
new TimerFlushPolicy(500),
352+
new StartupFlushPolicy(),
353+
],
354+
});
355+
```
356+
You can set several policies at a time. Whenever any of them decides it is time for a flush it will trigger an upload of the events. The rest get reset so that their logic restarts after every flush.
357+
That means only the first policy to reach `shouldFlush` gets to trigger a flush at a time. In the example above either the event count gets to 5 or the timer reaches 500ms, whatever comes first will trigger a flush.
358+
We have several standard FlushPolicies:
359+
- `CountFlushPolicy` triggers whenever a certain number of events is reached
360+
- `TimerFlushPolicy` triggers on an interval of milliseconds
361+
- `StartupFlushPolicy` triggers on client startup only
362+
363+
### Adding or removing policies
364+
One of the main advatanges of FlushPolicies is that you can add and remove policies on the fly. This is very powerful when you want to reduce or increase the amount of flushes.
365+
For example you might want to disable flushes if you detect the user has no network:
366+
```ts
367+
import NetInfo from "@react-native-community/netinfo";
368+
const policiesIfNetworkIsUp = [
369+
new CountFlushPolicy(5),
370+
new TimerFlushPolicy(500),
371+
];
372+
// Create our client with our policies by default
373+
const client = createClient({
374+
// ...
375+
flushPolicies: policies,
376+
});
377+
// If we detect the user disconnects from the network remove all flush policies,
378+
// that way we won't keep attempting to send events to segment but we will still
379+
// store them for future upload.
380+
// If the network comes back up we add the policies back
381+
const unsubscribe = NetInfo.addEventListener((state) => {
382+
if (state.isConnected) {
383+
client.addFlushPolicy(...policiesIfNetworkIsUp);
384+
} else {
385+
client.removeFlushPolicy(...policiesIfNetworkIsUp)
386+
}
387+
});
388+
```
389+
### Creating your own flush policies
390+
You can create a custom FlushPolicy special for your application needs by implementing the `FlushPolicy` interface. You can also extend the `FlushPolicyBase` class that already creates and handles the `shouldFlush` value reset.
391+
A `FlushPolicy` only needs to implement 2 methods:
392+
- `start()`: Executed when the flush policy is enabled and added to the client. This is a good place to start background operations, make async calls, configure things before execution
393+
- `onEvent(event: SegmentEvent)`: Gets called on every event tracked by your client
394+
- `reset()`: Called after a flush is triggered (either by your policy, by another policy or manually)
395+
They also have a `shouldFlush` observable boolean value. When this is set to true the client will atempt to upload events. Each policy should reset this value to `false` according to its own logic, although it is pretty common to do it inside the `reset` method.
396+
```ts
397+
export class FlushOnScreenEventsPolicy extends FlushPolicyBase {
398+
onEvent(event: SegmentEvent): void {
399+
// Only flush when a screen even happens
400+
if (event.type === EventType.ScreenEvent) {
401+
this.shouldFlush.value = true;
402+
}
403+
}
404+
reset(): void {
405+
// Superclass will reset the shouldFlush value so that the next screen event triggers a flush again
406+
// But you can also reset the value whenever, say another event comes in or after a timeout
407+
super.reset();
408+
}
409+
}
410+
```
411+
342412
## Automatic screen tracking
343413
As sending a screen() event with each navigation action can get tiresome, it's best to track navigation globally. The implementation is different depending on which library you use for navigation. The two main navigation libraries for React Native are [React Navigation](https://reactnavigation.org/){:target="_blank"} and [React Native Navigation](https://wix.github.io/react-native-navigation/docs/before-you-start/){:target="_blank"}.
344414

0 commit comments

Comments
 (0)