Summary:
Add support for secondary indices, to allow for cheap lookups, like a set of events for a specific UI element in the events table:
```
#### getAllRecordsByIndex
Usage: `getAllRecordsByIndex({ indexedAttribute: value, indexAttribute2: value2, .... })`
This method allows fast lookups for objects that match specific attributes exactly.
Returns all items matching the specified index query.
Note that the results are unordered, unless
records have not been updated using upsert / update, in that case
insertion order is maintained.
If no index has been specified for this exact keyset in the indexQuery (see options.indices), this method will throw.
Example:
```
```
const ds = createDataSource([eatCookie, drinkCoffee, submitBug], {
key: 'id',
indices: [
['title']
['id', 'title'],
['title', 'done'],
],
});
// Find first element with title === cookie (or undefined)
const todo = ds.getFirstRecordByIndex({
title: 'cookie',
})
// Find all elements where title === cookie, and done === false
const todos = ds.getAllRecordsByIndex({
title: 'cookie',
done: false,
})
```
Reviewed By: antonk52
Differential Revision: D47396435
fbshipit-source-id: 20c4527be83532863b9b07ab20ebf20a80c3c35d
Summary:
flipper-server-companion depends on flipper-plugin. flipper-plugin includes dependencies that run only in a browser. Splitting flipper-plugin into core and browser packages helps to avoid including browser-only dependencies into flipper-server bundle.
As a result, bundle size could be cut in half. Subsequently, RSS usage drops as there is twice as less code to process for V8.
Note: it currently breaks external flipper-data-source package. It will be restored in subsequent diffs
Reviewed By: lblasa
Differential Revision: D38658285
fbshipit-source-id: 751b11fa9f3a2d938ce166687b8310ba8b059dee
Summary: Since there were large refactoring's done to `DataSource` during the milestone for side-by-side panels, wanted to update some of the documentation as well so that the information is accurate and up to date.
Reviewed By: mweststrate
Differential Revision: D38541404
fbshipit-source-id: a6ba472f881fb8cbfa90ff5ac295a0b87c595080
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:
Currently, we call onSelect in DataTable only when user changes their selection. At that moment, we pass the row data to the `onSelect` callback. However, if later the data changes, but the selection stays the same, we do not call `onSelect` again. As result, any listener to onSelect does not receive the latest data.
In this diff, we start calling `onSelect` when the selection does not change, but the underlying data does.
Reviewed By: mweststrate
Differential Revision: D37520346
fbshipit-source-id: a88d34654e9ad0721caf5918dde49b86ba20fc1f
Summary:
During filter changes, DataTable would loose any selections made, which was posted multiple times as papercut
I didn't implement preserving multi line selections. That should be straightforward, but wasn't sure that'd be desirable or not.
Changelog: DataTable: Data tables will now preserve the current selection and scroll it into view when changing the search filter.
Reviewed By: aigoncharov
Differential Revision: D36736496
fbshipit-source-id: 401ef351c847f58a5d411cf9f352390f6a110b24
Summary:
As reported in https://fb.workplace.com/groups/flippersupport/permalink/1346149929198995/, data updates would sometimes not render in DataTable. After some debugging, this happens when multiple updates are scheduled with high frequency, and is bug in the internal render scheduler. (it might be that this never triggered before React 18, but it was a lingering bug).
Basically in the following sequence, no second render of the data table would happen:
1. emit update
2. schedule render
3. React renders
4. emit a second update
5. scheduler bails out because update is already scheduled
6. React useEffect will clear out the scheduler state that was causing the render at point 3.
Now the second update never gets rendered out (well, not until something else causes a new render).
The problem here is that the scheduler state should be immediately reset as soon as React starts rendering, so that any new incoming update should trigger a new render, even though useEffect of the first render didn't finish. New flow now becomes:
1. emit update
2. schedule render
3. React renders & clears out scheduler state
4. emit a second update
5. scheduler schedules fresh render
6. etc...
Reviewed By: nikoant
Differential Revision: D35501325
fbshipit-source-id: 8af58c0da7bb024f360b750c856865f220dc6272
Summary:
This diff adds `types` fields on the compiler config for every project. This way we can make sure that for example node types and packages are not available in flipper-ui-core. Without an explicit types field, all types would be shared between all packages, and implicitly included into the compilation of everything. For the same reason `types/index.d.ts` has been removed, we want to be intentional on which types are being used in which package.
This diff does most of the work, the next diff will fine tune the globals, and do some further cleanup.
As an alternative solution I first tried a `nohoist: **/node_modules/types/**` and make sure every package list explicitly the types used in package json, which works but is much more error prone, as for example two different react types versions in two packages will cause the most unreadable compiler error due to the types not being shared and not literally the same.
Reviewed By: lawrencelomax
Differential Revision: D33124441
fbshipit-source-id: c2b9d768f845ac28005d8331ef5fa1066c7e4cd7
Summary: Current implementation uses type `string` as a key for indexing items stored in datasource. However, users can provide any key as an index which means that the type of index item can be anything, not only string. This diff introduces a more refined types for the key. It adds another requirement to provide a key property to a generic which is used to infer the index type.
Reviewed By: mweststrate, aigoncharov
Differential Revision: D31895751
fbshipit-source-id: 19ba907bd6f35df87e3fa442db5fc5cec6af174d
Summary: We're currently getting errors for every duplicate key and can't easily unify them, so we're adding the additional information to a warning instead.
Reviewed By: mweststrate
Differential Revision: D30337821
fbshipit-source-id: db9dc44d7d3424de169bed9b4447b482e411eb19
Summary:
I don't think this should make a difference in our size. Will see
in the size check.
This makes it quite hard right now to read errors that involve the data-source
package because terser runs over it.
Reviewed By: nikoant
Differential Revision: D29228941
fbshipit-source-id: 8cc79e4148be0e8ced9186323967bc79ba781c0b
Summary: some type simplifications, that makes it easier to reuse data sources and helps type inference
Reviewed By: passy
Differential Revision: D28413380
fbshipit-source-id: 261a8b981bf18a00edc3075926bd668322e1c37d
Summary:
Added demo to show how DataSource can power charts using event sampling and smart windowing.
A more experimental application: use dataSource to power some charts, that leverages the events emitted from an datasource that is continuously being appended:
- incoming events are downsampled 1 in 100 to build up the bottom window
- incoming events are not downsampled to render the topwindow, but since datasource views will ignore events outside the window, things will stay pretty responsive when a window is selected (without a window, the downsampled dataset is used as source for top chart as well).
Compared to a naive (well still slightly optimised with useFastArray) implementation that throws all incoming event in a big array, it performs > 20 times faster (see difference in amount of events processed)
Reviewed By: passy
Differential Revision: D28474409
fbshipit-source-id: 6a7973d1ade3053b1d6c8f72069697d96b1ef4fd
Summary:
Changelog: [Logs] Fix regression causing the scrollbars to be hidden. This diff fixes a regression where the Logs plugin was no longer scrollable (and scrolls indefinitely, killing perf).
As reported in https://fb.workplace.com/groups/flippersupport/permalink/1133775743769749/
The cause of the problem is the swap between the `PluginContainer` and `outOfContentsContainer`.
The deeper root that caused in the first place, is that containers use a `flex: 1` layout, which gets interpreted as `flex: 1 1 0%` (grow, shrink, 0% by default), where it was always inteded to be `flex: 1 1 0` (grow, shrink, by default zero pixels). In practice that difference usually doesn't matter. But sometimes it does... See https://stackoverflow.com/a/42630660/1983583
My whole life has been a lie up to this point.
Will trigger a new release after landing this.
Reviewed By: nikoant
Differential Revision: D28422966
fbshipit-source-id: 3ebd5f8ae76e032c5d698154b021df8ebef2c757
Summary:
Added a microbundle based build setup to the data-source folder to be able to package just that folder.
For simplicity / iteration speed, this is only used to publish externally. Our own code still references the source files directly.
More strict separation can be done later if there is external adoption.
Reviewed By: nikoant
Differential Revision: D28056699
fbshipit-source-id: a011b615cfffeff8ecb879bd7281a71085cea965
Summary:
To make the DataSource abstraction reusable for other teams and an upcoming talk, this diff moves all DataSource storage & virtualization logic in one folder.
Will set up a build process and demo project in later diffs.
Reviewed By: nikoant
Differential Revision: D28056700
fbshipit-source-id: 7cfe5b40bbbe387da711f765a604a45029d451c7
