Summary:
Original commit changeset: 1d0e6ce17c89
Backing this out until we can come up with a better way to do it.
The change was introduced so that when a device disconnects / crashes, we don't lose all plugin state, and you can still see what was on screen before the crash..
However, there are some problems with this solution, which get quite complicated. Putting them here for future reference:
* Closing an app results in the plugins staying there, and there's no way to tell it's not actually connected.
* If the app reconnects, the JS plugin doesn't get re-initialized. Even though the client plugin has been.
Reviewed By: bnelo12
Differential Revision: D16280932
fbshipit-source-id: 92585cdd0dace2012924df4106327a1e21ab9f9b
Summary:
Non-final identifiers make code harder to understand.
This is particularly true for JavaScript where even the *type*
can change as a value gets reassigned later.
This enforces to use `const` whereever possible, but doesn't
"outlaw" `let`. Mixed destructuring is also still allowed.
Used `eslint --fix` to change all existing cases.
Reviewed By: jknoxville
Differential Revision: D16131329
fbshipit-source-id: 2eceaca7c603b71b36e005be5d135e1849f2518d
Summary:
We are using `redux-persist` to persist parts of our redux store over reloads. In this library, there is a check if a value "was removed to the store". However, they are doing this check by checking if the value of this key is `undefined`. This is not a good way of checking if a property exists on an object, because it can exists but explicitly be set to `undefined`. This was the case for `connections.selectedDevice`, we were setting the value to undefined, once the device disconnected. This caused the key to be persisted, eventhough it wasn't whitelisted for persisting.
In this diff, we are setting the `selectedDevice` to `null` instead of `undefined` once a device disconnects.
Reviewed By: passy
Differential Revision: D16121260
fbshipit-source-id: f32c8ea9e30f02e065fa63380ae0245379a47496
Summary:
When an archived device reconnected, the clients from the architved device weren't removed and a new client was added. This caused a client to be shown multiple times after reconnecting a device.
In this diff, all clients and pluginStates from an archived device are removed once the device reconnects.
Reviewed By: passy
Differential Revision: D16075349
fbshipit-source-id: 1d0e6ce17c89bb75dd993466bca6bd64e2c63338
Summary:
Bug Summary:
When running Flipper on Mac, the Mac device is always first to register with Flipper and thus is always selected as the default connected device when first launching. This blocks the beautiful tutorial screen from appearing for new users.
Fix:
When registering new devices in the redux store, a new check has been added that maintains a blacklist of devices that cannot be selected as default. I have added Mac to start. At the same time, this fix preserves userPreferredDevices so that if the user has selected Mac as a device in the past, then next time Flipper is opened, even blacklisted devices will be displayed.
Making this fix uncovered a race condition, between the redux state being rehydrated and the devices being registered. I have potentially fixed this via a callback function in persistStore.
Reviewed By: passy
Differential Revision: D16048371
fbshipit-source-id: 79580b30e8a3b077dac1ac15131266e59646253f
Summary: Currently, you get an error when you don't have device utils installed. However, when you switch your flipper to a supported device, the error may not be cleared. This handles that case.
Reviewed By: jknoxville
Differential Revision: D15087620
fbshipit-source-id: 6060752b54161c7610656531d053ecbcdd9e978a
Summary: The error was getting wiped accidentally if register device didn't have any error. In practice, meaning that the "flipper already running" message only flickered on the screen and then disappeared.
Reviewed By: passy
Differential Revision: D14576768
fbshipit-source-id: 1c7443f8f25ffa6a56f8d4994f3fef53bbb02c6d
Summary:
This was originally introduced so we could squash multiple instances of the same error at the client side and only report one instance of them.
Now we've moved to doing the aggregation server side, which is more powerful, so this is no longer necessary. We've also seen a case of these Error objects appearing opaque making it hard to see the underlying problem, so removing it entirely.
Reviewed By: passy
Differential Revision: D14576715
fbshipit-source-id: b285dcb5249e209f9008a14ac6a2f226f3aa82d7
Summary: Should also fix the build.
Reviewed By: jknoxville
Differential Revision: D14477777
fbshipit-source-id: 01fcfb2321c9b7a12acdf079473d91b6805d4dda
Summary:
Currently when a client connects, if there's no matching device we know of, it emits an error.
The problem is that there's a race between clients connecting and devices being detected, if the client connects first, then we'll emit this error, even though the device is displayed shortly afterwards.
Fixing this by waiting 2 seconds after a client connects, and then if it's still connected, checking for a matching device. This should be enough time to make this error more reliable.
Reviewed By: passy
Differential Revision: D14126315
fbshipit-source-id: c81b2c6d9a6e0639a656d1a4d7a8f999f715bfbf
Summary:
We were using `window.performance` to measure performance. This was because the equivalent node.js API `perf_hooks` wasn't available in the electron version we were using back then.
However, `perf_hooks` has landed in electron meanwhile, so I am moving to this API, as it works for the headless version and jest tests, too.
This allows us to delete the babel transform that was used for node-based tests, where the browser API was replaced with the node API
Reviewed By: jknoxville
Differential Revision: D13860133
fbshipit-source-id: cf1395004fac046dd55751ff465af494173b2cbf
Summary:
This diff adds the capability to export the flipper data to a file. With this diff you can click on the "Export Flipper" option from the "Edit" menu in menubar. It will export it in the file at this location
`~/.flipper/MessageLogs.json`
We do not exactly export the store, but just the important part of it. We export in the following format
```
{
fileVersion: '1.0',
device: {
os: 'iOS',
title: 'iPhone 7',
serial: '',
deviceType: 'physical',
},
clients: [
{
query: {
app: 'Facebook',
},
d: '12345678'
},
{
query: {
app: 'Instagram',
},
id: '12345678'
}
],
store: {
pluginState: {},
notifications: {}
}
}
```
In next diff I will add the capability to select the folder to export the file too.
Reviewed By: danielbuechele
Differential Revision: D13751963
fbshipit-source-id: 7d3d49c6adf8145b2181d2332c7dbd589155cec3
Summary:
Now flipper will include iOS devices in the dropdown, but you'll also get a message saying they aren't yet supported.
Also doesn't start up the PortForwardingMacApp instances in this case, because it's pointless.
Reviewed By: priteshrnandgaonkar
Differential Revision: D13319990
fbshipit-source-id: 75d72c6ed2478c7b999c5f43b764f097141b33de
Summary:
At the moment, when a client is failing to connect, you effectively get an infinite spinner, as it keeps retrying.
This keeps the spinner while it's retrying, but in between, shows a failure icon.
This isn't perfect. It's still shown under possibly the wrong device, but that already happens anyway, this just adds an extra icon.
Pull Request resolved: https://github.com/facebook/flipper/pull/339
Reviewed By: priteshrnandgaonkar
Differential Revision: D13319635
Pulled By: jknoxville
fbshipit-source-id: e16177ecc7058b779fb17b61e20fcbac8ccf0c29
Summary: Adds support for physical iOS devices, when the necessary dependencies are present. Unfortunately these aren't open sourced yet so the open source build won't get this feature yet.
Reviewed By: priteshrnandgaonkar
Differential Revision: D13001473
fbshipit-source-id: d8c2bcd53b7972bec676717c8af0112800b918d0
Summary:
We've seen this happen sometimes, e.g. when adb fails and we aren't showing any android devices, but the sdk still manages to connect.
When we detect this, log an error so we can track how often it occurs.
Reviewed By: passy
Differential Revision: D13175639
fbshipit-source-id: b0f79b77ac04ad804e56448b3696a3ffeb30631e
Summary: Stops them from jumping around if they try to connect more than once.
Reviewed By: passy
Differential Revision: D13084056
fbshipit-source-id: 803538298c45b9c28e5116f072518e8632b0f1cf
Summary: Puts the connection state into redux so we have more visibility on what's happening in bug reports and in general allowing us to display it on screen.
Reviewed By: passy
Differential Revision: D13060455
fbshipit-source-id: c79b4b7d6a1155d86128a5d8d1174ead9e4514ae
Summary:
Allow linking from one plugin to another. Adds a prop `selectPlugin` to the plugin that can be passed a pluginID and an optional `deepLinkPayload`.
The return value tells you if switching the plugin was successful.
```
selectPlugin: (pluginID: string, deepLinkPayload: ?string) => boolean,
```
Reviewed By: passy
Differential Revision: D10483925
fbshipit-source-id: 6f821277150b2db185b7d545c310214a11432eac
Summary:
- Set userPrefferedPlugin for external deeplink
- Listen for deeplink in renderer process and navigate accordingly
Reviewed By: passy
Differential Revision: D10339035
fbshipit-source-id: 4de6249a0672f9ce02b0dfb78a4563302c308578
Summary: When relaunching Flipper/refreshing it while developing, where was a case, where the App Client connected, before the device was registered in Flipper. In this case, we didn't select the previously selected plugin
Reviewed By: jknoxville
Differential Revision: D9359779
fbshipit-source-id: 9c6f8e6bf65a46dc84c9781242b23df0ed539810
Summary: Track the time from when the plugin is selected until its `init()` function finishes.
Reviewed By: passy
Differential Revision: D9239750
fbshipit-source-id: 569f236c9d58f70548f1ba6bf31a96047dcc8245
Summary:
Deselect plugin when app disconnects, but store the information that the users had the app selected. When the app conencts again, restore the user's selection.
This also stores the device seleced by the user and reselects the device if it connects.
Reviewed By: xiphirx
Differential Revision: D8833948
fbshipit-source-id: ad3ef54681550ae674bdd4e695d677aea5c14588
Summary: The redux store keeps a list of devices. For the active device, it stored the index in that list. This diff now stores a reference to the active device instead of the index in that array. This changes makes it easier to get the reference to the active device in a component.
Reviewed By: jknoxville
Differential Revision: D8767514
fbshipit-source-id: c740cf98d6039223ce8d5a47bcd277989fe70bc3
Summary:
Refactors the plugin architecture of Sonar:
- Before plugin rendering had it's own implementation of the react lifecycle. This means the `render`-function was not called by react, but rather by the application it self. In this diff, the render method is now called from react, which enables better debugging and allows react to do optimizations.
- Business logic for querying emulators is moved away from the view components into its own dispatcher
- All plugin handling is moved from `App.js` to `PluginContainer`.
- The sidebar only shows one selected device. This allows us to add the screenshot feature as part of the Sonar main app and not a plugin.
- This also fixes the inconsistency between the devices button and the sidebar
Reviewed By: jknoxville
Differential Revision: D8186933
fbshipit-source-id: 46404443025bcf18d6eeba0679e098d5440822d5
