Summary: Introduce the DataList component. Not feature complete yet, but core functionality is present so that people can use it during the convertathon. It is used to implement the route list in the network mock dialog
Reviewed By: priteshrnandgaonkar
Differential Revision: D27046716
fbshipit-source-id: a247ce7032b350b31bf55962ca4268e30f43471a
Summary: Expose a Panel api from Sandy, which is quite similar to the old one, except that it uses Antd, and it will remember the users closed / open preference through sessions, a much requested feature.
Reviewed By: nikoant
Differential Revision: D27966607
fbshipit-source-id: 9b18df377215c1e6c5844d0bf972058c8c574cbb
Summary:
This diff moves the core of ElementsInspector to flipper-plugin and decouples it from legacy design system and Electron, without any significant improvements or API changes yet, which will follow later.
Colors and docs will be added later in this stack.
Reviewed By: passy
Differential Revision: D27660300
fbshipit-source-id: 96abfa3b3174fa852cf04ae119c23c3d629fee74
Summary:
This diff moves the rest of the DataInspector jungle to flipper-plugin. No actual improvements are made yet, but the code is decoupled from Electron and the legacy theming. For example by using Antd based context menus.
Note that `ManagedDataInspector` is now rebranded `DataInspector`, as that is the only variation that should (and is) used publicly.
For the interactionTracker removal, see next diff.
SearchableDataInspector will be addressed in a next diff
Reviewed By: passy
Differential Revision: D27603125
fbshipit-source-id: 188bd000260e4e4704202ce02c7fc98319f0bc22
Summary:
Another utility component used by DataInspector.
Colors have been hardcoded for now, to decouple from the classic Flipper color palette. Will organize this better later in this stack, and when addressing / adding support for dark mode.
Buttons, checkboxes, selects have been replaced by Antd's counterpart.
Unlike ManagedDataTable, the DataInspector is primarily moved rather than copied & adapted, as the underlying abstraction / API won't change significantly. So the changes here will immediately affect all plugins in Flipper using this component.
Reviewed By: passy
Differential Revision: D27603126
fbshipit-source-id: bacd48c9af2b591033e7f2352627f11acb4df589
Summary: This stack moves the DataInspector component to flipper-plugin. The first diffs will move some utility abstractions to turn this into smaller steps
Reviewed By: passy
Differential Revision: D27591890
fbshipit-source-id: d0285ca31b6c9b334000dd15c722b9bda7638d73
Summary: just a rename, as we will have `data-inspector` folder as well in next diffs.
Reviewed By: passy
Differential Revision: D27591891
fbshipit-source-id: b1fe92cbf4be1633e623e59b694efc3f687c3413
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:
This diff deprecates the Sidebar concept, and copies the implementation to Sandy (tried moving first, but since existing plugins use the Sidebar in non-flex (Layout) contexts, that the layout of several plugins, so rather deprecated the old implementation.
Instead of exposing `Sidebar` explicitly, one can now put the `resizable` flag on a Layout.Top/Left/Bottom/Right, which makes building layouts even simpler, see demo.
The gutter logic was moved to the new implementation, since that was only used by the Sandy chrome anyway.
Changelog: Layout.Top / Left / Bottom / Right now support a resizable option
Reviewed By: passy
Differential Revision: D27233899
fbshipit-source-id: fbbdeb2ebf30d49d0837705a00ea86bb07fc2ba2
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:
This diff implements the remaining features in the logs plugin:
- deeplinking
- merging duplicate rows
The logs plugin source code has now been reduced from originally `935` to `285` LoC. All optimisation code has been removed from the plugin:
* debouncing data processing
* pre-rendering (and storing!) all rows
Finally applied some further styling tweaks and applied some renames to DataTable / DataSource + types finetuning. Some more will follow.
Fixed a emotion warning in unit tests which was pretty annoying.
Reviewed By: passy
Differential Revision: D26666190
fbshipit-source-id: e45e289b4422ebeb46cad927cfc0cfcc9566834f
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:
Beyond a search across all columns, it is now possible to specific columns for specific values:
* for a row to be visible, all active column filters need to be matched (e.g. both a filter on time and app has to be satisfied)
* if multiple values within a column are filtered for, these are -or-ed.
* if no value at all within a column is checked, even when they are defined, the column won't take part in filtering
* if there is a general search and column filters, a row has to satisfy both
Filters can be preconfigured, pre-configured filters cannot be removed.
Reseting will reset the filters back to their original
Move `useMemoize` to flipper-plugin
Merged the `ui/utils` and `utils` folder inside `flipper-plugin`
Reviewed By: nikoant
Differential Revision: D26450260
fbshipit-source-id: 11693d5d140cea03cad91c1e0f3438d7b129cf29
Summary:
Add support for resizable columns, column sorting, and hiding / showing columns
Moved some utilities from Flipper to flipper-plugin, such as Interactive and LowPassFilter
Split DataTable into two components; DataSourceRenderer which takes care of purely rendering the virtualization, and DataTable that has the Chrome around that, such as column headers, search bar, etc.
Reviewed By: nikoant
Differential Revision: D26321105
fbshipit-source-id: 32b8fc03b4fb97b3af52b23e273c3e5b8cbc4498
Summary:
First rudementary setup of DataTable component that follows a data source. Initially used react-virtuose library, but it performed really badly by doing expensive layout shifts and having troublesome scroll handling. Switched to react-virtual library, which is a bit more level, but much more efficient, and the source code is actually understandable :)
Features:
- hook up to window events of datasource
- high and low prio rendering, based on where the change is happening (should be optimized further)
- sticky scrolling support
- initial column configuration (custom rendering, styling, columns etc will follow in next diffs)
Reviewed By: nikoant
Differential Revision: D26175665
fbshipit-source-id: 224be13b1b32d35e7e01c1dc4198811e2af31102
Summary:
For context see https://fb.workplace.com/notes/470523670998369
This diff introduces the DataSource abstraction, that can store records. If a key is set a key -> record mapping is stored, to make it easy to update existing records using `upsert`, without knowing their exact index.
Internal storage will be slightly altered in upcoming diffs, so don't pay to much attention to that part.
Reviewed By: nikoant
Differential Revision: D25953337
fbshipit-source-id: 1c3b53a2fcf61abaf061946be4af21d2aecc6c6d
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: In the Flipper chrome there is a lot of `logger={logger}` prop drilling. Let's not do that anymore in the future by using a proper hook, which is exposed from `flipper-plugin`.
Reviewed By: passy
Differential Revision: D25421304
fbshipit-source-id: 01ec8563c67f7e2fac359c2f8216eba722bff8d9
Summary: Wired up tracking to all chrome sections and some import UI elements
Reviewed By: jknoxville
Differential Revision: D25219089
fbshipit-source-id: c75bed91894609dafc5fcc6423a5228211fb92d8
Summary:
This wires up tracking directly to the ANT component library for the following components:
1. `Button`
2. `Collapse.Panel`
3. `Tabs`
Other less commonly used elements can be connected in the future if needed.
I played a bit with different patterns, but in testing the patch-package patching give the most reliable results. Alternatives considered:
1. Expect users to explicitly wrap there components, e.g. `<Tracked><Button>Hi</Button></Tracked>`
1. Didn't implement this because it would be very common to forget, and at the moment you want to make some analysis you'll discover there is no interesting data available. I think for tracking we want to have opt-out rather than opt-in
2. The additional wrapping can cause some subtile layout issues due to static field inspection / forwarded refs (e.g. Ant often has an assumption that relevant children types are _directly_ nested under their parent element. For examle `<Tooltip><Tracked><Button>` does not work as expected
2. Expose our own `Button` / `Collapse` / `Tabs` that applies `Tracked` to an underlying Ant component.
1. also suffers from 1.b.
2. It is gonna be quite confusing for other devs that some elements would need to be imported from `flipper-plugin`, ant some from `antd`, and that this is likely to change over time. We could lint against it, but it will be still suboptimal
Reviewed By: jknoxville
Differential Revision: D25196321
fbshipit-source-id: b559356498c3191a283062a88daacb354b0f79f4
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: To control bundle size and the amount of different versions used, we want plugins to use emotion's styled and immer's produce from flipper-plugin, rather than bringing their own
Reviewed By: passy
Differential Revision: D25087286
fbshipit-source-id: d2cc8b2cb1a17c520d05d99048cd94338984a913
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 prefixes APIs of `flipper-plugin`, that are used by Flipper, but should not be used by plugins directly, with `_`. Also added tests to make sure we are always intentional when extending the exposed APIs
Reviewed By: passy
Differential Revision: D24991700
fbshipit-source-id: ed3700efa188fca7f5a14d5c68250598cf011e42
Summary:
This diff adds support for finding appPatterns (not sure how the feature is called) in the device, and auto completing on it.
Also improved the styling of bookmark sections.
This diff also adds support of showing a dialog in which params an be filled out if needed.
The behavior around optional arguments seems buggy, as in, no dialog will show up, but since I didn't want to change the logic around this unilaterally, left it as-is for now.
Updated the dialog to Ant so that the renderReactRoot utility could be used safely
Reviewed By: cekkaewnumchai
Differential Revision: D24889855
fbshipit-source-id: 6af264abec2e9e5b921ef7da6deb1d0021615e9e
Summary:
allow-large-files
This diff introces the `NUX` element that can be wrapped around any other element to give a first-time usage hint.
Hint dismissal is stored by taking a hash of the hint contents, and scoped per plugin.
Users can reset the 'read' status in the settings page
Example usage:
```
<NUX
title="Use bookmarks to directly navigate to a location in the app."
placement="right">
<Input addonAfter={<SettingOutlined />} defaultValue="mysite" />
</NUX>
```
Reviewed By: nikoant
Differential Revision: D24622276
fbshipit-source-id: 0265634f9ab50c32214b74f033f59482cd986f23
Summary: This blesses the `Layout` and `theme` components and exposes them from `flipper-plugin`, so that they can be used in (public) Sandy plugins. Also marked old abstractions as going to be deprecated.
Reviewed By: cekkaewnumchai
Differential Revision: D24503560
fbshipit-source-id: a8f384667b8f66e3b9f00771a123fe5c9d755eb3
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:
Some non-semantic changes. Mostly an earlier rename that was accidentally done only locally rather than across the codebase
Also support `.spec` test extension, which is more idiomatic Jest, since we don't use the `.node` and `.electron` distinction anymore anyway.
Reviewed By: jknoxville
Differential Revision: D22976438
fbshipit-source-id: f3abedb36cbac1e835295177117ccbca492a67a1
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:
This diff makes sure that devices will actually instantiate applicable sandy device plugins. Similar to how client plugins are owned by Client, device plugins are directly owned by BaseDevice, which significantly simplifies life cycle management and doesn't dispatch updates to all Redux connect components whenever something irrelevant changes.
Also made sure `device.teardown()` is called. That API already existed, but wasn't used or implemented before.
Updated Flipper test utils to support testing device plugins as well (both Sandy and classic ones)
Reviewed By: passy, nikoant
Differential Revision: D22693929
fbshipit-source-id: 73b2b8666ef7a0e748ea89360db84734d37eb5be
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
Summary: While testing manually discovered the sandy plugin infra din't cover the case that a plugin can be selected but not enabled at the same time. Added test and fixed that.
Reviewed By: nikoant
Differential Revision: D22308597
fbshipit-source-id: 6cef2b543013ee81cee449396d523dd9a657ad1c
Summary:
Introduced a minimal state abstraction so that state can be maintained in the plugin instance, but subscribe to by the UI.
At a later point we could pick an off the shelve solution like Recoil or MobX, or introduce cursors to read something deep etc etc, but for now that doesn't seem to be needed at all, and I think this will be pretty comprehensible for plugin authors (see also the 25th diff in this stack).
The api
```
createState(initialValue): Atom
Atom {
get() // returns current value
set(newValue) // sets a new value
update(draft => { }) // updates a complex value using Immer behind the scenes
}
// hook, subscribes to the updates of the Atom and always returns the current value
useValue(atom)
```
Reviewed By: nikoant
Differential Revision: D22306673
fbshipit-source-id: c49f5af85ae9929187e4d8a051311a07c1b88eb5
Summary:
`usePlugin(pluginFactory)` returns the current plugin instance's api that was exposed by the plugin directory.
Passing `pluginFactory` is technically strictly not needed, but having the user pass it, we can make sure it is strongly typed
Reviewed By: nikoant
Differential Revision: D22286293
fbshipit-source-id: 4268b6849b8cd3d524103de7eadbd6c0a65c7a61
Summary:
This sets up the initial infra that is to be used by plugin devs to test plugins.
There is not much yet to see, as there is no state or message sending yet. But at least the life cycle of plugins can be test, things are strongly typed and everything is in the place where it should be :)
N.b. the import difference with these utils and the createFlipperMock utilities in Flipper are
1. this testing infra is entirely inside flipper-plugin package, so that plugin devs don't need flipper as a dependency
2. this testing infra doesn't provide abstractions for plugin / device / client switching; it tests plugins purely in isolation of the rest of the world (except for firing `onConnect` / `onDisconnect` which is normally the effect of switching plugins)
Reviewed By: nikoant
Differential Revision: D22255262
fbshipit-source-id: b94ccbab720d2b49428a646aed3c55af71a5bc80
Summary: PluginContainer will now wrap Sandy plugins in PluginRenderer. PluginRenderer will also be used by plugin unit tests in the future
Reviewed By: jknoxville
Differential Revision: D22159359
fbshipit-source-id: 69f9c8f4bec9392022c1d7a14957f5aca0339d97
Summary: This diff introduces the `onDestroy` hook that can be used by plugins to listen to the event where a plugin is cleaned up (either because it is disabled, or because the client is being cleaned up)
Reviewed By: jknoxville
Differential Revision: D22208121
fbshipit-source-id: 9c4951ae671be611f21da171c548d4054c481166
Summary:
So far there were 2 types of plugins: `FlipperPlugin` and `FlipperDevicePlugin`. This introduces a third kind: `SandyPluginDefinition`.
Unlike with the old plugins, the export of the module is not directly exposed as the plugin definition. Rather, we use class `SandyPluginDefinition` (instance) that holds a loaded definition and its meta data separately (`PluginDetails`). This means that we don't have to mix in and mutate loaded definitions, and that for unit tests we can avoid needing to provide a bunch of meta data. This also prevents a bunch of meta data existing on two places: on the loaded classes as static fields, and in the meta data field of the loaded class as well. Finally, we can now freely extends the `PluginDetails` interface in flipper, without needing to store it on the loaded classes and we are sure that no naming conflicts are caused by this in the future.
For compatibility with the existing code base, common fields are delegated from the `SandyPluginDefinition` class to the meta data.
Also cleaned up types around plugins a little bit and removed some unnecessary casts.
For all features that reason about plugins in general (such as exports), sandy plugins are ignored for now.
`SandyPluginInstance` is worked out in further diffs
The `instanceof` calls are replaced by a utility function in later diffs.
{F241363645}
Reviewed By: jknoxville
Differential Revision: D22091432
fbshipit-source-id: 3aa6b12fda5925268913779f3c3c9e84494438f8
Summary: Set up an initial library which can (should) be used by plugins in the future.
Reviewed By: jknoxville
Differential Revision: D22019554
fbshipit-source-id: 502b14b34b2c9c117cea377ab6ebbf150e6faee9
