Summary: Flipper Sandy plugins didn't have an event to hook into that is run _after_ any state snapshot is loaded, which was needed by the graphQL plugin, as they do some post processing when a data snapshot is restored.
Reviewed By: passy
Differential Revision: D28189573
fbshipit-source-id: 4ef992f3fafc32787eab3bc235059f2c41396c80
Summary:
Noticed in reviews during the convertathon there is still quite some boilerplate in things that happen on the boundary of UI and plugin state, such as setting up menu entries and providing common functionality like clear, master/detail layout, etc.
This diff introduces the `MasterDetail` component, which takes a higher level approach by merely needing to provide the state atoms and desired features, and taking care of the wiring.
Applied it to createTablePlugin, to prove that going from `createTablePlugin` to `MasterDetail` will be a much smaller step now.
Verified on the funnel logger plugin
Reviewed By: passy
Differential Revision: D28090362
fbshipit-source-id: 146f8c315fea903901ad4e3e46711642f16cf0e6
Summary: This diff exposes the createTablePlugin from flipper-plugin, so that createTablePlugin based plugins can be converted to Sandy as well
Reviewed By: jknoxville
Differential Revision: D28031227
fbshipit-source-id: 8e9c82da08a83fddab740b46be9917b6a1023117
Summary:
In many cases, the onExport handler doesn't try to customise the format, but merely fetch some additional information before creating an export.
By allowing the `onExport` handler to also return nothing, and instead merely update existing state, this case will be easier to express now;
Reviewed By: nikoant
Differential Revision: D28026558
fbshipit-source-id: 2b90b3e1ced6a6a5b42938b6f6b74b0eb9ceafc0
Summary: The `logger` was currently only available in a React context, and not directly exposed from the `client` API as well. This diff fixes it. The infrastructure including test stubs were present already, so the change is minimal.
Reviewed By: nikoant
Differential Revision: D28010120
fbshipit-source-id: cdd09ed236f5d92d07005d4e5a699360596281e4
Summary:
Some styling fixes and minor improvements in DataTable, used by network plugin:
- be able to customise the context menu
- be able to customise how entire rows are copied and presented on the clipboard to be able to deviate from the standard JSON
- deeplink handling was made async, this gives the plugin the opportunity to first handle initial setup and rendering before trying to jump somewhere which is a typical use case for deeplinking
Reviewed By: passy
Differential Revision: D27947186
fbshipit-source-id: a56f081d60520c4bc2ad3c547a8ca5b9357e71a1
Summary: This moves `<DetailSidebar>` component to `flipper-plugin` and documents it. No semantic changes.
Reviewed By: passy
Differential Revision: D27234575
fbshipit-source-id: 74640602d718f84ad999f5dac0420089796ed7fb
Summary:
Use Logs2 plugin now as the default logs plugin (by overwriting it).
See the rest of this stack
Changelog: The device logs plugin has been fully rewritten. It is faster and more reponsive, formats urls and json, and supports line wrapping and text selection. Beyond that it is now possible to sort and filter on all columns and pause and resume the log stream.
Reviewed By: nikoant
Differential Revision: D27048528
fbshipit-source-id: e18386fec6846ac3568f33a3578f4742213ecaca
Summary:
This diff converts the CrashReporter plugin to Sandy. The main driver is that it allows us to fix the connection management of logs in a next diff.
There are few changes to highlight:
* A bunch of the old unit tests are removed, as they primarily verified that persistedState abstraction works, a concept that doesn't exist anymore with Sandy (as a result all the logic in error handling and crash reporter plugin has become a lot more trivial as well)
* Added additional unit tests to verify that the integration with notifications from Sandy, and the integration of crashes in combination with CrashReporter plugin works (this wasn't the case before)
* Plugin errors were always suppressed in production builds of Flipper. However, that makes error reporting pretty pointless in the first place, so enabled it by default, but made it a setting in case this results in too many errors suddenly.
* The integration with clicking OS crash notification -> bringing the user to a sensible place _doesn't_ work, but it didn't work before this diff either, so will address that later
* This doesn't upgrade the Crash reporter UI to sandy yet, will do that later in a separate diff
Changelog: Crash reporter will now report errors triggered from the device / client plugins by default. This can be disabled in settings.
Reviewed By: priteshrnandgaonkar
Differential Revision: D27044507
fbshipit-source-id: 8233798f5cce668d61460c948c24bdf92ed7c834
Summary: Exposed the `pluginKey` to sandy plugins (which we will use later for storing table preferences per plugin). And a little moving code around because circular deps problem roared its ugly head again.
Reviewed By: nikoant
Differential Revision: D27009721
fbshipit-source-id: 7ad29e72ff8028c9daae270c4749b657bd8ff049
Summary: Make sure that DataSources can be serialized directly with a single setting, just like plain state atoms
Reviewed By: nikoant
Differential Revision: D26944954
fbshipit-source-id: 2b0d625d7d67f27a7c2e33dd7c4b534dfa4d3e82
Summary: ..and some earlier reviews comments has been processed + some fine tuning on the ui
Reviewed By: priteshrnandgaonkar
Differential Revision: D26816559
fbshipit-source-id: adf2586763be185ee8e7cc22b2827ecefe4e4cab
Summary:
Introduced a context menu for DataTable with some default options. Opted to put it under a visible hovered dropdown instead of on right-click, since this better alings with Ant's design guides (we don't have context clicks anywhere else I think), but if it isn't convincing we can still change it.
Included some default actions, to set up quick filters, and to copy values. For copying rows, implemented it to by default take the JSON from a row, rather than space separated values like in ManagedTable, as many existing plugins customize the onCopy handler to just do that, so it seemed like a better default since it is a richer format. If there are good use cases for the previous behavior, we'll probably find out after the old release :)
Introduced utility to copy text to clipboard in FlipperLib, but decoupled it from Electron.
Didn't include multi select yet, that will be done in a next diff.
Reviewed By: nikoant
Differential Revision: D26513161
fbshipit-source-id: b2b1b20b0a6f4ada9de2566bf6b02171f722c4aa
Summary:
Noticed that subsequent `adb logcat` invocations are stateful, and we didn't clear it's state when clearing the logs in memory.
This is a bandaid to get back to the previous behavior. I am wondering whether it wouldn't be just much more intuitive to always clear the logs (`adb logcat -c`) before we start the streaming log listener, so that users are never shown old logs from before flipper was connected?
Also fixed a leak in cleaning up the log listeners that was revealed by the possibility to disable the log plugin
Reviewed By: nikoant
Differential Revision: D26450262
fbshipit-source-id: 5b426e2d0e1fafdbc512d48d22b7bd4f30b61309
Summary:
*Stack summary*: this stack adds ability to manage device plugins in the same way as client plugins: install, update, uninstall, enable (star) and disable (unstar) them.
*Diff summary*: changed the way how plugin compatibility with devices is checked from dynamic call to "supportsDevice" to static checks of "supportedDevices" metadata property which make it possible to check compatibility without even downloading plugin from Marketplace.
Changelog: plugin compatibility with devices is now checked according to metadata in property "supportedDevices" in package.json
Reviewed By: mweststrate
Differential Revision: D26315848
fbshipit-source-id: 6e4b052c4ea0507ee185fc17999b6211cdb11093
Summary:
Minor code cleanup to avoid future confusion:
- archived: a device that was imported from a Flipper trace, and only has persisted state
- (dis)connected: a real stateful device that might or might not have an active connection
Reviewed By: nikoant
Differential Revision: D26275459
fbshipit-source-id: eba554b37c39711e367c3795ff4456329a303c22
Summary:
This diff addresses two problems:
1. Since clients plugins can be active beyond having a connection, we have to make it possible for plugin authors to check if they are connected before they make a call.
2. if there is a custom `exportPersistedState`, plugins should be able to skip making calls if the device has disconnected.
Introducing this change makes it possible to interact with a reasonable level with disconnected clients, and makes it possible to create Flipper traces for disconnected clients.
Note that both items were already problems before supporting offline clients; as there can be a noticeable delay between disconnecting and Flipper detecting that (i've seen up to 30 secs). What happend previously in those cases is that the export would simply hang, as would other user interactions, as loosing the connection in the middle of a process would cause the promise chains to be neither rejected or resolved, which is pretty iffy.
Before this diff, trying to export a disconnected device would hang forever like:
{F369600601}
Reviewed By: nikoant
Differential Revision: D26250895
fbshipit-source-id: 177624a116883c3cba14390cd0fe164e243bb97c
Summary:
It should be possible to exported disconnected devices, so that flipper traces / support form reports can be created from them. This diff introduces this functionality. Support for plugins with custom export logic is introduced in a later diff.
Issues fixed in this diff:
- don't try to take a screenshot for a disconnected device (this would hang forever)
- device plugins were always exported, regardless whether the user did select them or not
- sandy plugins were never part of exported disconnected clients
- increased the amount of data exported for device logs to ~10 MB. This makes more sense now as the logs will no longer be included in all cases
- fixed issue where are plugins would appear to be enabled after the client disconnected (this bug is the result of some unfortunate naming of `isArchived` vs `isConnected` semantics. Will clean up those names in a later diff.
Changelog: It is now possible to create a Flipper trace for disconnected devices and apps
Reviewed By: nikoant
Differential Revision: D26250894
fbshipit-source-id: 4dd0ec0cb152b1a8f649c31913e80efc25bcc5dd
Summary:
Introduced `isConnected` flag on device and plugin client to reflect whether a connection is still available for the plugins, or that they have been disconnected.
Potentially we could expose the (readonly) `connected` state atom for this as well, or an `onDisconnect` event for device pugins, to create a responsive UI, but there might be no need for that, in which case this suffices.
Reviewed By: nikoant
Differential Revision: D26249346
fbshipit-source-id: b8486713fdf2fcd520488ce54f771bd038fd13f8
Summary:
This diff stack introduces support for keeping devices and clients around after they have disconnected. This is a pretty important debugging improvement, that will allow inspecting a device / app after it crashed for example.
This feature existed partially before, but only supported Android, and only support plugins with persisted state; as it replace the current device with an archived version of the same device. In practice this didn't work really well, as most plugins would not be available, and all non-persisted state would be lost.
This diff makes sure we can keep devices around after disconnecting, the next one will keep the clients around as well. And explain some code choices in more detail.
Note that `Device.isArchived` was an overloaded term before, and even more now (both representing imported and disconnected devices), will address that in a later diff.
https://github.com/facebook/flipper/issues/1460https://github.com/facebook/flipper/issues/812https://github.com/facebook/flipper/issues/1487
Changelog: iOS and Android devices will preserve their state after being disconnected
Reviewed By: nikoant
Differential Revision: D26224310
fbshipit-source-id: 7dfc93c2a109a51c2880ec212a00463bc8d32041
Summary:
Logs were stored hardcoded on the Device object first, this diff makes it normal plugin state.
This makes sure that we can use the same abstractions as in all plugins that store large data sets, and that we can leverage the upcoming DataSource abstraction.
Reviewed By: nikoant
Differential Revision: D26127243
fbshipit-source-id: 7c386a615fa7989f35ba0df5b7c1d218d37b57a2
Summary: Per title, this allows for pre-processing data after it is deserialized and before it is stored in the plugin
Reviewed By: nikoant
Differential Revision: D26126423
fbshipit-source-id: bc08a6ab205d2a0d551515563cd85a197595ddb2
Summary:
Sandy plugins can now set up an `onExport` handler to enable customizing the export format of a plugin: `client.onExport(callback: (idler, onStatusMessage) => Promise<state>)`
Import will be done in next diff
Reviewed By: nikoant
Differential Revision: D26124440
fbshipit-source-id: c787c79d929aa8fb484f15a9340d7c87545793cb
Summary: Plugin metadata format extended to include type of each plugin (client / device) and list of supported devices (android/ios/..., emulator/physical, etc). This will allow to detect plugins supported by device even if they are not installed and only available on Marketplace.
Reviewed By: mweststrate
Differential Revision: D26073531
fbshipit-source-id: e331f1be1af1046cd4220a286a1d52378c26cc53
Summary:
I've re-designed interfaces describing plugins as I found that mental overhead working with them became too expensive because of slightly flawed design. However this cascaded changes in many files so you can see how extensively these interfaces used in our codebase.
Before this change we had one interface PluginDetails which described three different entities: 1) plugins installed on the disk 2) plugins bundled into Flipper 3) plugins available on Marketplace. It's hard to use this "general" PluginDetails interface because of this as you always need to think about all three use cases everywhere.
After this change we have 3 separate interfaces: InstalledPluginDetails, BundledPluginDetails and DownloadablePluginDetails and things became much type-safer now.
Reviewed By: mweststrate
Differential Revision: D25530383
fbshipit-source-id: b93593916a980c04e36dc6ffa168797645a0ff9c
Summary:
Introduced API to replace the deprecated `selectPlugin` in Sandy.
The API can be used to navigate from `device plugin -> device plugin`, or` client plugin -> device / client plugin`
Introduced `isPluginAvailable` as well, so that the user interaction an be fine tuned in case the plugin is not disabled.
Reviewed By: jknoxville
Differential Revision: D25422370
fbshipit-source-id: c6c603f1c68e6291280b3d0883e474448754ded1
Summary:
`activatePlugin` events where not recorded correctly for Sandy plugins. Although the starting measuerments is fired the `connections` reducer, the completing event fires from `PluginContainer`. Since this is done as part of a ref-update (!!), see [here](https://www.internalfb.com/intern/diffusion/FBS/browse/master/xplat/sonar/desktop/app/src/PluginContainer.tsx?commit=65a625ea9941&lines=155), and the ref to the corresponding element is not set for Sandy plugins, the event was never marked as completed.
Fixed this by making it part of the `activate` life-cycle event of Sandy plugins.
Reviewed By: passy
Differential Revision: D25421537
fbshipit-source-id: 5cbfeb91cc12e4520fa271bab24034094d7ddb39
Summary: Make sure that GKs can be used in pure sandy plugins.
Reviewed By: jknoxville
Differential Revision: D25368358
fbshipit-source-id: c7c6aa4ecf0443cb3b5d90e22e8aca9a73a69389
Summary:
Set up basic primitives for user interaction tracking. I hope the docs and unit tests in this diff are self explanatory :)
In upcoming diffs:
* Wire up to scuba events
* Annotate all important parts of Flipper Chrome
* Investigate if we can wrap important interactions of ANT by default
Reviewed By: jknoxville
Differential Revision: D25120234
fbshipit-source-id: 9849d565d7be27e498cc2b4db33e7d6e6938ee06
Summary: `unstablebatched_updates` should be used whenever a non-react originating event might affect multiple components, to make sure that React batches them optimally. Applied it to the most import events that handle incoming device events
Reviewed By: nikoant
Differential Revision: D25052937
fbshipit-source-id: b2c783fb9c43be371553db39969280f9d7c3e260
Summary: This diff adds the `client.onUnhandledMessage` handler, to be able to handle messages for which we don't know the names upfront. Some existing plugins that only send one kind of message can benefit from this, as can generic plugins, like the createTablePlugin
Reviewed By: passy
Differential Revision: D24949453
fbshipit-source-id: 0fed81e28aee350632c09ee3bb834f306dc8b100
Summary: expose `appName`, `appId` and `device` to Sandy plugins. Will be used in next diff to migrate navigation plugin
Reviewed By: cekkaewnumchai
Differential Revision: D24857253
fbshipit-source-id: 03ac3d376d5d1950bcf3d78386a65ce167b517e3
Summary: `supportsMethod` wasn't implemented in the new sandy APIs so far, but is needed for D24108772
Reviewed By: cekkaewnumchai
Differential Revision: D24109496
fbshipit-source-id: 694344b423c1805baa193e4f2e1ad5f28483378b
Summary: In the attached task an IPv6 address ended up in the URL send from IG. Since that URL couldn't be parsed, it crashed the network plugin. This change makes sure the plugin doesn't crash on invalid urls.
Reviewed By: cekkaewnumchai
Differential Revision: D23344503
fbshipit-source-id: c7ac2068e407a764d59e632bef1be7c4239c8c8a
Summary:
Documented all exposed Sandy APIs plugin developers should know about.
Honestly didn't proof-read it myself yet, but wanted to publish this diff at least before PTO, so that the information is available to anyone interested / playing with sandy
Reviewed By: jknoxville
Differential Revision: D22976373
fbshipit-source-id: c30918201d2feeb306ca0d9a3ae1ec10bdf7e2f5
Summary: Little ux tweak, there are some rare scenarios where you can end up in an empty plugin screen, made a small message.
Reviewed By: jknoxville
Differential Revision: D22846396
fbshipit-source-id: 0ad19f1c252112d78a5587e6633fee2d9542d5e1
Summary:
Converted the DeviceLogs plugin to sandy.
Kept logic and UI the same (so same batching, localstorage mechanisms etc). But used sandy api's for log subscribing, state, and separating the logical part of the component from the UI.
Note that some mechanisms work slightly different, like deeplinking and scrollToBottom handling, to reflect the fact that plugins are now long lived
Reviewed By: jknoxville
Differential Revision: D22845466
fbshipit-source-id: 7c98b2ddd9121dc730768ee1bece7e71bb5bec16
Summary:
Added support for `createPaste` in Sandy plugins
Nice minimalistic example of how to expose a Flipper api to Sandy.
Note that some indirection could be removed by having an interface that is shared directly between `BasePluginClient` and `FlipperLib` (e.g. `PublicFlipperLib`). In contrast to `addMenuEntries` from the previous diff, `createPaste` is basically exposed verbatim to Sandy without additional wrapping, so those cases could be made simpler. Maybe will do that later.
Reviewed By: passy
Differential Revision: D22815873
fbshipit-source-id: e6d0773a35341edfe5de0898317eaadf88de79d0
Summary:
[interesting] since it shows how Flipper APIs are exposed through sandy. However, the next diff is a much simpler example of that
This diff adds support for adding menu entries for sandy plugin (renamed keyboard actions to menus, as it always creates a menu entry, but not necessarily a keyboard shortcut)
```
client.addMenuEntry(
// custom entry
{
label: 'Reset Selection',
topLevelMenu: 'Edit',
handler: () => {
selectedID.set(null);
},
},
// based on built-in action (sets standard label, shortcut)
{
action: 'createPaste',
handler: () => {
console.log('creating paste');
},
},
);
```
Most of this diff is introducing the concept of FlipperUtils, a set of static Flipper methods (not related to a device or client) that can be used from Sandy. This will for example be used to implement things as `createPaste` as well
Reviewed By: nikoant
Differential Revision: D22766990
fbshipit-source-id: ce90af3b700e6c3d9a779a3bab4673ba356f3933
Summary:
The device type enum was mixing two different concepts (emulator vs physical) and (archived vs not), and we already have a separate `isArchived` field. So cleaned this up to not leak it into sandy.
If anybody can think of any unforeseen consequences of this, lemme know :)
Reviewed By: jknoxville
Differential Revision: D22763506
fbshipit-source-id: bd2f7dbd1d2d2e6942ba7c6ddd8dc91ee34d591d
Summary: Introducing a base abstract class (blegh) to share some life cycle management between Device- and normal plugins. Cleaned up the test utils a bit as well + some old TODO's that now have been taken care of
Reviewed By: nikoant
Differential Revision: D22727089
fbshipit-source-id: 507816f1bfdbc6e7e71d4bd365b881b6710ca917
Summary:
Device plugins have an activate and deactivate hook, that reflects the plugin being selected in the UI. Added these same hooks to client plugins as well. In practice they are called at the same times as `onConnect` and `onDisconnect`, except for background plugins, which connect only once, so it is pretty useful to be still able to make the distinction.
Since there is now quite some common functionality between plugins and device plugins, will clean things a bit up in a next diff
[Interesting] as it explains the difference between the different lifecycle methods of plugins, and the impact of being a background plugin
LIfecycle summary:
1. app connects
2. for background plugins: connect them (`onConnect`)
3. user selects a plugin, triggers `onActivate`. will also trigger `onConnect` the plugin if it _isnt_ a bg plugin
4. user selects a different plugin, triggers `onDeactivate`. will also trigger `onDisconnect` if it isn't a bg plugin.
5. app is unloaded. Triggers `onDisconnect` for bg plugins. Triggers `onDestroy` for all plugins,
Reviewed By: jknoxville
Differential Revision: D22724791
fbshipit-source-id: 9fe2e666eb37fa2e0bd00fa61d78d2d4b1080137
Summary:
Make sure device plugins can be deeplinked as well.
(note that the duplication between `Plugin` and `DevicePlugin` is cleaned up again in D22727089, first wanted to make it work and tested, then clean)
DeepLink no longer have to be strings, per popular requests, as that makes direct linking between plugins easier (online links from the outside world have to arrive as strings)
Reviewed By: jknoxville, nikoant
Differential Revision: D22727091
fbshipit-source-id: 523c90b1e1fbf3700fdb4f62699dd57070cbc980
Summary: Now that we can load device plugins, let's make sure they are rendered as well.
Reviewed By: passy, nikoant
Differential Revision: D22693927
fbshipit-source-id: 22574ec6e629e6dd66e42193b406ceb7dfcf1836
Summary: Add unit tests to verify that the unit test utilities for for Sandy device plugins work as expected. Fixed a bug revealed by that and cleaned up some TODO's
Reviewed By: jknoxville, passy, nikoant
Differential Revision: D22693928
fbshipit-source-id: 93162db19d826d0cd7f642cef1447fd756261ac8
Summary:
This stack introduces Sandy device plugins, they are quite similar to normal plugins, but, a devicePlugin module is organized as
```
export function supportsDevice(device): boolean
export function devicePlugin(devicePluginClient)
export function Component
```
Device plugins get access to the device meta data and can subscribe to the `onLogEntry` callback and `onDestroy` lifecycle.
They will be able to store state just as normal plugins, but can't send or receive methods, so devicePluginClient is a bit limited.
This diff only sets up most of the new data structures, and makes sure everything still compiles and no existing tests fail.
To prevent this diff from becoming to big, actually loading, rendering and testing device plugins will be done in next diffs
Please take a critical look at the api proposed and the (especially) the public names used :)
Reviewed By: passy, nikoant
Differential Revision: D22691351
fbshipit-source-id: bdbbd7f86d14b646fc9a693ad19f33583a76f26d
