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:
See previous diff.
Achieves the same optimization as in the mentioned diff, but this time by only debouncing the messages as they arrive over the socket, and not the state updates caused by Redux directly. This means that plugin rendering won't be debounced anymore until we address this more fundamentally.
With this change there is a double level buffering:
1. A buffer that stores all incoming messages (that are not replies to requests)
2. A buffer that stores messages we are interested in in the plugin queue, unless the plugin is active (this we already had).
This still fixes the issue that too chatty plugins cause to many updates foreground plugin (the problem we tried to fix originally), without debouncing plugin rendering if it is needed to update for any other reason.
Another nice benefit is that previously every received message would trigger a store update in Redux which would cause all connected components to evaluate their subscriptions (and then bail out in the typical case). Now we will only update the redux store every 200 ms.
Changelog: Foreground plugins will burn less CPU when they're very chatty
Reviewed By: jknoxville
Differential Revision: D21858849
fbshipit-source-id: c72352e569a8a803bbedffb71b17b11fcefee043
Summary:
This diff fixes an issue where we don't want to have the Navigation plugin be disabled as background plugins like all other plugins, so that the breadcrumb navigation keeps working.
Yet another hack concerning the super useful Navigation plugin. On a positive note, since connection management for background is not entirely managed by the Desktop and not the native said, these kind of exceptions are fairly easy to make :)
Reviewed By: passy
Differential Revision: D21089537
fbshipit-source-id: 209954ff35c95e066fe688a60ad46ccfc3835c44
Summary:
Background for this diff: https://fb.quip.com/KqEfAlKYlgme
Some plugins don't respect that stuff (livefeed and graphql), but for others it seems to work fine.
This is just a PoC, there are some present bugs concerning the combination of selecting and bg plugins
Questions to investigate:
- [x] make sure that LiveFeed and GraphQL disconnect properly. There might be more plugins that need that
- [x] verifiy that we don't loose one of the original goals of background plugins, e.g. QPL collecting and sending data from device start. Does this still work as intended after this change?
- [x] how can we observe / measure improvements? Are dev builds more responsive after this? Is the layout inspector smoother for example because no QPL plugins are interweaved?
- [x] how is forward and backward compatibility?
- If Flipper is updated, but device not: No change I think, as getBackgroundPlugins() will return an empty set, and background plugins are initiated as usual, so old behavior
- If device is updated, but Flipper not, background plugins won't be started until they are selected. This is a degradation, but hopefully explainable.
- [x] Verify QPL buffer is not unbounded
- [x] Share architecutre changes with team
For Graphql updates: D20943455
Added runtime stats to monitor network traffic (sadly had to redo that since scuba couldn't handle the data format used at first, so probably will hold of landing this diff a week to make sure we can see some effects)
Follow up work:
[x] wait until we released the stat tracking before we release this, to be able to measure the effect?
[x] make sure graphql fix lands
[ ] use side effects abstraction
[ ] fix other background plugins (android only) or fix it in a generic way:
{F234394286}
Changelog: Background plugins will no longer receive a Flipper connection if they are disabled. This should significantly reduce the overall load of Flipper both on the device and desktop when unused plugins are disabled used, which could otherwise generate 10MB/s of network traffic certain scenarios. All plugins *should* be able to handle to this gracefully, but since this is quite a fundamental change, reach out to the Flipper team when in doubt!
Reviewed By: jknoxville
Differential Revision: D20942453
fbshipit-source-id: b699199cb95c1b3e4c36e026b6dfaee7d1652e1f
Summary: I think it is good to have error handlers where-ever possible, so that there is historical data in our monitoring when we need it, and can track from which point of the code it originates :)
Reviewed By: jknoxville
Differential Revision: D21040059
fbshipit-source-id: 1c07fbfa65379739554bc98f83761ae97870ba82
Summary:
Measure how many byte we receive per plugin, and add this to the plugin stats that are collected
Will add a graph to the flipper dashboard, and probably a small visualization in a next diff as well.
Reviewed By: priteshrnandgaonkar
Differential Revision: D20917583
fbshipit-source-id: bb341531ecf8492080af82c56e73c0ec608f7b36
Summary:
Before we dropped all messages if the client connected before the device has been registered. Which happens typically on iOS (it can actually take very long, will investigate that as well, but not in this diff).
However, we don't need to wait for the device to process messages, we just need its serial, which we already know (given that we use that query id to find the matching device in the first place).
I think this will greatly improved perceived stability for iOS
Reviewed By: jknoxville
Differential Revision: D20734892
fbshipit-source-id: f98e8d31558ef606b9a8287e03fc41ab6c3a087d
Summary: See previous two diffs, this applies the abstraction to our code base
Reviewed By: passy
Differential Revision: D20679687
fbshipit-source-id: 05e340dca3f832971783a844a78d1ffd553ff9d2
Summary:
Quick notes:
- This looks worse than it is. It adds mandatory parentheses to single argument lambdas. Lots of outrage on Twitter about it, personally I'm {emoji:1f937_200d_2642} about it.
- Space before function, e.g. `a = function ()` is now enforced. I like this because both were fine before.
- I added `eslint-config-prettier` to the config because otherwise a ton of rules conflict with eslint itself.
Close https://github.com/facebook/flipper/pull/915
Reviewed By: jknoxville
Differential Revision: D20594929
fbshipit-source-id: ca1c65376b90e009550dd6d1f4e0831d32cbff03
Summary:
Our usage of requestIdleCallback (probably) causes more trouble than it solves:
1. It makes sure everything is processed asynchronously. But since everything is arriving over a network stack, that is already the case without wrapping it again to run on a separate event loop tick
2. The timeout we set before `500` forces the app to give _more_ priority to message processing instead of less
3. In a next diff (D20151700) in this stack we will make sure that messages are not processed immediately, but simple stored, which should not be significantly more expensive (probably even cheaper) than scheduling another tick on the event loop
Reviewed By: jknoxville
Differential Revision: D20557104
fbshipit-source-id: 6cc10ba537e3cb5f31e6c32e1fdeb57c20f06f17
Summary: Did run for 2 months stable now, time to remove some dead code.
Reviewed By: passy
Differential Revision: D20556785
fbshipit-source-id: 514673995212d62d21744f304286caa6e91007fb
Summary:
1) moved "sonar/desktop/src" to "sonar/desktop/app/src", so "app" is now a separate package containing the core Flipper app code
2) Configured yarn workspaces with the root in "sonar/desktop": app, static, pkg, doctor, headless-tests. Plugins are not included for now, I plan to do this later.
Reviewed By: jknoxville
Differential Revision: D20535782
fbshipit-source-id: 600b2301960f37c7d72166e0d04eba462bec9fc1
