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:
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:
Unified all imports of Logger. Some were called LogManager before.
Now the fb-stub and the fb variants use the same interface.
Constructor of Logger is no longer exposed so it can't be initialized twice, unless in the case you're explicitly using the fb variant, which has extra functionality.
Reviewed By: danielbuechele
Differential Revision: D14083929
fbshipit-source-id: 9b61a06e1264d5f142b5a9188465c99deaf18193
Summary: Change from `recordSuccessMetric` to `reportPlatformFailures`, because the next diff adds `reportPluginFailures` and I want to distinguish the two.
Reviewed By: passy
Differential Revision: D13878380
fbshipit-source-id: 9c6b8bfe1ed2e1a8bbe5aacbec31d24e9aa39171
Summary:
Part 3 and final part of adding customizable ports. To use this, the iOS / Android apps have to also be started with the same custom ports.
Example usage: `FLIPPER_PORTS=8189,8188 yarn start`
Reviewed By: passy
Differential Revision: D13801761
fbshipit-source-id: 3dd80a3001ed0855e54cc568fa94eb6fac5fc7f1
Summary:
We had a promise for initializing the servers, but it wasn't rejected when server startup failed.
Fixed by resolving / rejecting based on the listen / error events fired from the server.
Reviewed By: passy
Differential Revision: D13762580
fbshipit-source-id: a0d1a56473f84dc416e5ce2de91a53b21574f452
Summary: Will provide some visibility on error rates.
Reviewed By: passy
Differential Revision: D13671492
fbshipit-source-id: 60971a7e8163c58dd4d6540e57e05b38c852744e
Summary:
The advantage of this is that anyone can now log without needing to carry around a Logger object.
Primary reason is for making metrics less intrusive in the codebase.
Reviewed By: passy
Differential Revision: D13671368
fbshipit-source-id: 162ab1351a124683aef13983fc3bcec01385cd1a
Summary: Wraps a future and records the success rate. This will be stored along with the sessionId and the userId, so we can drill down and get the success rate at different levels.
Reviewed By: passy
Differential Revision: D13635049
fbshipit-source-id: 4e0e6bdc0f9b76b08cf37c5d9fe87909f7338534
Summary:
This is semi-explorative to see how far we can get with this approach, but I think it'l be useful. If it is, we can factor the code into a nicer utility, that perhaps wraps promises or even just has succeeded/failed methods.
Using 1 and 0 instead of true and false so we can do numerical aggregates on it, like average, which will give the success rate.
This will allow queries such as:
* What percentage of attempts fail? - Not very useful because they get retried if they fail.
* What percentage of sessions that attempt, encounter a failure? - More useful, but still not perfect because they could retry and succeed.
* What percentage of sessions attempt and don't ever succeed? - Better but still not perfect because one device might succeed and another fail, but this will be rare.
Reviewed By: passy
Differential Revision: D13625987
fbshipit-source-id: 2b9f45cc888247d068cc52281443e9ece7985da8
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: 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:
This improves bug reports.
Adding serial into device.toJson() means you can now easily see which clients (apps) are from which device because they both contain the serial.
Changing client id to use # instead of - because the subcomponents of it already use -.
Reviewed By: passy
Differential Revision: D13058430
fbshipit-source-id: 02697ec623829423e667fd2acbd1abc369a6919b
Summary:
I feel like doing async stuff here isn't a good idea in general.
But more pressingly, it means you can't immediately call server.close() after new Server(), because the things to close haven't been created yet.
Reviewed By: danielbuechele
Differential Revision: D10488301
fbshipit-source-id: 76ebe91e0c09f353e0bdb9f2e4116757e757abb2
Summary:
Adds a new type of plugin: `FlipperBackgroundPlugin`
Background plugins are not torn down when the user switches to another plugin so they keep receiving messages in the background.
Background plugins need to use persistedState to keep their data. To handle the messages received in the background they need to implement a static method that merges a message with the current state from redux. The plugin doesn't need to call this method itself, it is called from `client.js`.
```static persistedStateReducer = (
persistedState: PersistedState,
data: Object,
): PersistedState
```
This method is used to handle messages in both foreground and background.
Reviewed By: danielbuechele
Differential Revision: D10256305
fbshipit-source-id: d86da9caa1b75178841a9a347eb427112141eaa3
Summary:
Adds a test runner for jest test and adds three simple test cases:
- render the app
- start a server
- client connecting to the app
Test can be run using `yarn test`.
To make the test runner work, some changes needed to be made:
- remove the export of `init()` from `'flipper'`, because it was a cyclic dependency
- updating Button.js to the new ref-API
Reviewed By: jknoxville
Differential Revision: D10027078
fbshipit-source-id: 49107b0dd4dec666b92ecd841422fe7e6b3a7756
Summary: Not collecting all debug logs because there are so many, but server ones are few and usually important for context on what's connected at the time.
Reviewed By: danielbuechele
Differential Revision: D9654402
fbshipit-source-id: 5ad090838be3e06c25bd93e4d85726822bd7fc4e
Summary:
Android devices don't always know their own serial.
But we do a certificate exchange using adb from the desktop, so we can provide it in the response.
After this the client will provide it every time it connects, so we can do things like filter plugins by device id.
For apps that have already done cert exchange, they'll continue to use 'unknown' as their id until they do it again with an up to date version of sonar.
We can think about forcefully stopping that, but I haven't done it.
Reviewed By: danielbuechele
Differential Revision: D9481460
fbshipit-source-id: f8932699711ebbec4260fabe32f87e6cdff920f2
Summary: The console was pretty spammy. This fixes some issues that were logged and changes many log statements to `console.debug` which are not shown by default.
Reviewed By: passy
Differential Revision: D9303011
fbshipit-source-id: 1102f4f8814152a45f155cb43488a515c2d4eee4
Summary:
[Step 1 of a protocol change between desktop app and flipper agent]
The flipper agent periodically tries to connect.
When it doesn't have the required certs, instead of trying to connect, it requests them from the desktop.
After requesting, it just continues the loop, trying to request.
The problem with that is
a) the desktop can take longer than one cycle to generate and provide the certs, meaning the agent will make overlapping requests, causing confusion and it to take longer than necessary.
b) the desktop can take less time than a retry cycle, but the agent will still wait before trying to connect.
Fixing a) by making the agent wait for a response from the desktop before continuing attempting to reconnect.
This means on the next connection attempt, it's guaranteed that the desktop is finished processing the CSR.
b) remains unfixed for now, but can be dealt with separately.
This is step 1 which adds an extra responder to the desktop app. It won't change anything until the agent starts
sending requestResponse messages instead of fireAndForgets. The plan is to leave this in place for a while to give users time to update, after that, we'll roll out the change to the agent.
Reviewed By: passy
Differential Revision: D9179392
fbshipit-source-id: 9a8021253dcd28c15cceeec23630a67aec219fd5
Summary: At the moment sonar doesn't work with physical iOS devices. Until we add that feature, to avoid confusion, tell the user that it won't work.
Reviewed By: passy
Differential Revision: D8859223
fbshipit-source-id: 318777406877e0f769c6d0dc5bbe745ca0565f55
Summary:
Some errors such as UI errors should be logged whenever they occur, but some, such as those that occur when a device keeps trying to connect but can't, should not be.
This adds the class and replaces the top recurring errors with it.
Reviewed By: danielbuechele
Differential Revision: D8639448
fbshipit-source-id: f001aa1e90eae6d26a8dbfcd3175b51fc486eae9
Summary: The `Client` and `Server` code was in one file, which was messy. This splits it into two separate files.
Reviewed By: emilsjolander
Differential Revision: D8186932
fbshipit-source-id: faa79d7dccd867d69ccd1bccd43a2cf85314b1b3
Summary:
At the moment, in sonar we have an error reporter and a Logger.
ErrorReporter can be encapsulated into Logger, so users don't have to decide between logging and reporting errors.
Reviewed By: danielbuechele
Differential Revision: D8531902
fbshipit-source-id: 3986f51ea163ac939f3baffd4db3ab968f2a0762
