Summary:
In a headless mode we do not have access to local storage. As a result, headless plugins that try to use `persistToLocalStorage` option crash. We should ignore the option for these plugins for now and add a way to persist the plugin state to the disk in a headless mode in the future.
CHANGELOG: Ignore persistToLocalStorage in headless mode
Resolves https://github.com/facebook/flipper/issues/4190
Reviewed By: lblasa
Differential Revision: D40341873
fbshipit-source-id: 40774c0024f79cf1652f24146fd16f6a101ca99e
Summary:
Without seeing the specific messages it might be hard to debug what is taking so long.
CHANGELOG: Enhance a warning about taking too much time to process plugin messages
Differential Revision: D40340272
fbshipit-source-id: a4dbd639cf389763a3cb00a190216c0e653c08e4
Summary:
When we start using Flipper from the CLI for automation, we want to have the list of currently connected devices as soon as flipper server is alive.
Otherwise, we would have to poll flipper server waiting for some magical moment in the future when devices connect.
This way, we can be certain that if flipper server started, but we do not see a device, it is not connected at all.
Reviewed By: mweststrate
Differential Revision: D40184106
fbshipit-source-id: ce4c2b897a2df0081e3a0b6a8c26640599e0f9e8
Summary:
Show users a way to fix Flipper EADDRINUSE on their own without filing a support request
CHANGELOG: Better error message for EADDRINUSE
Reviewed By: mweststrate
Differential Revision: D40338164
fbshipit-source-id: ec0419c78983b55736aa773757775b5302da51e0
Summary: This makes the vizualiser a lot less cluttered
Reviewed By: lblasa
Differential Revision: D40021837
fbshipit-source-id: 8901c9bff6f05ee3fa4517e103c770be1fcfa403
Summary: Previously opening a deep link would always fail with flipper thinking the plugin did not exist. In this diff we wait for plugins to be initialized
Differential Revision: D40142275
fbshipit-source-id: 7894fc60a6df57e13395e05263b0905847b11ad3
Summary:
Related GH issue: https://github.com/facebook/flipper/issues/4139
Context:
The current direction is that all plugins should be able to run in browser envs. Opening external windows, deeplinks and etc. should be abstracted away in getFlipperLib().
For plugin developers, it could be challenging to upgrade the existing plugins that rely on electron being present. We should not failing the build process for them because their plugins depend on electron.
Allow desktop plugin to build
Relevant ticket: https://github.com/facebook/flipper/issues/4139
Pull Request resolved: https://github.com/facebook/flipper/pull/4145
Reviewed By: mweststrate
Differential Revision: D39887902
Pulled By: mweststrate
fbshipit-source-id: 4132912b5a2b598c7897d434647cffed6980de19
Summary: It didnt need to exist and can be seen as a subtree update of type full scan
Reviewed By: lblasa
Differential Revision: D39731552
fbshipit-source-id: e351413d9480e118fc000c5e55eae0e7980233f2
Summary:
A side affect of the new tree implementation was unecessary renders. For very large trees this was noticable to the user.
A condition is added to the props are equal function for the memoized component to consider if this nodes path is a prefix to the new or previous hover path. This indicates whether it needs to rerender or wether the change in hover state is unconsequential to this component.
changelog: Fixed a bug in the nested highlighting of the data inspector, previously it could remain highlighted while moving the mouse away quickly and multiple highlights could be visible at the same time
Reviewed By: mweststrate
Differential Revision: D39883905
fbshipit-source-id: abdac71574695000addb4ba6477503b7d44a4faf
Summary:
There were 2 issues with the previous implementation of the nested hover.
1. If you moved the mouse out of the inspector quickly we would miss the event and we would have a hover state of the root element when we shouldnt
2. The hover state was stored per node, it was possible to have mulitple children hovered at the same time if you moved the mouse fast enough in a very complex tree
The new implementation has the hovered id stored in the Datainspector root. This solves the multiple state issue since there can only be one. Finally There is an onMouseLeave hook added to the parent div which seems to reliably fire no mouse how erractic my mouse movements :) Also the new implementation is a lot easier to understand
Reviewed By: mweststrate
Differential Revision: D39855733
fbshipit-source-id: 96b43f216deef72b81cd52001f8de26df55ea693
Summary:
^
This change allows to take different snapshots for different nodes and render them each on the visualiser.
At the moment, more than likely, this is not really used. At the same time, it fixes an issue whereas any subtree update can override and set the only visible snapshot.
Reviewed By: LukeDefeo, antonk52
Differential Revision: D39821920
fbshipit-source-id: ab8f6a4a2a5e96801c951a4e3009cc571a617f22
Summary:
^
TODO: the snapshot corresponds to the referring subtree update. However, the snapshot is getting applied as if it was the current top view of the running app. This is true in most cases but it doesn't for some. To solve this, we need to use the rootId for the subtree and apply the snapshot only if appropriate.
Having said that, is good enough for the current submission as we keep iterating on it.
Reviewed By: LukeDefeo
Differential Revision: D39813307
fbshipit-source-id: 33b6aff6e9dd085934150ebd2f247062447a59ff
Summary: We have a list of modules that we do not bundle with the plugins, but provide externally to them from Flipper. For the mechanism to work correctly, we have to stop importing from nested paths of these modules.
Reviewed By: mweststrate
Differential Revision: D39776237
fbshipit-source-id: 06eae9bf9d5b11b48d2720bf592bfea749773847
Summary:
Start bundling source maps together with the source code itself in the dev mode. Therefore it is no longer required to add a link to the external source map file in dev mode.
In prod mode we still ship them separately.
Reviewed By: mweststrate
Differential Revision: D39775064
fbshipit-source-id: 6c56df7a3fce084c07a8618a63dbd8ae4741348c
Summary:
^
Adding listeners was correctly intercepting events but the event object often lacked the information necessary to correctly triage and fix an issue.
I discovered that by subscribing to these events directly, the event object did have the required information.
Changelog: Use global window event handlers instead of listeners
Reviewed By: antonk52
Differential Revision: D39809292
fbshipit-source-id: 8a0fc7b7cd86ea16e40f2dc383bc30364f6fc16c
Summary: Currently, if we publish a new shared plugin lib in a separate diff, the compatibility check fails for it while it should exit with a warning only
Reviewed By: antonk52
Differential Revision: D39731259
fbshipit-source-id: 7651642ebfb5e18ace047d36b52907bca65c4462
Summary:
Improved the 2 way relationship between tree and vizualiser. There are 3 states.
1. Select, this is when you click on either tree node or view. View is highlighted darker colour, sidebar shows up for that node and select is persisted when you mouse away
2. Hover, this is when you hover over a tree node or in the vizualizer, the node is highlighted a lighter colur
3. Hover while holding control - same as hover but we dont draw any children, this lets you see how parent nodes appear without their children
Reviewed By: lblasa
Differential Revision: D39695661
fbshipit-source-id: 623e479fb03567e9f15a4a4f9201b2c7884cabe4
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:
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
