Summary:
Let's the notification render any React node.
Particularly useful when including links or wanting to
format messages.
Reviewed By: jknoxville
Differential Revision: D10488157
fbshipit-source-id: 06d3c6b4477c78e8bef78e3a3dc0e05bc67a2ef4
Summary:
Allow linking from one plugin to another. Adds a prop `selectPlugin` to the plugin that can be passed a pluginID and an optional `deepLinkPayload`.
The return value tells you if switching the plugin was successful.
```
selectPlugin: (pluginID: string, deepLinkPayload: ?string) => boolean,
```
Reviewed By: passy
Differential Revision: D10483925
fbshipit-source-id: 6f821277150b2db185b7d545c310214a11432eac
Summary: adding a `static defaultPersistedState` which plugins can use to populate their persistedState for the first render.
Reviewed By: passy
Differential Revision: D10446987
fbshipit-source-id: eb37553db7bbec31edf5b4972176e71f303639fe
Summary:
When sending a message from the mobile side, you call something like:
`send(method: string, params: Object)`
But when receiving it in the reducer, you only get the params. Adding method so you can distinguish them.
Reviewed By: passy
Differential Revision: D10447890
fbshipit-source-id: f1fe925e82355866f86b322ecd3c72c604ae86af
Summary:
Adding a static method plugins can implement to trigger notifications:
```
static getActiveNotifications: ?(persistedState: P) => Array<Notification>;
```
When the plugin's persisted state changes, this API is called from the `notification`-dispatcher which updates the notifications store.
Reviewed By: passy
Differential Revision: D10378434
fbshipit-source-id: 778fe3ad4229b03bd5ba14ebfdafa5020c25f34f
Summary:
Restore the logic for setting and computing notifications that was
partially removed with D10300838.
Reviewed By: jknoxville
Differential Revision: D10361547
fbshipit-source-id: 4d229d5f4dbeda3139463e1c348909b9c5dba66f
Summary: Put back deinit message and send deinit call even if the plugin is the background one
Reviewed By: danielbuechele
Differential Revision: D10300165
fbshipit-source-id: ef945282fe628e9196c21b5060a8e464e98bc94c
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
