Summary:
Unified all imports of Logger. Some were called LogManager before.
Now the fb-stub and the fb variants use the same interface.
Constructor of Logger is no longer exposed so it can't be initialized twice, unless in the case you're explicitly using the fb variant, which has extra functionality.
Reviewed By: danielbuechele
Differential Revision: D14083929
fbshipit-source-id: 9b61a06e1264d5f142b5a9188465c99deaf18193
Summary:
Now that flipper is using rsocket requestResponse, the SDK is responding with an error when the connection for this plugin has been torn down.
To avoid flipper interpreting these as bad, keep track of which plugins are inited, and only worry about responses from these.
Reviewed By: danielbuechele
Differential Revision: D13973745
fbshipit-source-id: d4e6916f89b3b562e5dcf23c4fe5b5cb384a6ec4
Summary:
Fixes required to be able to run Flipper in node.js:
* Adds checks if the `window`-object exists before using it, to allow running in node.
* Imports from within Flipper should directly reference the file they are requiring instead of `import from 'flipper'`. This was done in most of the places. Fixed a few occurrences where this wasn't the case. This is to prevent cyclic dependencies in node.
* shared packages (React, ReactDOM and Flipper) were exposed on the `window` before, changed this to `global` as this works in browser and node.
* Adds some missing methods to our electron stubs (used for testing and headless Flipper)
Reviewed By: passy
Differential Revision: D13786577
fbshipit-source-id: 145d560f1446e7d0bdec2acd8dd54dae983d7b36
Summary: This diff adds a static function `onRegisterDevice` which is being called whenever an device gets registered. This callback is used to add loglisterner for android. I even moved the logic of iOS from `onRegisterPlugin` to this callback. The reason for not adding android log listener in `onRegisterPlugin` was that there were cases when baseDevice was not yet registered before calling `onRegisterPlugin`. For android, I want the instance of `BaseDevice` so that I can add logListener on it.
Reviewed By: danielbuechele
Differential Revision: D13563282
fbshipit-source-id: b5be40f3dbc808bdaeabae28423c563cf2345a22
Summary: This diff refactors CrashReporter Plugin. The business logic of crash reporter plugin was placed in the `iOSDevice.js` as it gets the hook to the initialisation of iOSDevice. This diff moves the business logic to the Crash Reporter plugin files under the plugins folder. To get the hook, so that we can add our watcher, I have added a static function over `FlipperBasePlugin`, which if exists, will be called once `REGISTER_PLUGIN` event is dispatched
Reviewed By: danielbuechele
Differential Revision: D13529035
fbshipit-source-id: 28216b273b4032727859107d8a6751c6465af9ac
Summary:
If a plugin was not loaded we used to ignore it. This diff still ignores the plugins that weren't loaded, but adds some information about them to the redux store. This information is used in the PluginDebugger.
These are the three reasons, why a plugin might not be loaded.
* `gatekeepedPlugins`: Plugin was ignored because of a GK
* `failedPlugins`: Plugin could not be requried/failed to parse
* `disabledPlugins`: Plugin disabled in `~/.flipper/config.json`
Information for each them is added to the redux store.
Reviewed By: passy
Differential Revision: D13516986
fbshipit-source-id: b7a55a159cb586d1a88fbb976248131c52a909c5
Summary:
Adding the properties from a plugin's `package.json` as static properties to the class.
The name from `package.json` is used as it's `id`.
This allows us in the future to add meta information about a plugin to it's package.json and still use the data inside the app.
Reviewed By: priteshrnandgaonkar
Differential Revision: D13417288
fbshipit-source-id: 3d0a62d4cb0115153cce1aaee677b9680fefebf4
Summary: Makes a crash reporter plugin as a device plugin
Reviewed By: passy
Differential Revision: D13203954
fbshipit-source-id: 02ef2aff05d5a240eaff588f9b515d3d610fc182
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
