Summary:
In order to accomplish multi-panel mode, we need to use multiple data views on the same data source so that the filters can be applied differently, etc.
This diff serves to refactor DataTable and some of its associated classes to use DataView as the primary driver for data management. Additionally, the diff refactored the state to allow multi-paneling to be on the DataPanel layer instead of the DataTable layer for ease of usage
This is the last diff of the larger stack which introduces the multi-panel mode feature. A possible next step could be allowing infinite(up to a certain limit) panels to be populated.
Changelog: Introduced side by side view feature for `DataTable`. There is now a new boolean for `DataTable` props called `enableMultiPanels`. If this is passed in, then the table will have an option to open a different "side panel" using a completely different dataview which allows different filters, searches, etc.
Reviewed By: mweststrate
Differential Revision: D37685390
fbshipit-source-id: 51e35f59da1ceba07ba8d379066970b57ab1734e
Summary:
Sets a default key binding of `ctrl+l` to clear the screen within built-in Flipper plugins which display a log view.
Motivation: A small quality of life improvement for developers used to the default "clear screen" binding. This makes our log-rendering plugins consistent with other native apps such as terminals, Chrome DevTools, and many others.
Reviewed By: mweststrate
Differential Revision: D37782638
fbshipit-source-id: 0a85b930faaa0e9468d5391f15092aad7b6057ee
Summary:
Changelog: most data tables allow for horizontal scrolling now if they run out of space
This diff introduces support for horizontal scrolling in datatables. Originally thought about making this a view option, but doing automatically works actually quite fine. By default the columns resize as they did, but if either a column is made bigger or the window is so small no space is left, a horizontal scrollbar can be used.
This adresses several usability issues reported in GH / workplace
fixes https://github.com/facebook/flipper/issues/2608
Reviewed By: antonk52
Differential Revision: D33368216
fbshipit-source-id: 206c761a5873cf0396af091f2cbdedc3e638afac
Summary: `device.realDevice` was the escape hatch used in Sandy plugins to give access to device specific features like taking screenshots, clearing logs or accessing `adb`. Since in decapitated Flipper that won't be possible anymore (since plugins run in the client but device implementations on the server), all escape hatches have been bridged in this stack, and we can get of the `realDevice` interaction, by explicitly exposing those cases, which makes it type safe as well.
Reviewed By: passy
Differential Revision: D31079509
fbshipit-source-id: c9ec2e044d0dec0ccb1de287cf424907b198f818
Summary:
Changelog: Standardized DataList component
This diff standardizes the DataList component, by reusing the DataList. This is done to be able to take full advantage of all its features like virtualisation, keyboard support, datasource support, etc.
Also cleaned up DataTable properties a bit, by prefixing all flags with `enableXXX` and setting clear defaults
Reviewed By: passy
Differential Revision: D28119721
fbshipit-source-id: b7b241ea18d788bfa035389cc8c6ae7ea95ecadb
Summary:
Here I'm changing plugin repository structure to allow re-using of shared packages between both public and fb-internal plugins, and to ensure that public plugins has their own yarn.lock as this will be required to implement reproducible jobs checking plugin compatibility with released flipper versions.
Please note that there are a lot of moved files in this diff, make sure to click "Expand all" to see all that actually changed (there are not much of them actually).
New proposed structure for plugin packages:
```
- root
- node_modules - modules included into Flipper: flipper, flipper-plugin, react, antd, emotion
-- plugins
--- node_modules - modules used by both public and fb-internal plugins (shared libs will be linked here, see D27034936)
--- public
---- node_modules - modules used by public plugins
---- pluginA
----- node_modules - modules used by plugin A exclusively
---- pluginB
----- node_modules - modules used by plugin B exclusively
--- fb
---- node_modules - modules used by fb-internal plugins
---- pluginC
----- node_modules - modules used by plugin C exclusively
---- pluginD
----- node_modules - modules used by plugin D exclusively
```
I've moved all public plugins under dir "plugins/public" and excluded them from root yarn workspaces. Instead, they will have their own yarn workspaces config and yarn.lock and they will use flipper modules as peer dependencies.
Reviewed By: mweststrate
Differential Revision: D27034108
fbshipit-source-id: c2310e3c5bfe7526033f51b46c0ae40199fd7586