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:
`scrollTo` used there caused the window to scroll to the most left when a user was inspecting an element which horizontal scroll wasn't in the most left position.
This diff removes the horizontal constrain and only scroll vertically.
Reviewed By: mweststrate
Differential Revision: D23284227
fbshipit-source-id: 7c19cac7496927c631572e222cb1d635dd1f8ea4
Summary:
Note: this is to be stacked upon https://github.com/facebook/flipper/pull/1479
Note: this PR will probably not succeed against FB internal flipper, as I'm pretty sure there are more call sites that need to be updated. So consider this WIP
Currently connection errors are managed in the connection reducers, and are displayed through their own means, the error bar. Showing console.errors is also hooked up to this mechanism in FB internal flipper, but not at all in the OSS version, which means that some connection errors are never shown to the user.
Besides that there is a notification system that is used by for example the crash reporter and plugin updater.
Having effectively (at least) two notifications mechanisms is confusing and error prone. This PR unifies both approaches, and rather than having the connection reducer manage it's own errors, it leverages the more generic notifications reducer. Since, in the previous PR, console errors and warnings have become user facing (even in OSS and production builds, which wasn't the case before), there is no need anymore for a separate error bar.
I left the notifications mechanism itself as-is, but as discussed in the Sandy project the notification screen will probably be overhauled, and the system wide notifications will become in-app notifications.
## Changelog
Pull Request resolved: https://github.com/facebook/flipper/pull/1483
Test Plan: Only updated the unit tests at this point. Manual tests still need to be done.
Reviewed By: passy
Differential Revision: D23220896
Pulled By: mweststrate
fbshipit-source-id: 8ea37cf69ce9605dc232ca90afe9e2f70da26652
Summary:
While converting Bloks-Script plugin, Timur found a bug where the message queue wasn't processed.
Although queue processing was unit tested, the integration into the rendering lifecycle wasn't explicitly tested and missed a TODO that already signalled this should have been implemented.
Added a unit test to verify the bug and fix. Also tested in a running Flipper instance with the converted plugin (next diff)
Reviewed By: jknoxville
Differential Revision: D23263909
fbshipit-source-id: 63783c980247bdf6c93d00a46881d7d0eb291d09
Summary: If myles is taking too long users might experience issues with multiple tabs open for 'open in diffusion' functionality. This diff addresses this problem by displaying 'open in ide' menu only if the path is already resolved.
Reviewed By: mweststrate
Differential Revision: D23242199
fbshipit-source-id: ffa698110d4c5e0c0e0686fbc56a7eea6b5782e6
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: 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:
Handling issues typically start with: did you look at the Electron logs? Since Flipper is such an extensible tool, running in varying environments I think the console should be support as first class concept. Many errors are currently not shown to the user. This PR is a first attempt to fix that.
The implementation is based on https://github.com/samdenty/console-feed, which is used by quite some web based IDE like tools (like codesandbox), and offers a lot of goodies out of the box, like collapsing errors, objects, etc.
Edit: also added a counter keeping track of the amount of errors
N.B. no need to immediately review this diff, I'll import it to phabricator as soon as I can :)
## Changelog
changelog: Introduce 'Debug Logs' section to help users to troubleshoot issues or to provide more accurate reports.
Pull Request resolved: https://github.com/facebook/flipper/pull/1479
Test Plan: 
Reviewed By: jknoxville
Differential Revision: D23198103
Pulled By: passy
fbshipit-source-id: a2505f9fa59e10676a44ffa33312efe83c7be55d
Summary:
As per the title
Bug:
{F288338655}
Reviewed By: mweststrate
Differential Revision: D23168390
fbshipit-source-id: e57ac1f22c0a3932fe9948d16cf9fc9cc74ab636
Summary: Bringing this to the latest version everywhere.
Reviewed By: priteshrnandgaonkar
Differential Revision: D23051537
fbshipit-source-id: 5cad59ab6fcc57fc72df8ace985a7b5f39de2bda
Summary:
Detect the framework used for a given component and accordingly, display a proper IDE list.
[FB Only]
changelog: It is now possible to directly open CKComponents from the Layout inspect
Reviewed By: adityasharat
Differential Revision: D23158628
fbshipit-source-id: 305f10752c72eac001334f09bab29264e3e328a6
Summary:
Added corresponding method for CKComponents which handles two main cases:
- CKSomeComponent_Spec should have corresponding CKSomeComponentSpec.mm
- CKSomeComponent should have corresponding CKSomeComponent.mm
Reviewed By: cuva
Differential Revision: D23158626
fbshipit-source-id: 9d5645a70d838847696aced6bbc947a8c4383f0c
Summary: Useful for next diffs: enables to detect whether we have LithoComponent or CKComponent
Reviewed By: adityasharat
Differential Revision: D23128972
fbshipit-source-id: b9aef358c1426df4f05213c42e43402e8cae984f
Summary:
Few cases to consider:
- SomeComponent.* might correspond to SomeComponentSpec.java
- SomeComponent.* might correspond to SomeComponentSpec.kt
- SomeComponent.* might not have a corresponding Spec file
- SomeComponent.kt (if it's a KComponent) corresponds to SomeComponent.kt
Reviewed By: adityasharat
Differential Revision: D23100032
fbshipit-source-id: f0604f3d1061f0e15fa2f455bdddd4d07ac12305
Summary:
- Passing the `treeNodeIndexPath` from `FocusInfo` all the way to the `Tree` component.
- Using the index path to find the right node and give it a different visual appearance.
Reviewed By: kevin0571
Differential Revision: D23161057
fbshipit-source-id: 05a95444bb76c1f28a21b42bf477ed9c9929e3b1
Summary:
- Added `treeNodeIndexPath` to `FocusInfo` which represents the path to the selected node in the component tree.
- Extracting scope root ID from payload to identify the time line track that corresponds to the selected component.
- Finding the most recent 'Tree Build' event on the track so we can be sure the selected component is in the associated component tree.
- Extracting the index path to the selected node in the tree.
Reviewed By: kevin0571
Differential Revision: D23160875
fbshipit-source-id: 8607bf7b34bca1374f9fafded197b35c811f3f75
Summary:
- Use `FocusInfo` type instead of a raw string (I'll add another field to it in the next diff and it made sense to keep the changes separate).
- `userSelectedGenerationId` now has the type of `string | undefined` for consistency.
Reviewed By: fabiomassimo
Differential Revision: D23160820
fbshipit-source-id: f210d93b9ed7cb25eb3c2c8e6e6aadec4dc872d7
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:
Added papercuts link to the thanks message after user submits a rating within the star rating popup.
Also increased the timeout after submitting ratings from 1500 to 5000, due to the longer thanks message. Also added a dismiss option.
Reviewed By: jknoxville
Differential Revision: D23115320
fbshipit-source-id: 78de3481e5a085949ddbfbdd51ff499b8b567959
Summary:
There's a bug in the network inspector.
Messages come in in batches for performance reasons.
These batches can include both requests and responses, but the code assumes only one or the other.
This fixes it to make it not mutually exclusive.
This bug only affects row building in the table, so when you click on the row, you can still see the response and everything.
Reviewed By: cekkaewnumchai
Differential Revision: D23102575
fbshipit-source-id: 47e8c6b0f1c9cf0d5860b6f349a7d9fe225c73ae
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: Added new events for 'open in IDE' functionality within the Layout Plugin
Reviewed By: passy
Differential Revision: D23075105
fbshipit-source-id: 1d18977da728bb4c53cd13e8669253dea65d7c4d
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:
It's common for responses to be completely missing in the network inspector. This is because they are larger than can be serialized in one go on some devices, so we drop all messages larger than 1MB.
This changes the android client to send large responses in individually serialized batches. This way we avoid running out of memory and can still send arbitrarily large payloads.
Changelog: Android network inspector can now handle responses large than 1MB.
Reviewed By: passy
Differential Revision: D22999905
fbshipit-source-id: ff4eb8fa72a7e42ea90d12ffe0f20c6d1e58b7e5
Summary:
Added infra for writing and using custom eslint rules and created a rule for disallowing cross-package file imports. Such imports are anti-pattern and they also break standalone plugin bundling.
We still have a bunch of places where Flipper core references code directly from plugins. I've ignored these places for now and added task T71355623 to revisit them.
Reviewed By: passy
Differential Revision: D22998955
fbshipit-source-id: d04cff8fc115ba1300a7e6830306ec134046e927
Summary:
thefutureisnowoldman
Changelog: Changelog entries now link to their GitHub commits
Reviewed By: passy
Differential Revision: D22999105
fbshipit-source-id: 77e4884a3515245ba9296d8c4f59cdcb3c4b098d
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/1442
Layout plugin cannot be bundled as a standalone package because it imports a file from outside of its folder. This change exposes IDEFileResolver in a proper way so now it's possible to import it from 'flipper'.
Reviewed By: passy
Differential Revision: D22975515
fbshipit-source-id: 8af6d2ca1ceb8627a449e055c8773549dd681b7a
Summary:
Dropdown menu to select IDE in which the Litho Component will be opened.
Some Litho Components do not have corresponding Spec files. Hence, I am first trying to access files with Spec suffix and retrying if fails without the suffix. The number of such files is limited.
[FB Only]
changelog: It is now possible to directly open source files from the Layout inspector
Reviewed By: adityasharat
Differential Revision: D22922126
fbshipit-source-id: e1109c995427755a28ba78a65f5ff98392fb7060
Summary: Populate class name for Litho Components.
Reviewed By: adityasharat
Differential Revision: D22922106
fbshipit-source-id: e18b748e0e0bd6f511558124a28b4b58d217ded7
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:
No device was using this feature, so doesn't look like there is a reason to keep it.
...if somebody was about to use this feature, let me know :). But probably, if we need this, a much more simple solution is to determine the visible columns with a simple switch on device type in the logs plugin, even though that is strictly speaking less scalable. But the current solution feels a bit over-engineered for something that is not really used.
Marked [interesting] as I might be missing some background concept which would make this relevant as well.
Reviewed By: jknoxville, nikoant
Differential Revision: D22763507
fbshipit-source-id: ecdbc779cbbfa3b0b72c80b459b12c1a25bf3fc4
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: More is more. Just moving code, no further changes.
Reviewed By: nikoant
Differential Revision: D22374891
fbshipit-source-id: 65c9af8b4b34ee8e16aeae5705528093e1c800cc
Summary: Didn't understand what that field meant. Turns out, it was never used.
Reviewed By: nikoant
Differential Revision: D22374893
fbshipit-source-id: c36d8f0c1be1b27306347d1c8c8a763c621720a5
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
