Add lifecycle diagrams for regular and background plugins
Summary: I think this'll clarify how to use the lifecycle methods. Diagram edit link: https://excalidraw.com/#json=5696112581148672,nDwD6t1BNXVreQ8YE8917g Reviewed By: mweststrate Differential Revision: D20645302 fbshipit-source-id: 0814dbe8421cfe8e85c297bd5bfb4a8f1a83c353
This commit is contained in:
committed by
Facebook GitHub Bot
parent
4d866b0327
commit
0275d35233
BIN
docs/assets/bg-plugin-lifecycle.png
Normal file
BIN
docs/assets/bg-plugin-lifecycle.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 722 KiB |
BIN
docs/assets/regular-plugin-lifecycle.png
Normal file
BIN
docs/assets/regular-plugin-lifecycle.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 695 KiB |
23
docs/extending/client-plugin-lifecycle.md
Normal file
23
docs/extending/client-plugin-lifecycle.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: client-plugin-lifecycle
|
||||
title: Client Plugin Lifecycle
|
||||
---
|
||||
|
||||
There are two types of client plugin: Regular and Background plugins. We recommend starting off as a regular plugin and switching it to a background plugin if necessary.
|
||||
|
||||
For both types of plugin, we recommend starting work after `onConnect` is called, and terminating it after `onDisconnect`, when possible. This prevents wasted computation when Flipper isn't connected. If the plugin needs to keep track of events that occur before it gets connected (such as initial network requests on app startup), you should do so in the plugin constructor (or ideally in a separate class).
|
||||
|
||||
## Regular Plugin Lifecycle
|
||||
For regular plugins, `onConnect` and `onDisconnect` are triggered when the user opens the plugin in the Flipper UI, and when they switch to another plugin, respectively.
|
||||

|
||||
|
||||
## Background Plugin Lifecycle
|
||||
For background plugins, `onConnect` is called when Flipper first connects, and `onDisconnect` when it disconnects. The user does not need to be viewing the plugin for it to send messages; they will be queued up until the next time the user opens the plugin where they will be processed.
|
||||
|
||||
Even for background plugins, `onDisconnect` and `onConnect` may be called on a plugin (e.g. if the user restarts Flipper). Plugins should handle this accordingly by making sure to resend any important data to the reconnected instance.
|
||||
<div class="warning">
|
||||
Note that a plugin must be enabled by the user for its messages to be queued up.
|
||||
</div>
|
||||
|
||||

|
||||
|
||||
@@ -200,7 +200,7 @@ addPlugin({
|
||||
|
||||
## Background Plugins
|
||||
|
||||
In some cases you may want to provide data to Flipper even when your plugin is not currently active. Returning true in `runInBackground()` will result in `onConnect` being called as soon as Flipper connects, and allow you to use the connection at any time.
|
||||
In some cases you may want to provide data to Flipper even when your plugin is not currently active. Returning true in `runInBackground()` will result in `onConnect` being called as soon as Flipper connects, and allow you to use the connection at any time. See the [Client Plugin Lifecycle](client-plugin-lifecycle) for more details.
|
||||
|
||||
This should be used in combination with a `persistedStateReducer` on the desktop side. See the [JS Plugin API](js-plugin-api#background-plugins) for details.
|
||||
|
||||
|
||||
@@ -12,6 +12,9 @@
|
||||
"extending/arch": {
|
||||
"title": "Architecture"
|
||||
},
|
||||
"extending/client-plugin-lifecycle": {
|
||||
"title": "Client Plugin Lifecycle"
|
||||
},
|
||||
"extending/create-plugin": {
|
||||
"title": "Client Plugin API"
|
||||
},
|
||||
|
||||
@@ -50,6 +50,7 @@
|
||||
"extending/styling-components",
|
||||
"extending/search-and-filter",
|
||||
"extending/create-plugin",
|
||||
"extending/client-plugin-lifecycle",
|
||||
"extending/send-data",
|
||||
"extending/error-handling",
|
||||
"extending/testing",
|
||||
|
||||
Reference in New Issue
Block a user