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

client-plugin-lifecycle.mdx (Creating Plugins - Client Plugin Lifecycle)

Browse Source 
Summary:
Restyle of page, including changes to spelling, grammar, links, and structure (where relevant).

This diff includes a new version of the images:
bg-plugin-lifecycle.png
regular-plugin-lifecycle.png

The old versions have been renamed to:
bg-plugin-lifecycle.bak
regular-plugin-lifecycle.bak

Reviewed By: aigoncharov

Differential Revision: D36630758

fbshipit-source-id: 29922750364e1dd6f959bd297e3b5d5e6cf1a9ac
This commit is contained in:
Kevin Strider
2022-05-25 03:42:25 -07:00
committed by Facebook GitHub Bot
parent ee006a961b
commit b75eeb941b
5 changed files with 11 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docs/extending/client-plugin-lifecycle.mdx
View File

@@ -4,20 +4,25 @@ title: Client Plugin Lifecycle
---
import useBaseUrl from '@docusaurus/useBaseUrl';
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.
There are two types of client plugin: [Regular](#regular-plugin-lifecycle) and [Background](#background-plugin-lifecycle). It's recommended you start off with a regular plugin and switch 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).
For both types of plugin, it's recommended you start work after the `onConnect` is called then terminate work 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
## 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.
The process is illustrated in the following diagram.
<img alt="Regular Plugin Lifecycle diagram" src={useBaseUrl("img/regular-plugin-lifecycle.png")} />
## 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">
Even for background plugins, `onDisconnect` and `onConnect` may be called on a plugin (such as if the user restarts Flipper). Plugins should handle this accordingly by making sure to resend any important data to the reconnected instance. The process is illustrated in the following diagram.
:::warning
Note that a plugin must be enabled by the user for its messages to be queued up.
</div>
:::
<img alt="Background Plugin Lifecycle diagram" src={useBaseUrl("img/bg-plugin-lifecycle.png")} />