jens/flipper
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Make sure that plugins don't store events unbounded

Browse Source 
Summary:
To avoid plugins to collect data forever and store it (if they are never opened), introduced a hard-coded default limit on how many events will be preserved.

A semantic change is that plugins have to be potentially resistant against missing events. So far, during testing, this didn't seem to cause any problems.

Reviewed By: jonathoma

Differential Revision: D19175912

fbshipit-source-id: 828be941e76b7356c9f5be7e5a49de9a7a31b0d2
This commit is contained in:
Michel Weststrate
2020-01-02 07:12:06 -08:00
committed by Facebook Github Bot
parent 8c8f360572
commit 0494a84d98
5 changed files with 78 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/extending/js-plugin-api.md
View File

@@ -78,6 +78,9 @@ static persistedStateReducer<PersistedState>(
```
The job of the `persistedStateReducer` is to merge incoming data into the state, so that next time the plugin is activated, the persisted state will be ready.
If a plugin has a `persistedStateReducer`, and the plugin is not open in flipper, incoming messages are queued until the plugin is opened.
The amount of events that is cached for a plugin is controlled by the optional static field `maxQueueSize`, which by default is set to `10000` events.
The data that is produced from `persistedStateReducer` should be immutable, but also structurally sharing unchanged parts of the state with the previous state to avoid performance hiccups. To simplify this process we recommend using the [Immer](https://immerjs.github.io/immer/docs/introduction) package.
Immer makes it possible to keep the reducer concise by directly supporting "writing" to the current state, and keeping track of that in the background.