Summary:
Adds a new type of plugin: `FlipperBackgroundPlugin`
Background plugins are not torn down when the user switches to another plugin so they keep receiving messages in the background.
Background plugins need to use persistedState to keep their data. To handle the messages received in the background they need to implement a static method that merges a message with the current state from redux. The plugin doesn't need to call this method itself, it is called from `client.js`.
```static persistedStateReducer = (
persistedState: PersistedState,
data: Object,
): PersistedState
```
This method is used to handle messages in both foreground and background.
Reviewed By: danielbuechele
Differential Revision: D10256305
fbshipit-source-id: d86da9caa1b75178841a9a347eb427112141eaa3
Summary: Invert the way device plugin <-> device support works with the long term goal of supporting user defined device plugins
Reviewed By: danielbuechele
Differential Revision: D10240765
fbshipit-source-id: 9e886518a2fbfd263c79daa4b805c088ab38ab87
Summary:
- Adds the Flipper notifications UI from the hackweek
- The notifications plugin is hidden behind a GK `flipper_notifications`
- Plugins currently can not dispatch any notifications
Reviewed By: jknoxville, passy
Differential Revision: D10300838
fbshipit-source-id: 2a3a823f09fee3370ce725b506b162e57751c382
Summary:
Method `computeNotifications` added to the base plugin class.
Plugins should implement this to define a mapping from their state+props to the notifications they are emitting.
I've plugged this into componentDidUpdate, because we don't yet have the background plugin infra. When we do, we'll want some other incoming data hook to use so it's not tied to the react component rendering.
Example usage added to network plugin in the next commit.
Reviewed By: passy
Differential Revision: D10127875
fbshipit-source-id: efd4d8cfc0d3d33852a6cf9a290549a5f90d389d
Summary:
Plugins had their custom setup method which needed to be called externally. That is what consturctors are for. This removes the setup method and moves ths logic to the constructor.
The setup method was called to late which caused the graphQL plugin to crash. With the logic now being in the constructor, it is ensured that it is called at the initialization.
Reviewed By: jknoxville
Differential Revision: D8769807
fbshipit-source-id: 7b4ab4815bbe397c80998adcb89ca361df6970d3
Summary:
This saved the state of the network plugin even when switching between plugins using persistedState.
A bug in the Android implementation didn't clear the events that were already sent to the desktop.
Reviewed By: jknoxville
Differential Revision: D8752098
fbshipit-source-id: 152ec5da83958ad8124686f780d39983cbce563f
Summary:
Refactors the plugin architecture of Sonar:
- Before plugin rendering had it's own implementation of the react lifecycle. This means the `render`-function was not called by react, but rather by the application it self. In this diff, the render method is now called from react, which enables better debugging and allows react to do optimizations.
- Business logic for querying emulators is moved away from the view components into its own dispatcher
- All plugin handling is moved from `App.js` to `PluginContainer`.
- The sidebar only shows one selected device. This allows us to add the screenshot feature as part of the Sonar main app and not a plugin.
- This also fixes the inconsistency between the devices button and the sidebar
Reviewed By: jknoxville
Differential Revision: D8186933
fbshipit-source-id: 46404443025bcf18d6eeba0679e098d5440822d5
Summary: The `Client` and `Server` code was in one file, which was messy. This splits it into two separate files.
Reviewed By: emilsjolander
Differential Revision: D8186932
fbshipit-source-id: faa79d7dccd867d69ccd1bccd43a2cf85314b1b3
