Summary:
Builds didn't fail when using non-existing icons, and the error message was not very clear
Also added verification that, before automatically adding an icon to the prefetcher, that icon does exists
Reviewed By: jknoxville
Differential Revision: D19264063
fbshipit-source-id: 4320d5b960e85e3f15bbca13d69f3063b983a511
Summary: Doctor sometimes can show false-positives and in such case there is no way to suppress showing warning message on each startup. To reduce annoyance I've added an option to save the problems already seen by user and show the Doctor warning only for new problems.
Reviewed By: mweststrate
Differential Revision: D19187095
fbshipit-source-id: 14c1fcc9674f47fbe0b5b0f2d5d1bceb47f7b45d
Summary: Collect run time stats on how much CPU plugins use
Reviewed By: nikoant
Differential Revision: D19161359
fbshipit-source-id: 96b020b1f23b5e8d2e602f0ff6c3aa80ea149792
Summary:
When browing through flipper one gets random warnings about uncached icons. Since we can't predict which plugins use which icons, it is hard to keep the list in `icons.js` updated.
This diff extracts the table to a separate json file (static/icons.json) and if an icon is missing in development, it will automatically add it to the list, so that the icons will be part of the prefetch of the next build / restart
Reviewed By: jknoxville
Differential Revision: D19257253
fbshipit-source-id: c9c791d50fa5d66738d93873289fbde575f32d66
Summary: Without selected device or client, it is currently impossible to submit a bug report. This diff fixes that.
Reviewed By: jknoxville
Differential Revision: D19251701
fbshipit-source-id: fd0dc0c779fb27d93ed02a404da76a7e6b251b94
Summary:
Since background plugins don't receive data anymore when not starred, we should hint the user about this.
For this diff, I reused the existing statusbar. Although this solution is quite ugly, I think it is better than introducing yet another notification / warning mechanism. Probably we should revisit the layout of this status bar in the future.
Reviewed By: jknoxville
Differential Revision: D19251588
fbshipit-source-id: 1dfd07be383d4ba318f344ebff4b08ed36194c58
Summary:
From several reviews / early feedbacks it was suggested several times to use the star mechanism to distinguish which plugins are allowed to send messages. This diff implements that:
- If a plugin is not selected, and not starred, it will drop the messages it received in the background
- This logic is still behind the same GK
- I think this change warrants upping the message queue limits significantly
- A future optimization would be to disable sending messages from the device side of things to reduce bridge usage, but that change is probably a lot more complicated with less impact
- In the next diff I'll make clear from UI perspective that unstarred plugins don't queue messages
In the attach video one can see how graphQL plugin keeps storing messages if it is starred, but if it isn't starred and not selected either, it will skip messages
{F225692819}
Reviewed By: jknoxville
Differential Revision: D19250928
fbshipit-source-id: 7e6af0eb6830dc79951cfd206e05b44061f1b14a
Summary: `flipperPrintPluginBackgroundStats()` tended to report the class name rather than the given plugin id
Reviewed By: jknoxville
Differential Revision: D19250706
fbshipit-source-id: 6035892bacf6a592d8c510320d5e003fac580ec7
Summary:
Because the recordSourceUpdates where stored in Map instances, they were never serialized when exporting the data to flipper. (JSON.stringify doesn't support Map's). Although Flipper's own serializer does support maps (which is what you get when not overriding these static methods), the Flipper serializer is really slow, which made the export unusable.
~~The reason this became a problem is that in the new message architecture plugin snapshots serialize the events and apply them only when the plugin is opened, rather than doing it immediately when they are received. However, to be able to apply the events, the recordSource should be available. Before this change, this would throw exceptions when viewing the plugin in an imported flipper trace, as this recordSourceUpdates aren't available anymore.~~
The events are processed *before* the export now, so this is no longer a deal breaker, but it is still an improvement, as it will make the data available in the Flipper exports / imports, and fixed the following error that would occur when opening the store page in an flipper import:
{F225365428}
Reviewed By: jonathoma
Differential Revision: D19178158
fbshipit-source-id: f2bc0a05b02dd2fbd1029d472beeb614dded2dd3
Summary: This diff makes sure that pending queues for plugins that are selected are processed before making a flipper export.
Reviewed By: jknoxville
Differential Revision: D19194211
fbshipit-source-id: e076375889450407e7f94384051719f3bbc415ee
Summary:
To avoid plugins to collect data forever and store it (if they are never opened), introduced a hard-coded default limit on how many events will be preserved.
A semantic change is that plugins have to be potentially resistant against missing events. So far, during testing, this didn't seem to cause any problems.
Reviewed By: jonathoma
Differential Revision: D19175912
fbshipit-source-id: 828be941e76b7356c9f5be7e5a49de9a7a31b0d2
Summary: This introduces the necessary UI changes, to kick off and render event progressing process where needed
Reviewed By: jknoxville
Differential Revision: D19175450
fbshipit-source-id: 61e3e8f59eeebf97eedbe715fa7db320286543e2
Summary:
This diff introduces the logic for queueing incoming messages rather then directly processing them you are behind the `flipper_event_queue` GK.
The reason the queue processing is a bit complicated is to make the queue can be processed non-blocking, can be cancelled, and is safe to concurrency issues.
The idea here is that the queue is processed when we switch to a plugin, report it's progress, and abort the process when switching to another plugin without loosing any work.
This diff does not include
[x] updates to the UI (**SO DON"T LAND IN ISOLATION**)
[x] metrics to see the effect
The effect of the changes can be seen when profiling the application, before this change there are very regular CPU spikes (see the small yellow bar on the top):
https://pxl.cl/TQtl
These go away when the events are no longer processed
https://pxl.cl/TQtp
Reviewed By: nikoant
Differential Revision: D19095564
fbshipit-source-id: 0b8c3421acc4a4f240bf2aab5c1743132f69aa6e
Summary:
## The dependency [deep-equal](https://github.com/inspect-js/node-deep-equal) was updated from `1.1.1` to `2.0.1`.
This version is **not covered** by your **current version range**.
If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.
---
**Publisher:** [ljharb](https://www.npmjs.com/~ljharb)
**License:** MIT
[Find out more about this release](https://github.com/inspect-js/node-deep-equal).
---
<details>
<summary>FAQ and help</summary>
There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html). If those don’t help, you can always [ask the humans behind Greenkeeper](https://github.com/greenkeeperio/greenkeeper/issues/new).
</details>
---
Your [Greenkeeper](https://greenkeeper.io) bot 🌴
Pull Request resolved: https://github.com/facebook/flipper/pull/706
Reviewed By: mweststrate
Differential Revision: D19141026
Pulled By: cekkaewnumchai
fbshipit-source-id: e89050bf9e83f072a03f79e9b7772269be6efb9d
Summary:
See explanation in parent diff, make sure the idler is used efficiently, instead of wasting a lot of CPU creating a new callstack every time `idle` is called.
Also fixed that cancelled idlers could result in an _uncaught_ exception
Reviewed By: nikoant
Differential Revision: D19158593
fbshipit-source-id: 0be505a74c374e0ca6ee0e79b1f1e98ac9b80467
Summary:
To test things that depend on `Idler`, we would so far need to depend on timing in the unit tests, which is very error prone. So introduced a `TestIdler` as well to make sure we can create an idler we can control remotely (as demonstrated in the unit test)
Note that idler smells like generator functions all over the place, so maybe I'll take a stab later to see if we can replace idlers with generators, which gives a much clearer control flow imho.
Reviewed By: nikoant
Differential Revision: D19158369
fbshipit-source-id: 605d120860ecb02883442524df6f876e050ff092
Summary: Previously it was not possible to run unit tests to test logic that requires GK's to be enabled. This fixes that
Reviewed By: passy
Differential Revision: D19158368
fbshipit-source-id: b89691bdd2f975a3b4be343bd966ed77b2ad3763
Summary: Fix various errors that Flipper was complaining about in Watch plugin
Reviewed By: ankursadhoo
Differential Revision: D19168777
fbshipit-source-id: eefb98818ddb0da78de1daf2d67045cb90cd90aa
Summary:
This diff will make it easier to test a plugin in a "fully loaded" Flipper state. This makes it possible to test all the wiring of flipper, rather than the individual reducers.
This is in preparation of processing the message queue async.
Reviewed By: passy
Differential Revision: D19140879
fbshipit-source-id: 5a333abe9c7a4d0c33d1d06a105cd094cb8fc19f
Summary:
Skip Android health-checks when the "Android Developer" option is disabled in Flipper settings.
Also made some refactoring to use immer for healthcheck reducer.
Reviewed By: mweststrate
Differential Revision: D19088322
fbshipit-source-id: 801d874b6e7e5af80802b4bf4313d98f1cee13f6
Summary: Added a setting "Match local fbsource chekout", which inverserly corresponds to the `ignore_local_pin` setting in `flipper-launcher.toml`.
Reviewed By: passy
Differential Revision: D19030456
fbshipit-source-id: deaaf4e873a00bbc4e8bd3034353cf580df95a36
Summary: Replacing this with promisify-child-process, which is better.
Reviewed By: mweststrate
Differential Revision: D18954702
fbshipit-source-id: 2dad756a2cd4dd21b2efc8b1780d589607d6ff05
Summary:
This diff is a refinement of D18780965, which fixed plugin preferences to be stored per device. Instead of storing plugin preferences globally, we now store them per app, so that every app can have their own favorites, which are shared regardless the device
Note that the current favorite selection will be lost.
Reviewed By: nikoant
Differential Revision: D19018169
fbshipit-source-id: acfa05ece8516840bb91aee4059886365b346582
Summary: There were a few warnings printed when starting Flipper. This fixes the last of them!
Reviewed By: nikoant
Differential Revision: D19011385
fbshipit-source-id: 15bc46c4a67e8c8fd3c8b5d96dc67e61911a7e53
Summary: React 16 is not compatible with react-emotion 9 (it prints warnings, see also https://github.com/emotion-js/emotion/issues/644). So we should upgrade to 10.
Reviewed By: mweststrate
Differential Revision: D18905889
fbshipit-source-id: c00d2dbbadb1c08544632cb9bfcd63f2b1818a25
Summary: It fixes the bug, where currently we show all active persistent plugins for the export functionality irrespective of the fact that the plugin is active for the selected client. With this diff we will only show active persistent plugins for the selected client.
Reviewed By: mweststrate
Differential Revision: D18890247
fbshipit-source-id: e567da0ccf04e051ca0eabb497a6bd72cc8a0d76
Summary:
This Pull request makes it possible to automatically generate regression tests for plugins. The idea here is to record all incoming states for a specific plugin, the start state of the plugin, and the enstate of the plugin.
By replaying the same events in a test, the same plugin should result in the same end state. This will make it easy to test regressions and refactorings on real life scenarios. Execution time is recorded as well.
The API's are exposed as
- `flipperStartPluginRecording()`
- `flipperStopPluginRecording()`
This process generates both a data snapshot and unit test.
Reviewed By: passy
Differential Revision: D18907455
fbshipit-source-id: 923f814f534ccfa6aa2ff2bfa2f80bee41a1c182
Summary: Before looking into performance bottlenecks, I thought it wise to upgrade to TypeScript as that is where all plugins are heading
Reviewed By: jknoxville
Differential Revision: D18829689
fbshipit-source-id: 4c515f240d742f77e89f3cbdff500c69afb3ac06
Summary: I noticed a bug where the export data perf events were not logged. The issue was that, it used the `Logger.getTrackTimeSince` method which used the `performance` from `perf-hooks` and not an ordinary performance object available in the global scope. So just importing performance from perf-hooks solved the issue.
Reviewed By: mweststrate
Differential Revision: D18887666
fbshipit-source-id: 66c24f47b95b25d2f3703c16c70cbe8b35fe0ec3
Summary:
Quite a bit of complex slicing going on there, so I think
this is quite useful to guard against future breakages.
Reviewed By: jknoxville
Differential Revision: D18853033
fbshipit-source-id: 36b17b8ce208cb320a193bceed86c89e010107e4
Summary: This had been there for way too long.
Reviewed By: mweststrate
Differential Revision: D18834089
fbshipit-source-id: 563aa04876910a7544a7f62865b146b933dbf570
Summary: I **think** this is the last part of the codebase doing manipulation of strings to produce plugin keys etc.
Reviewed By: passy
Differential Revision: D18831990
fbshipit-source-id: db449d78230adbca66e78f041381a34d9b249a45
Summary: This diff makes it possible to gather stats of plugin usage, and print them from the console by issuing `window.flipperPrintPluginBackgroundStats()`.
Reviewed By: jknoxville
Differential Revision: D18811590
fbshipit-source-id: 4219923f7fd90187c7ec50a9aa68d7b817e3db8f
Summary:
Ok this diff got a bit bigger than expected, but I think it makes it easier to understand what "plugin keys" are, and makes them less prone to error.
Previously pluginKeys were composed of: clientId#pluginName, where clientId was itself: app#os#device#device_id
But also, there were some plugin keys where the clientId was a device_id.
Now you deconstruct a plugin key, and will get a tagged object with type: 'device' or 'client', and the properties that they each have.
There is now no custom parsing of these afaik, let's keep it that way.
Since it took me a while to figure out what all these IDs are, I've documented it a bit in clientUtils.
Reviewed By: passy
Differential Revision: D18811848
fbshipit-source-id: eed2e2b5eedafb9e27900dbcf79a389fcaffae95
