Summary: We had an issue where the offset for a native view was effectively caclculated twice and summed, once by litho and once by android. Given the UI debugger expects a nodes bounds to be w.r.t its parent the android systems x,y offset is 'wrong' from ui debuggers perspective, we set it to 0,0 and rely on the calculated offsets by the litho component hierachy
Reviewed By: lblasa
Differential Revision: D39695663
fbshipit-source-id: d9c2be950fc68bc2286359a62746356e89299cfd
Summary: Without this change gatekeeped and disabled plugins are also counted as loaded, which results in plugin duplication in the UI
Reviewed By: lblasa
Differential Revision: D39695335
fbshipit-source-id: 759e2e0eaead1bee0f7d61e4ba3d1b8e4b6c0976
Summary: Some plugins import from shared directories. These directories are not plugins themselves, therefore the current plugin root searching mechanism does nto work for them. To support plugin reloading for this scenario, we start re-building all plugins if we fail to find a plugin root.
Reviewed By: lblasa
Differential Revision: D39693820
fbshipit-source-id: 33dd7de4121bd5665a39b0ea96adce4603dc7df0
Summary:
We would like to version control Flipper and some of our custom plugins that are installed on developers' systems.
Flipper by default prompts users to upgrade so they sometimes do the update and then all our custom plugins break because they were compiled for an older version.
See https://github.com/facebook/flipper/issues/3947 for feature request info.
## Changelog
Adds notifyAvailable flag to config.json to disable prompting for users that "an update is available"
Pull Request resolved: https://github.com/facebook/flipper/pull/3992
Test Plan:
Tested by running locally.
Had to comment out the isProduction() check to confirm this it worked properly because this flag is false on dev versions.
Couldn't figure out how to manually test the handleOpenPluginDeeplink.tsx change but made a similar change there; happy to test that if you can tell me how to exercise that path.
Reviewed By: antonk52
Differential Revision: D39654481
Pulled By: antonk52
fbshipit-source-id: cef6b48d870915c48f620269c42d24b8ef1f4c29
Summary:
Introduced some basic bidirectional link between tree and wireframe, the specific interaction will need some tweaking but this should get us started.
When hovering over the tree we halt the rendering of the wireframe up to that point, this allows us to explore parent views that layout child views.
When clicking a view in the wireframe it is 'seleceted' as if it was clicked in the tree. This set the tree selection so you can identify it in the tree as well as opens the side bar
Reviewed By: lblasa
Differential Revision: D39539277
fbshipit-source-id: 3beb1ad4cb56b398c640ac3e7fac2cc97f3f1a18
Summary: Basic visual wireframe for the purposes of verifying that our captured view hierachy is correct, the actual version we ship will hopefully be a lot better :)
Reviewed By: lblasa
Differential Revision: D39539278
fbshipit-source-id: 73d926ff1990f09ca9877430cb227f690d05d1d4
Summary: Split our the mega component into separate parts in preparation for the visualizer
Reviewed By: lblasa
Differential Revision: D39509406
fbshipit-source-id: 0f867c1f8a91b7592673ae47ba2b5db4f3500732
Summary: This is to support a future diff where we will draw a basic wireframe for debugging
Reviewed By: lblasa
Differential Revision: D39509407
fbshipit-source-id: d99fd6fe39404996a0ed944c10905331262fd0c6
Summary: It was building at target sdk 0 before which lead to various checks failing, in future when these checks fail we should send a notification to flipper
Reviewed By: lblasa
Differential Revision: D39652095
fbshipit-source-id: 748bc74f0b5745011e6289e5582405149df8357f
Summary: Catch the case when we mis the initial draw
Reviewed By: lblasa
Differential Revision: D39658946
fbshipit-source-id: 00a46226128e28a8753df2161d1edcd6ffa47d67
Summary: Previously we were cancelling the entire context which meant after reconnect nothing was sent. Additionally we now close / reinitiaze the channel so that any old events are not sent on reconnect
Reviewed By: lblasa
Differential Revision: D39658945
fbshipit-source-id: bb02724434aa820d811b49ab799a4643ab7e785a
Summary:
^
`mutableClass` should be used instead of `clazz`
Reviewed By: LukeDefeo
Differential Revision: D39652102
fbshipit-source-id: 8ba86d39796beed79ff7cf8b37f3460facc38430
Summary:
Remove usage of '!!', it is generally discourages even though instances are guaranteed to exist.
Adjust comments
Reviewed By: LukeDefeo
Differential Revision: D39575368
fbshipit-source-id: a159a0411a913de3d1ae6236c41ea15255687433
Summary: Keep a weak reference of the view instead of a strong reference.
Reviewed By: LukeDefeo
Differential Revision: D39575312
fbshipit-source-id: ae8df7d089b29ea3b1cf960a6ae020ed5a9c3648
Summary:
^
There's no way to address these warnings, so suppress.
Reviewed By: LukeDefeo
Differential Revision: D39575262
fbshipit-source-id: 6703476d7637c63aa9a81b26f8cdbd0f53e3991c
Summary: This change tidies up the traversal and removes unused LayoutVisitor
Reviewed By: LukeDefeo
Differential Revision: D39575241
fbshipit-source-id: 2ab101f74ae7b2c16ddf7016abc78a03590916b0
Summary:
^
These are the last two types imported from stetho which, if anything, can be integrated as is without having to track back to Stetho
Reviewed By: LukeDefeo
Differential Revision: D39573639
fbshipit-source-id: 8009532116ec7b2fed2751fa966269ad81a7cb00
Summary:
^
After this change lands, it is safe to remove most of the Stetho fragment support types.
Reviewed By: LukeDefeo
Differential Revision: D39460121
fbshipit-source-id: 0e7d4ce71e828ee7bc9c6e945b8fe27dbd6f08f8
Summary:
In D39311893 (094c5bdfdd) we started monkey-patching `require` to resolve global dependencies in the plugins. Apparently, patching `globalThis.require` did not work in the electron env. On my local machine it kept working because I had the experimental `flipper-server` feature enabled which embeds flipper-server into the electron build. In flipper-server we properly patch `require` via `Module.prototype.require` which affected the global require in electron.
With this fix we now properly patch require in electron via Module.prototype.require all the time
Changelog: Fix plugin loading with experimental flipper-server disabled
Reviewed By: nikoant
Differential Revision: D39633821
fbshipit-source-id: 9554f643c625620d116075ae87f573d8447850f6
Summary:
This is mainly an RFC version (happy to land it as a seed for a plugin that can be used to debug and/or control status) the plan is to have the following:
- One place to track the full life-cycle of status.
- Control and visualize playback and state.
- Troubleshoot errors and details of a given status (e.g. media links, evets, latencies .. etc).
Differential Revision: D38123193
fbshipit-source-id: 49229d604434d575d6aaddc818064598e7ccee92
Summary: Now that we build all plugins at all times and it is super-fast, these options are redundant
Reviewed By: lblasa
Differential Revision: D39542723
fbshipit-source-id: 1b30ba384267ec4fd0c35b4dc14f0223ffe414c9
Summary: Restart electron app if we had any server-code changes
Reviewed By: lblasa
Differential Revision: D39542169
fbshipit-source-id: fb8e335f3e3fe0cf34e57a79b96e9cc8377e9fda
Summary: `requirePlugin` in electron uses native `require` which has a built-in cache. Without this fix a stale version of the plugin loaded.
Reviewed By: lblasa
Differential Revision: D39542121
fbshipit-source-id: e6c4b65f9ea7b816803baaae537c234914fcb3d7
