5ad8106e3f
Summary: When using baseUrl in site config, it adds a prefix to all link paths. But for assets, it doesn't work if you refer to them as `docs/assets/...`, you have to use just `assets/...`. Source: https://github.com/facebook/Docusaurus/issues/861 Reviewed By: passy Differential Revision: D20796933 fbshipit-source-id: 2346e42b8b548f576a1e143f56ee5236eab55073
24 lines
1.6 KiB
Markdown
24 lines
1.6 KiB
Markdown
---
|
|
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>
|
|
|
|
|
|
|