Summary:
Noticed that subsequent `adb logcat` invocations are stateful, and we didn't clear it's state when clearing the logs in memory.
This is a bandaid to get back to the previous behavior. I am wondering whether it wouldn't be just much more intuitive to always clear the logs (`adb logcat -c`) before we start the streaming log listener, so that users are never shown old logs from before flipper was connected?
Also fixed a leak in cleaning up the log listeners that was revealed by the possibility to disable the log plugin
Reviewed By: nikoant
Differential Revision: D26450262
fbshipit-source-id: 5b426e2d0e1fafdbc512d48d22b7bd4f30b61309
Summary:
*Stack summary*: this stack adds ability to manage device plugins in the same way as client plugins: install, update, uninstall, enable (star) and disable (unstar) them.
*Diff summary*: changed the way how plugin compatibility with devices is checked from dynamic call to "supportsDevice" to static checks of "supportedDevices" metadata property which make it possible to check compatibility without even downloading plugin from Marketplace.
Changelog: plugin compatibility with devices is now checked according to metadata in property "supportedDevices" in package.json
Reviewed By: mweststrate
Differential Revision: D26315848
fbshipit-source-id: 6e4b052c4ea0507ee185fc17999b6211cdb11093
Summary:
Minor code cleanup to avoid future confusion:
- archived: a device that was imported from a Flipper trace, and only has persisted state
- (dis)connected: a real stateful device that might or might not have an active connection
Reviewed By: nikoant
Differential Revision: D26275459
fbshipit-source-id: eba554b37c39711e367c3795ff4456329a303c22
Summary:
This diff addresses two problems:
1. Since clients plugins can be active beyond having a connection, we have to make it possible for plugin authors to check if they are connected before they make a call.
2. if there is a custom `exportPersistedState`, plugins should be able to skip making calls if the device has disconnected.
Introducing this change makes it possible to interact with a reasonable level with disconnected clients, and makes it possible to create Flipper traces for disconnected clients.
Note that both items were already problems before supporting offline clients; as there can be a noticeable delay between disconnecting and Flipper detecting that (i've seen up to 30 secs). What happend previously in those cases is that the export would simply hang, as would other user interactions, as loosing the connection in the middle of a process would cause the promise chains to be neither rejected or resolved, which is pretty iffy.
Before this diff, trying to export a disconnected device would hang forever like:
{F369600601}
Reviewed By: nikoant
Differential Revision: D26250895
fbshipit-source-id: 177624a116883c3cba14390cd0fe164e243bb97c
Summary:
It should be possible to exported disconnected devices, so that flipper traces / support form reports can be created from them. This diff introduces this functionality. Support for plugins with custom export logic is introduced in a later diff.
Issues fixed in this diff:
- don't try to take a screenshot for a disconnected device (this would hang forever)
- device plugins were always exported, regardless whether the user did select them or not
- sandy plugins were never part of exported disconnected clients
- increased the amount of data exported for device logs to ~10 MB. This makes more sense now as the logs will no longer be included in all cases
- fixed issue where are plugins would appear to be enabled after the client disconnected (this bug is the result of some unfortunate naming of `isArchived` vs `isConnected` semantics. Will clean up those names in a later diff.
Changelog: It is now possible to create a Flipper trace for disconnected devices and apps
Reviewed By: nikoant
Differential Revision: D26250894
fbshipit-source-id: 4dd0ec0cb152b1a8f649c31913e80efc25bcc5dd
Summary:
Introduced `isConnected` flag on device and plugin client to reflect whether a connection is still available for the plugins, or that they have been disconnected.
Potentially we could expose the (readonly) `connected` state atom for this as well, or an `onDisconnect` event for device pugins, to create a responsive UI, but there might be no need for that, in which case this suffices.
Reviewed By: nikoant
Differential Revision: D26249346
fbshipit-source-id: b8486713fdf2fcd520488ce54f771bd038fd13f8
Summary:
This diff stack introduces support for keeping devices and clients around after they have disconnected. This is a pretty important debugging improvement, that will allow inspecting a device / app after it crashed for example.
This feature existed partially before, but only supported Android, and only support plugins with persisted state; as it replace the current device with an archived version of the same device. In practice this didn't work really well, as most plugins would not be available, and all non-persisted state would be lost.
This diff makes sure we can keep devices around after disconnecting, the next one will keep the clients around as well. And explain some code choices in more detail.
Note that `Device.isArchived` was an overloaded term before, and even more now (both representing imported and disconnected devices), will address that in a later diff.
https://github.com/facebook/flipper/issues/1460https://github.com/facebook/flipper/issues/812https://github.com/facebook/flipper/issues/1487
Changelog: iOS and Android devices will preserve their state after being disconnected
Reviewed By: nikoant
Differential Revision: D26224310
fbshipit-source-id: 7dfc93c2a109a51c2880ec212a00463bc8d32041
Summary:
Logs were stored hardcoded on the Device object first, this diff makes it normal plugin state.
This makes sure that we can use the same abstractions as in all plugins that store large data sets, and that we can leverage the upcoming DataSource abstraction.
Reviewed By: nikoant
Differential Revision: D26127243
fbshipit-source-id: 7c386a615fa7989f35ba0df5b7c1d218d37b57a2
Summary: Per title, this allows for pre-processing data after it is deserialized and before it is stored in the plugin
Reviewed By: nikoant
Differential Revision: D26126423
fbshipit-source-id: bc08a6ab205d2a0d551515563cd85a197595ddb2
Summary:
Sandy plugins can now set up an `onExport` handler to enable customizing the export format of a plugin: `client.onExport(callback: (idler, onStatusMessage) => Promise<state>)`
Import will be done in next diff
Reviewed By: nikoant
Differential Revision: D26124440
fbshipit-source-id: c787c79d929aa8fb484f15a9340d7c87545793cb
Summary: Plugin metadata format extended to include type of each plugin (client / device) and list of supported devices (android/ios/..., emulator/physical, etc). This will allow to detect plugins supported by device even if they are not installed and only available on Marketplace.
Reviewed By: mweststrate
Differential Revision: D26073531
fbshipit-source-id: e331f1be1af1046cd4220a286a1d52378c26cc53
Summary:
I've re-designed interfaces describing plugins as I found that mental overhead working with them became too expensive because of slightly flawed design. However this cascaded changes in many files so you can see how extensively these interfaces used in our codebase.
Before this change we had one interface PluginDetails which described three different entities: 1) plugins installed on the disk 2) plugins bundled into Flipper 3) plugins available on Marketplace. It's hard to use this "general" PluginDetails interface because of this as you always need to think about all three use cases everywhere.
After this change we have 3 separate interfaces: InstalledPluginDetails, BundledPluginDetails and DownloadablePluginDetails and things became much type-safer now.
Reviewed By: mweststrate
Differential Revision: D25530383
fbshipit-source-id: b93593916a980c04e36dc6ffa168797645a0ff9c
Summary:
Introduced API to replace the deprecated `selectPlugin` in Sandy.
The API can be used to navigate from `device plugin -> device plugin`, or` client plugin -> device / client plugin`
Introduced `isPluginAvailable` as well, so that the user interaction an be fine tuned in case the plugin is not disabled.
Reviewed By: jknoxville
Differential Revision: D25422370
fbshipit-source-id: c6c603f1c68e6291280b3d0883e474448754ded1
Summary:
`activatePlugin` events where not recorded correctly for Sandy plugins. Although the starting measuerments is fired the `connections` reducer, the completing event fires from `PluginContainer`. Since this is done as part of a ref-update (!!), see [here](https://www.internalfb.com/intern/diffusion/FBS/browse/master/xplat/sonar/desktop/app/src/PluginContainer.tsx?commit=65a625ea9941&lines=155), and the ref to the corresponding element is not set for Sandy plugins, the event was never marked as completed.
Fixed this by making it part of the `activate` life-cycle event of Sandy plugins.
Reviewed By: passy
Differential Revision: D25421537
fbshipit-source-id: 5cbfeb91cc12e4520fa271bab24034094d7ddb39
Summary: Make sure that GKs can be used in pure sandy plugins.
Reviewed By: jknoxville
Differential Revision: D25368358
fbshipit-source-id: c7c6aa4ecf0443cb3b5d90e22e8aca9a73a69389
Summary:
Set up basic primitives for user interaction tracking. I hope the docs and unit tests in this diff are self explanatory :)
In upcoming diffs:
* Wire up to scuba events
* Annotate all important parts of Flipper Chrome
* Investigate if we can wrap important interactions of ANT by default
Reviewed By: jknoxville
Differential Revision: D25120234
fbshipit-source-id: 9849d565d7be27e498cc2b4db33e7d6e6938ee06
Summary: `unstablebatched_updates` should be used whenever a non-react originating event might affect multiple components, to make sure that React batches them optimally. Applied it to the most import events that handle incoming device events
Reviewed By: nikoant
Differential Revision: D25052937
fbshipit-source-id: b2c783fb9c43be371553db39969280f9d7c3e260
Summary: This diff adds the `client.onUnhandledMessage` handler, to be able to handle messages for which we don't know the names upfront. Some existing plugins that only send one kind of message can benefit from this, as can generic plugins, like the createTablePlugin
Reviewed By: passy
Differential Revision: D24949453
fbshipit-source-id: 0fed81e28aee350632c09ee3bb834f306dc8b100
Summary: expose `appName`, `appId` and `device` to Sandy plugins. Will be used in next diff to migrate navigation plugin
Reviewed By: cekkaewnumchai
Differential Revision: D24857253
fbshipit-source-id: 03ac3d376d5d1950bcf3d78386a65ce167b517e3
Summary: `supportsMethod` wasn't implemented in the new sandy APIs so far, but is needed for D24108772
Reviewed By: cekkaewnumchai
Differential Revision: D24109496
fbshipit-source-id: 694344b423c1805baa193e4f2e1ad5f28483378b
Summary: In the attached task an IPv6 address ended up in the URL send from IG. Since that URL couldn't be parsed, it crashed the network plugin. This change makes sure the plugin doesn't crash on invalid urls.
Reviewed By: cekkaewnumchai
Differential Revision: D23344503
fbshipit-source-id: c7ac2068e407a764d59e632bef1be7c4239c8c8a
Summary:
Documented all exposed Sandy APIs plugin developers should know about.
Honestly didn't proof-read it myself yet, but wanted to publish this diff at least before PTO, so that the information is available to anyone interested / playing with sandy
Reviewed By: jknoxville
Differential Revision: D22976373
fbshipit-source-id: c30918201d2feeb306ca0d9a3ae1ec10bdf7e2f5
Summary: Little ux tweak, there are some rare scenarios where you can end up in an empty plugin screen, made a small message.
Reviewed By: jknoxville
Differential Revision: D22846396
fbshipit-source-id: 0ad19f1c252112d78a5587e6633fee2d9542d5e1
Summary:
Converted the DeviceLogs plugin to sandy.
Kept logic and UI the same (so same batching, localstorage mechanisms etc). But used sandy api's for log subscribing, state, and separating the logical part of the component from the UI.
Note that some mechanisms work slightly different, like deeplinking and scrollToBottom handling, to reflect the fact that plugins are now long lived
Reviewed By: jknoxville
Differential Revision: D22845466
fbshipit-source-id: 7c98b2ddd9121dc730768ee1bece7e71bb5bec16
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:
Device plugins have an activate and deactivate hook, that reflects the plugin being selected in the UI. Added these same hooks to client plugins as well. In practice they are called at the same times as `onConnect` and `onDisconnect`, except for background plugins, which connect only once, so it is pretty useful to be still able to make the distinction.
Since there is now quite some common functionality between plugins and device plugins, will clean things a bit up in a next diff
[Interesting] as it explains the difference between the different lifecycle methods of plugins, and the impact of being a background plugin
LIfecycle summary:
1. app connects
2. for background plugins: connect them (`onConnect`)
3. user selects a plugin, triggers `onActivate`. will also trigger `onConnect` the plugin if it _isnt_ a bg plugin
4. user selects a different plugin, triggers `onDeactivate`. will also trigger `onDisconnect` if it isn't a bg plugin.
5. app is unloaded. Triggers `onDisconnect` for bg plugins. Triggers `onDestroy` for all plugins,
Reviewed By: jknoxville
Differential Revision: D22724791
fbshipit-source-id: 9fe2e666eb37fa2e0bd00fa61d78d2d4b1080137
Summary:
Make sure device plugins can be deeplinked as well.
(note that the duplication between `Plugin` and `DevicePlugin` is cleaned up again in D22727089, first wanted to make it work and tested, then clean)
DeepLink no longer have to be strings, per popular requests, as that makes direct linking between plugins easier (online links from the outside world have to arrive as strings)
Reviewed By: jknoxville, nikoant
Differential Revision: D22727091
fbshipit-source-id: 523c90b1e1fbf3700fdb4f62699dd57070cbc980
Summary: Now that we can load device plugins, let's make sure they are rendered as well.
Reviewed By: passy, nikoant
Differential Revision: D22693927
fbshipit-source-id: 22574ec6e629e6dd66e42193b406ceb7dfcf1836
Summary: Add unit tests to verify that the unit test utilities for for Sandy device plugins work as expected. Fixed a bug revealed by that and cleaned up some TODO's
Reviewed By: jknoxville, passy, nikoant
Differential Revision: D22693928
fbshipit-source-id: 93162db19d826d0cd7f642cef1447fd756261ac8
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:
This adds support for handling incoming deeplinks in a Sandy plugin, which can be done by using a `client.onDeepLink(deepLink => { } )` listener
Also generalized deeplinks to not just support strings, but also richer objects, which is beneficial to plugin to plugin linking.
Reviewed By: jknoxville
Differential Revision: D22524749
fbshipit-source-id: 2cbe8d52f6eac91a1c1c8c8494706952920b9181
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: While testing manually discovered the sandy plugin infra din't cover the case that a plugin can be selected but not enabled at the same time. Added test and fixed that.
Reviewed By: nikoant
Differential Revision: D22308597
fbshipit-source-id: 6cef2b543013ee81cee449396d523dd9a657ad1c
Summary:
`usePlugin(pluginFactory)` returns the current plugin instance's api that was exposed by the plugin directory.
Passing `pluginFactory` is technically strictly not needed, but having the user pass it, we can make sure it is strongly typed
Reviewed By: nikoant
Differential Revision: D22286293
fbshipit-source-id: 4268b6849b8cd3d524103de7eadbd6c0a65c7a61
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: Sandy plugins can now send messages to plugins. The methods and params are strongly typed in implementation and unit tests, based on the <Methods> generic of FlipperClient.
Reviewed By: nikoant
Differential Revision: D22256972
fbshipit-source-id: 549523a402949b3eb6bb4b4ca160dedb5c5e722d
Summary:
This sets up the initial infra that is to be used by plugin devs to test plugins.
There is not much yet to see, as there is no state or message sending yet. But at least the life cycle of plugins can be test, things are strongly typed and everything is in the place where it should be :)
N.b. the import difference with these utils and the createFlipperMock utilities in Flipper are
1. this testing infra is entirely inside flipper-plugin package, so that plugin devs don't need flipper as a dependency
2. this testing infra doesn't provide abstractions for plugin / device / client switching; it tests plugins purely in isolation of the rest of the world (except for firing `onConnect` / `onDisconnect` which is normally the effect of switching plugins)
Reviewed By: nikoant
Differential Revision: D22255262
fbshipit-source-id: b94ccbab720d2b49428a646aed3c55af71a5bc80
Summary:
Introduced hooks that are called whenever the plugin is connected / disconnected to it's counter part on the device.
There is some logic duplication between `PluginContainer` for old plugins, and `PluginRenderer` for new plugins, mostly caused by the fact that those lifecycles are triggered from the UI rather than from the reducers, but I figured refactoring that to be too risky.
Reviewed By: jknoxville
Differential Revision: D22232337
fbshipit-source-id: a384c45731a4c8d9b8b532a83e2becf49ce807c2
Summary: PluginContainer will now wrap Sandy plugins in PluginRenderer. PluginRenderer will also be used by plugin unit tests in the future
Reviewed By: jknoxville
Differential Revision: D22159359
fbshipit-source-id: 69f9c8f4bec9392022c1d7a14957f5aca0339d97
Summary: This diff introduces the `onDestroy` hook that can be used by plugins to listen to the event where a plugin is cleaned up (either because it is disabled, or because the client is being cleaned up)
Reviewed By: jknoxville
Differential Revision: D22208121
fbshipit-source-id: 9c4951ae671be611f21da171c548d4054c481166
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: Make sure Sandy plugins are loaded properly from disk
Reviewed By: jknoxville
Differential Revision: D22186275
fbshipit-source-id: fd2f560a7bed959b18e05db2a087909ad876ab9d
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
