Summary: When trying to refactor some components, did once again run into circular imports that cause the flipper startup sequence to fail. Added linting rules to make sure this is much less likely to happen in the future, and fixed all resulting errors
Reviewed By: nikoant
Differential Revision: D24390583
fbshipit-source-id: 9b20cf6a4d3555dc68f0069c2950dd7162b17e67
Summary: This diff adds the device switcher, filling the switcher with apps and devices.
Reviewed By: cekkaewnumchai
Differential Revision: D24053787
fbshipit-source-id: 4f69835a12eec90a0e5704f71c8ceed5509f61ce
Summary: Recreation of D22118786, which was so old rebasing died on some lacking meta data. Lands https://github.com/facebook/flipper/pull/1256
Reviewed By: passy
Differential Revision: D24331424
fbshipit-source-id: 65fc5d8bf0242d4266e269716a319d71ce2e2826
Summary: In D24138822 I basically bumped all desktop deps. That was a bit too much as it affected our build infra and broke it. The problem wasn't easy to bisect so choose a smaller set of deps instead to update; everything transpile & lint related + a few well tested runtime deps.
Reviewed By: cekkaewnumchai
Differential Revision: D24161841
fbshipit-source-id: 67162efeccd05a344b229ce976102cfafe6d1099
Summary:
Changelog: Flipper can now launch iOS simulators by using `File > Launch Emulator...`
In the Sandy designs the device selector dropdown no longer shows the option to launch an emulator. So added a button to app inspect and the main menu instead.
I found it always a bit funny that we can launch android emulators, but not iOS emulators. Turns out that launching them is actually not very complex, so added capabilities to launch ios emulators
Reviewed By: jknoxville
Differential Revision: D24021737
fbshipit-source-id: c106cc2246921e008f9c808ebb811d8e333aa93b
Summary: This is a small utility to be able to render a react element without giving it a position somewhere in the react render tree, so that dialogs can be triggered and rendered imperatively for example.
Reviewed By: cekkaewnumchai
Differential Revision: D24021752
fbshipit-source-id: 84633624c63c72a38a1b277207efba75af358a03
Summary:
I noticed that after the typescript upgrade, I got several weird positives from ESLint (like unused parameters in a type definition, which are obviously always unused, e.g. `type onClick = (e: Event) => void`). After some investigation, it turned out these warnings are generated by eslint, but that those rules should be performaned by typescript/eslint instead. For future reference to which rules this applies:
https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/README.md#extension-rules
Updated the config, and while at it, fixed all warnings in our codebase, except for `react-hooks/exhaustive-deps` warnings, since those require semantic changes.
This reduces the amount of eslint warnings from 86 to 39.
Reviewed By: passy
Differential Revision: D23905630
fbshipit-source-id: 0557708fd9ec6b17840a3c191e7d3baf225bdf23
Summary: May be useful for stability signals, or general bug correlation down the line.
Reviewed By: nikoant
Differential Revision: D23904843
fbshipit-source-id: ca31722b58d4657a9600fe5ce16ea3b5efd2c870
Summary:
We're seeing some CSR mismatches when they aren't expected. Adding logging to print out what is being found, to see if it's any OS-specific encoding issues or something like that, or completely different CSRs, etc.
URL encoded in case there are differences in non printable characters.
Reviewed By: nikoant
Differential Revision: D23867267
fbshipit-source-id: f406a396c808687b6b84561eb1def61b565aee34
Summary:
Implemented a first button: make main menu collapsible.
Also introduced some additional utilities and hooked up startup performance logging
Reviewed By: cekkaewnumchai
Differential Revision: D23783500
fbshipit-source-id: 2456fd781a52d497facbaccfabe885e4f8c408c5
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/1532
Upgrade to Electron 10, in an attempt to fix random hard Electron crashes. Didn't fix it, but given the changelog of Electron with all the bug fixes, seems to be a good idea nonetheless :)
Changelog: Flipper now uses Electron 10
Reviewed By: nikoant
Differential Revision: D23565000
fbshipit-source-id: 3f07b8cf8c438147bde5314698d20046ac9f94cf
Summary:
Now full restart is not required for applying plugin changes (install/uninstall/update). So this diff changes the behavior to use reload instead of restart in Plugin Manager and Auto Update Manager. It is much faster than full restart.
Changelog: faster reload after plugin install/uninstall/update.
Reviewed By: jknoxville
Differential Revision: D23706701
fbshipit-source-id: b2dcaf7768a5d47b3c967c17e090fa74884b3850
Summary:
- Removed compilation on startup which is not required anymore after switching to plugin spec v2.
- Removed from Node process ("static" package) all the dependencies which are not required anymore: e.g. metro, babel etc.
- Plugin loading code from node process moved to browser process and made asyncronous.
Some expected benefits after these changes:
1) Reduced size of Flipper bundle (~4.5MB reduction for lzma package in my tests) as well as startup time. It's hard to say the exact startup time difference as it is very machine-dependent, and on my machine it was already fast ~1500ms (vs 5500ms for p95) and decreased by just 100ms. But I think we should definitely see some improvements on "launch time" analytics graph for p95/p99.
2) Plugin loading is async now and happens when UI is already shown, so perceptive startup time should be also better now.
3) All plugin loading code is now consolidated in "app/dispatcher/plugins.tsx" instead of being splitted between Node and Browser processes as before. So it will be easier to debug plugin loading.
4) Now it is possible to apply updates of plugins by simple refresh of browser window instead of full Electron process restart as before.
5) 60% less code in Node process. This is good because it is harder to debug changes in Node process than in Browser process, especially taking in account differences between dev/release builds. Because of this Node process often ended up broken after changes. Hopefully now it will be more stable.
Changelog: changed the way of plugin loading, and removed obsolete dependencies, which should reduce bundle size and startup time.
Reviewed By: passy
Differential Revision: D23682756
fbshipit-source-id: 8445c877234b41c73853cebe585e2fdb1638b2c9
Summary:
Sorry for so long diff, but actually there are no functional changes, just refactoring to make further changes of Plugin Manager easier to understand.
I've de-coupled the code related to plugin management from UI code and moved it from PluginInstaller UI component (which will be replaced soon by new UI) to "flipper-plugin-lib". So pretty much everything related to plugin discovery and installation now consolidated in this package.
Additionally, this refactoring enables re-using of plugin management code in "flipper-pkg", e.g. to create CLI command for plugin installation from NPM, e.g.: `flipper-pkg install flipper-plugin-reactotron`.
Reviewed By: passy
Differential Revision: D23679346
fbshipit-source-id: 82e7b9de9afa08c508c1b228c2038b4ba423571c
Summary:
we used to send plugins list with connect command, now we can respond to getPlugins request with new api.
we still support old clients
Reviewed By: jknoxville
Differential Revision: D23625139
fbshipit-source-id: 37a24d0c83cd879d93287dd3a3d4d5d2f9477b34
Summary:
This allow websocket client to receive and reply messages from desktop client.
## Changelog
Implement requestResponse for websocket connection, allowing websocket client to receive and reply messages from desktop client
Pull Request resolved: https://github.com/facebook/flipper/pull/1510
Test Plan:
Tested with custom websocket client, allow communicating getPlugins, init, deinit, etc.
But I think it's better to have dedicated unit tests for this (currently there's none?), let me know what you think.
Reviewed By: passy
Differential Revision: D23499396
Pulled By: jknoxville
fbshipit-source-id: fb445c0634afd46a525fc52da33b487da4e591fe
See D23051239
Since the crash reporter endpoint does not exist anymore, and no data was reported there, removing the corresponding code from Flipper as well.
This also fixes the last remaining startup warning as well :)
Reviewed By: priteshrnandgaonkar
Differential Revision: D23472612
fbshipit-source-id: 7ce9f6a0261cdfe197a7da9b28a86407299effec
Summary: This diff adds analytics for events like uploading certs, zipping certs.Also logs the payload data received in trusted and untrusted request handlers. It will be helpful to debug the issues through this events.
Reviewed By: jknoxville
Differential Revision: D23374024
fbshipit-source-id: 6fa709bbf05e1b99ed1882be953abbd968eefc6e
Summary:
Bringing the pkd CPU usage fix to open source releases.
Now when idb is installed, Flipper will always use it to check for devices, and only fallback to instruments if not.
Fixes https://github.com/facebook/flipper/issues/1028
Reviewed By: passy
Differential Revision: D23293675
fbshipit-source-id: 6ff3e89167f5f6d4130f197b2a675202334d0e7d
Summary:
Some non-semantic changes. Mostly an earlier rename that was accidentally done only locally rather than across the codebase
Also support `.spec` test extension, which is more idiomatic Jest, since we don't use the `.node` and `.electron` distinction anymore anyway.
Reviewed By: jknoxville
Differential Revision: D22976438
fbshipit-source-id: f3abedb36cbac1e835295177117ccbca492a67a1
Summary:
As per the title
Bug:
{F288338655}
Reviewed By: mweststrate
Differential Revision: D23168390
fbshipit-source-id: e57ac1f22c0a3932fe9948d16cf9fc9cc74ab636
Summary:
This diff adds upload and download logic for certs. It makes changes on both Flipper Client and Desktop side. With this we enable cert exchange through WWW.
Next Diffs:
1) Add Flipper state in cert provider for more debug data
2) Tests
Reviewed By: jknoxville
Differential Revision: D23092706
fbshipit-source-id: e576253606b64b62848b70203db7e09a3bd77fd9
Summary:
Running `instruments -s devices` causes the `pkd` process in catalina to spike to ~100% for a few seconds.
Flipper runs this command every 3 seconds to poll for devices.
This switches it to use `idb list-targets` instead which is much more performant.
Currently switched off in the open-source version while we make sure it's working well. If you set the GK value 'flipper_use_idb_to_list_devices' to true, then you'll get the new behaviour.
Reviewed By: passy
Differential Revision: D23102067
fbshipit-source-id: 9e17155d938a4fe326e082511f747444e4b533a2
Summary:
This diff adds a toggle setting in wilde which will enable certificate exchange through www.
Right now it just sends the information about which medium to be used for cert exchange to Flipper JS and its client side. But its implementation is not done yet.
### Flow for Wilde
Whenever user changes the setting(or when user logs out) we set the state of exchange medium and accordingly set/reset authtoken. Note at no given point we remove already existing certificates.
### Context for OSS
With this diff we introduce another way to do certificate exchange. Before this diff, we did certificate exchange by accessing the file system of app. But it turns out it's not possible to do that in applications signed by enterprise certs. Thus with this diff one can write their FlipperKitCertificateProvider and fetch the certificate from WWW.
Reviewed By: jknoxville
Differential Revision: D22896320
fbshipit-source-id: 55aef7028a62e71ba9c02f9f79acaab41d09c0c6
Summary: This is tanking our success rates, but is an expected behaviour.
Reviewed By: jknoxville
Differential Revision: D23001697
fbshipit-source-id: 48bcdb99543d590d544cce8322950568a0ef5c6f
Summary:
Added support for `createPaste` in Sandy plugins
Nice minimalistic example of how to expose a Flipper api to Sandy.
Note that some indirection could be removed by having an interface that is shared directly between `BasePluginClient` and `FlipperLib` (e.g. `PublicFlipperLib`). In contrast to `addMenuEntries` from the previous diff, `createPaste` is basically exposed verbatim to Sandy without additional wrapping, so those cases could be made simpler. Maybe will do that later.
Reviewed By: passy
Differential Revision: D22815873
fbshipit-source-id: e6d0773a35341edfe5de0898317eaadf88de79d0
Summary:
[interesting] since it shows how Flipper APIs are exposed through sandy. However, the next diff is a much simpler example of that
This diff adds support for adding menu entries for sandy plugin (renamed keyboard actions to menus, as it always creates a menu entry, but not necessarily a keyboard shortcut)
```
client.addMenuEntry(
// custom entry
{
label: 'Reset Selection',
topLevelMenu: 'Edit',
handler: () => {
selectedID.set(null);
},
},
// based on built-in action (sets standard label, shortcut)
{
action: 'createPaste',
handler: () => {
console.log('creating paste');
},
},
);
```
Most of this diff is introducing the concept of FlipperUtils, a set of static Flipper methods (not related to a device or client) that can be used from Sandy. This will for example be used to implement things as `createPaste` as well
Reviewed By: nikoant
Differential Revision: D22766990
fbshipit-source-id: ce90af3b700e6c3d9a779a3bab4673ba356f3933
Summary:
The device type enum was mixing two different concepts (emulator vs physical) and (archived vs not), and we already have a separate `isArchived` field. So cleaned this up to not leak it into sandy.
If anybody can think of any unforeseen consequences of this, lemme know :)
Reviewed By: jknoxville
Differential Revision: D22763506
fbshipit-source-id: bd2f7dbd1d2d2e6942ba7c6ddd8dc91ee34d591d
Summary: Introducing a base abstract class (blegh) to share some life cycle management between Device- and normal plugins. Cleaned up the test utils a bit as well + some old TODO's that now have been taken care of
Reviewed By: nikoant
Differential Revision: D22727089
fbshipit-source-id: 507816f1bfdbc6e7e71d4bd365b881b6710ca917
Summary:
This diff makes sure that devices will actually instantiate applicable sandy device plugins. Similar to how client plugins are owned by Client, device plugins are directly owned by BaseDevice, which significantly simplifies life cycle management and doesn't dispatch updates to all Redux connect components whenever something irrelevant changes.
Also made sure `device.teardown()` is called. That API already existed, but wasn't used or implemented before.
Updated Flipper test utils to support testing device plugins as well (both Sandy and classic ones)
Reviewed By: passy, nikoant
Differential Revision: D22693929
fbshipit-source-id: 73b2b8666ef7a0e748ea89360db84734d37eb5be
Summary:
This stack introduces Sandy device plugins, they are quite similar to normal plugins, but, a devicePlugin module is organized as
```
export function supportsDevice(device): boolean
export function devicePlugin(devicePluginClient)
export function Component
```
Device plugins get access to the device meta data and can subscribe to the `onLogEntry` callback and `onDestroy` lifecycle.
They will be able to store state just as normal plugins, but can't send or receive methods, so devicePluginClient is a bit limited.
This diff only sets up most of the new data structures, and makes sure everything still compiles and no existing tests fail.
To prevent this diff from becoming to big, actually loading, rendering and testing device plugins will be done in next diffs
Please take a critical look at the api proposed and the (especially) the public names used :)
Reviewed By: passy, nikoant
Differential Revision: D22691351
fbshipit-source-id: bdbbd7f86d14b646fc9a693ad19f33583a76f26d
Summary:
The current Popover component isn't compatible with the new (in progress) component library because it relies on overflowing container elements, which isn't allowed in the generic Layout component.
So this is a new Popover element, which uses absolute positioning instead. It takes heavy inspiration from the Tooltip and TooltipProvider components which do a similar thing.
Still to do:
[x] Edge cases when popover would be near a window edge
[x] Style it to look nice
[x] Split the use case (RatingButton) changes into a separate diff
[x] When the location of the popover container moves (the rating button in this case, e.g. if you resize the window), it doesn't currently cause the effect function in the popover, so it doesn't get moved when it should
[x] Add a little pointer thingy like a speech bubble
[x] Make sure it's perfectly positioned
[ ] Rename it to Popover and delete the old one. Not done, since it's just a stopgap.
Reviewed By: mweststrate
Differential Revision: D22693105
fbshipit-source-id: bc141433914bc20da48f8ae96764a95f7cd74ce5
Summary:
let's finally inspect flipper with flipper!
Here we have:
1) a self inspection client which implements FlipperClient interface from js sdk and FlipperClientConnection. It links back and front parts of self inspection
2) simple plugin (UI) to show messages
3) back part of that plugin - it sends all received messages to UI part via client
4) we initialize self inspection for dev builds only
P. S. filesystem dependency will be replaced with npm one before I ship it (need to publish to npm first)
Reviewed By: mweststrate
Differential Revision: D22524533
fbshipit-source-id: 5c77e2f7b50e24ff7314e791a4dfe3c349dccdee
Summary:
This diff makes sure Sandy plugins show up as well in the plugin selector when making exports (and in support form as well).
Also verified that this works with the Sandy updated section plugin.
Note that persisted state now didn't need any changes in the plugin code to work :)
Commented / simplified the calculation of available plugins a little bit and fixed a confusing issue where two different redux stores where created in one unit test, which caused an issue in the new implementation.
Reviewed By: jknoxville
Differential Revision: D22434301
fbshipit-source-id: c911196bc5b105309e82204188f124f40aab487a
Summary:
Made Sandy plugins part of the export / import logic
Note that in the export format there is now a `pluginStates2` field. It could have been put in `pluginStates` as well, but I started with that and it felt very weird, as the `pluginStates` are supposed to reflect what is living in the Redux stores, where sandy state doesn't live in the Redux store (not directly at least). Trying to store it in the same field made things overcomplicated and confusing.
Reviewed By: jknoxville
Differential Revision: D22432769
fbshipit-source-id: d9858e561fad4fadbf0f90858874ed444e3a836c
Summary:
This plugin adds serialization capabilities to Sandy plugins buy setting the a `persist: <key>` flag. This shouldn't be used for state that is unserializable, too big, too sensitive, or irrelevant during export / import.
Using an explicit `persist` flag is done to make plugins robust to changes over time; as long as the key is kept the same, state variables can be renamed and reordered without breaking the import / export format. Also it allows us to detect some changes in the import / export format and warn about it.
Alternative designs considered but not implemented would be:
1. requiring the user to explicitly return the state from the factory (e.g. `const todos = createState([]); return { todos }`,
2. or construct the state from client (e.g. `const todos = client.createState([])`)
3. enable persistence by default, and store states in the order the states were created (much like useState in React). This was implemented in the first versions of this diff, but as pointed out in the discussions, this is too sensitive too (accidental) format changes, as the storage format would be quite implicit
A nice benefit of the current approach, especially compared with alternative approach 1, is that state being restored is immediately visible in the plugin factory. In other words, directly after initialization `const todos = createState([])`, the `todos.get()` is actually set to the state that is being restored, rather than having still the initial state which is only overridden rather. So this behaves very much like the `useState` hook in React.
Furthermore, in the future we could use the same `persist` key in combination with other options, such as `saveToLocalStorage`, in case some state acts as a 'preference' (T69989583).
`TestUtils.startPlugin` supports starting plugins with an initial state by using the optional `initialState` field
Actually wiring up the serialization and deserialization into the export / import functionality of Flipper is done in the next diff.
Reviewed By: jknoxville
Differential Revision: D22432770
fbshipit-source-id: 9a4849582c2f6f54d1e40f65a6cba73092c28fe8
Summary:
Turns out, we don't have any tests that _actually_ depend on Electron. What is more, the one test suite that was still left was actually failing for a long time, but somehow CI didn't pick and reported that :-P.
Note that I dropped the file `xplat/sonar/scripts/facebook/lego/run-sc-yarn-targets-with-electron.sh` entirely, as it appeared unused
Reviewed By: nikoant
Differential Revision: D22434441
fbshipit-source-id: 34df79a580a64904116ae93069bbc8fafc53d9d0
Summary:
While writing unit tests discovered a bug that disabling a plugin doesn't guarantee cleaning the messagequeues (both the buffer in client and the messagequeue reducer).
Fixed that. That was thanks to @#%@#$@#%@ Redux a lot harder than it should be; as 'STAR_PLUGIN' reasons about a plugin + app name, while the message queue reducer would need to deduct the plugin keys from that, but it can't because that mapping is stored in the connections reducers. So I moved the `STAR_PLUGIN` action handling to the root reducer, sot that it can reason about the state of multiple reducers, which looked like the least of all evils. For more ranting about that and possible alternative solutions: https://twitter.com/mweststrate/status/1277556309706117122
Reviewed By: nikoant
Differential Revision: D22284043
fbshipit-source-id: 35d0a8ba3a21a5959d2bb6ef17da3ff5077f48fd
Summary: This diffs adds the capability to listen to messages in Sandy plugins. Although API wise it looks more like the old `this.subscribe`, semantically it behaves like the `persistedStateReducer`; messages are queued if the plugin is enabled but not active.
Reviewed By: nikoant
Differential Revision: D22282711
fbshipit-source-id: 885faa702fe779ac8d593c1d224b2be13e688d47
Summary: Really nothing interesting to see here , just moved pluginStats out of messageQueue, as it started there and kept growing
Reviewed By: nikoant
Differential Revision: D22257318
fbshipit-source-id: 26be7efb4629fcef1b14de96a2b60f17f7d76785
Summary:
When running unit tests, every unit would try to make a graphql request (since promises always kick off immediately, even when not being awaited) and print an error. Fixed that by lazily choosing the preferred whatever it is.
Before:
{F241368814}
After:
(crickets)
Reviewed By: passy
Differential Revision: D22208422
fbshipit-source-id: b290d528d94dbed7ae867e07694d8d4cd85d8376
Summary: Replaced `instanceof` checks with `isSandyPlugin` utility. That is cleaner to read and makes it easier to find places where we make exceptions for Sandy plugins
Reviewed By: jknoxville
Differential Revision: D22206707
fbshipit-source-id: b44a1b585424f3b9bf0d7ce200c34107f03ed55e
Summary:
This diff makes sure sandy plugins are initialized.
Sandy plugins are stored directly in the client for two reasons
1. we want to decouple any plugin state updates from our central redux store, as redux is particularly bad in handling high frequency updates.
2. The lifecycle of a plugin is now bound to the lifecycle of a client. This means that we don't need 'persistedStore' to make sure state is preserved; that is now the default. Switching plugins will no longer reinitialize them (but only run specific hooks, see later diffs).
3. PersistedState will be introduced for sandy plugins as well later, but primarily for import / export / debug reasons.
A significant difference with the current persistent state, is that if a client crashes and reconnects, plugins will loose their state. We can prevent this (again, since state persisting will be reintroduced), but I'm not sure we need that for the specific reconnect scenario. Because
1. we should fix reconnecting clients anyway, and from stats it looks to happen less already
2. reconnects are usually caused by plugins that aggregate a lot of data and get slower over time. Restoring old state also restores those unstabilites.
For the overview bringing back the archi picture of earlier diff:
{F241508042}
Also fixed a bug where enabling background plugins didn't enable them on all devices with that app.
Reviewed By: jknoxville
Differential Revision: D22186276
fbshipit-source-id: 3fd42b577f86920e5280aa8cce1a0bc4d5564ed9
Summary: Unit tests tend to randomly bail out once FBLogger is (indirectly) required by some module under test. This makes sure FBLogger is stubbed by default. We might want to do the same for `User` in the future.
Reviewed By: jknoxville
Differential Revision: D22186274
fbshipit-source-id: 2ede364c4b691d69826781355592226b075d8367
Summary: The test mock utilities now return a promise, rather than taking a callback, which makes tests slightly nicer to read (similar to react-testing-library). No semantic changes.
Reviewed By: jknoxville
Differential Revision: D22186278
fbshipit-source-id: ec5b9f4e6bfeee9160e331f8c20a1d4fdcbfeede
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: This diff enables the installation for iOS simulators. This also fixes the error view created when there is an error. Right now there is a bug on my machine where idb doesn't detect my physical device. But once it is detected, it will work.
Reviewed By: mweststrate
Differential Revision: D22137831
fbshipit-source-id: b6d6f77318c6baef78c35af73db3969b7dd1b907
Summary:
Well this is embarassing. My iPhone is called iPhone, so I assumed instruments always outputs "iPhone" for iPhones, but it doesn't if they've got a different name.
Pointed out in https://github.com/facebook/flipper/issues/262
Reviewed By: nikoant
Differential Revision: D22066872
fbshipit-source-id: 847e1baf28103692dc9472d9730b6384ec719be0
