Summary:
This diff adds the capability to export the flipper data to a file. With this diff you can click on the "Export Flipper" option from the "Edit" menu in menubar. It will export it in the file at this location
`~/.flipper/MessageLogs.json`
We do not exactly export the store, but just the important part of it. We export in the following format
```
{
fileVersion: '1.0',
device: {
os: 'iOS',
title: 'iPhone 7',
serial: '',
deviceType: 'physical',
},
clients: [
{
query: {
app: 'Facebook',
},
d: '12345678'
},
{
query: {
app: 'Instagram',
},
id: '12345678'
}
],
store: {
pluginState: {},
notifications: {}
}
}
```
In next diff I will add the capability to select the folder to export the file too.
Reviewed By: danielbuechele
Differential Revision: D13751963
fbshipit-source-id: 7d3d49c6adf8145b2181d2332c7dbd589155cec3
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: When a plugin has no gatekeeper defined, an incorrect warning was logged, saying that if fails the gatekeeper "undeinfed"
Reviewed By: jknoxville
Differential Revision: D13275803
fbshipit-source-id: 9ae5ed55031cc6a636c7c5ffa23bdd059a8ed35f
Summary: Adds test for the plugin reducer and dispatcher
Reviewed By: jknoxville, passy
Differential Revision: D13082652
fbshipit-source-id: 4af2c7721c4d88abbd332d610ff71d5db78e721c
Summary:
Plugins were loaded in `/plugins/index.js` which was loaded once at launch of the app. This moves the list of available plugins to redux. This way, plugins can be dynamically added. The redux store keeps to Maps of plugins (devicePlugins and clientPlugins) with their ID as key:
```
devicePlugins: Map<string, Class<FlipperDevicePlugin<>>>,
clientPlugins: Map<string, Class<FlipperPlugin<>>>,
```
On launch of the app, all plugins bundled with the app and the one found in `pluginsPath` are dynamically added.
This changes now allows to add new plugins at any time. All components that need to know which plugins are available (e.g. the sidebar) are connected to the redux store. This way, they will automatically update, whenever a new plugin is added.
- add `plugins` to the redux store to keep the list of available plugins
- add a plugins dispatcher, responsible for loading the plugins on launch
- connecting all React components that imported `plugins/index.js` before to the redux store to get the plugins from there.
- moved the updating of the MenuBar to the plugins dispatcher as it needs to update whenever a new plugin is added.
Reviewed By: jknoxville, passy
Differential Revision: D12449236
fbshipit-source-id: 6ef3e243e2c80443614b901ccbfde485fcb4301c
