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: After the change D19216026 was landed Travis build is failing, because now Flipper requires watchman to operate. To fix this I added a step to install watchman before running Flipper build there.
Reviewed By: jknoxville
Differential Revision: D19262195
fbshipit-source-id: c68327a177e10e07c97a0a4e383c9cead1c5706a
Summary:
On Windows VM when "yarn start" is executed and compilation is in progress for some plugin, fs.watch randomly fires "changed" events for different files of other plugins. This leads to infinite attempts to rebuild the same plugin again and again, and this process never ends, so "yarn start" is almost unusable:
{F225467225}
I've tried to fix this by using watchman instead of fs.watch and on my tests with Windows build it works well:
{F225467508}
Also as watchman is more careful about opening file handles, hopefully this change will fix "too many files opened" problem as Michel suggested here https://fb.workplace.com/groups/flippersupport/permalink/764157990731528/ and here https://github.com/facebook/flipper/issues/699.
Reviewed By: mweststrate
Differential Revision: D19216026
fbshipit-source-id: acc53ae0d003a7936730e6423ac4dbca84f089c8
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:
## 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/705
Reviewed By: mweststrate
Differential Revision: D19141027
Pulled By: cekkaewnumchai
fbshipit-source-id: 2378cac6cd470af36c0995644f31459a885fa6a9
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:
While trying to find a simple fix for the broken source maps when unit testing (see previous diff), I noticed that control flow in the transformer was unnecessarily complicated.
This doesn't fix the sourcemap issue btw
Reviewed By: passy
Differential Revision: D19158367
fbshipit-source-id: 7dfe4b28eabd4534a32dcb655e534d0f418f0db4
Summary: Fix various errors that Flipper was complaining about in Watch plugin
Reviewed By: ankursadhoo
Differential Revision: D19168777
fbshipit-source-id: eefb98818ddb0da78de1daf2d67045cb90cd90aa
Summary:
## The devDependency [flow-bin](https://github.com/flowtype/flow-bin) was updated from `0.113.0` to `0.114.0`.
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:** [mroch](https://www.npmjs.com/~mroch)
**License:** MIT
[Find out more about this release](https://github.com/flowtype/flow-bin).
---
<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/700
Reviewed By: mweststrate
Differential Revision: D19087103
Pulled By: passy
fbshipit-source-id: 1e9c22a5a7b8e991b68596256900bfa69f974ee3
Summary:
I believe we set this to a specific version because of an earlier security
warning from GitHub, but that's no longer needed and just creates
Greenkeeper spam.
Reviewed By: nikoant
Differential Revision: D19088846
fbshipit-source-id: f2c886f296d2ba87c40c3605633aeb73b262ca59
Summary: Rolling back workaround for Android SDK detection as it breaks detection with Java 8 while fixing Java 9+
Reviewed By: cekkaewnumchai
Differential Revision: D19146945
fbshipit-source-id: 2bea318d5f5cfafdf213d2ec73e837f6e86c9f33
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: Workaround for Anrdoid SDK detection not working with Java 9+ installed
Reviewed By: mweststrate
Differential Revision: D19094906
fbshipit-source-id: a7c8c9c8403d25ecc9b2d95113718ddf1821a349
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: New release built against Litho 0.33.
Reviewed By: priteshrnandgaonkar
Differential Revision: D19030537
fbshipit-source-id: a14b04decf3023e9ee78ef2a894061d8b04d232e
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: It's not much, but at least more than nothing :)
Reviewed By: nikoant
Differential Revision: D18930725
fbshipit-source-id: b1e5fa203b0020de7b5f16d040808cbb247b8dd4
Summary:
This is a preparation diff to address performance issues in the GraphQL plugin, by making sure we can detect functional regressions and measure performance changes.
For reference, current performance impact: `Reducer took 6338ms. to process 42 events` on my machine with this data snapshot (~10sec of recorinding graphQL events on FB4a)
See D18907455 for some background.
Reviewed By: passy
Differential Revision: D18930652
fbshipit-source-id: 58c832f21ae60954bbd7a60c088479aef29ab874
Summary: Fixed doctor module resolution on github by adding doctor src folder into the metro bundler blacklist
Reviewed By: cekkaewnumchai, mweststrate
Differential Revision: D19020038
fbshipit-source-id: a6ab95383b5016fd5e2180d72883a42c63745ec9
Summary: Fix module resolution for flipper-doctor and return it to sonar directory and effectively to GitHub
Reviewed By: mweststrate
Differential Revision: D18963720
fbshipit-source-id: 61ea78ecbb154de79c7a2d348f347c64325e794c
Summary: colriot put out a new release last night.
Reviewed By: cekkaewnumchai
Differential Revision: D18953863
fbshipit-source-id: 32c4fe6a4aa66bb98606a78927e46b55e2196e33
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
