Commit Graph

3 Commits

Author SHA1 Message Date
Michel Weststrate
2e7015388c Remove remaining Electron imports from product code: paths & env
Summary:
This diff removes most remaining Electron imports, by storing env and path constants on the RenderHost. As nice side effect those paths are all cached now as well.

To make sure RenderHost is initialised before Flipper itself, forced loading Flipper through a require. Otherwise the setup is super sensitive to circular import statements, since a lot of module initialisation code depends on those paths / env vars.

Reviewed By: nikoant

Differential Revision: D31992230

fbshipit-source-id: 91beb430902272aaf4b051b35cdf12d2fc993347
2021-11-03 07:01:21 -07:00
Michel Weststrate
96cbc81e63 Fix connection and DOM management of React DevTools
Summary:
This diff fixes several existing issues in the React DevTools:

Every time the user opened the plugin we re-instantiated the devtools, which has a few problems: 1) it looses all state (e.g. selection), and 2) this causes the tools to start a websocket listener on a new port, that was never cleaned up, or ever used, since React Native always connects to port 8097 anyway.

To preserve the state the idea of the original implementation was to move the devTools out of the current view, without disposing it. This actually didn't work in practice due to a faulty implementation, causing a full reinialization of the tools every time. Addressed this by reusing the mechanism that is used by the Hermes debugger tools as well.

By properly managing the port (e.g. closing it), there is no need to start (in vain) the devTools on a random port.

Port reversal for physical devices needs to happen only once, in principle upon connecting the device, so moved it to the device logic, which also avoids the need to hack into the global Flipper store.

Avoiding recreating the devTools makes plugin switching near instant, instead of needing to wait for a few seconds until the devTools connect.

When multiple apps are connected the behavior is now consistent: the application that refreshed last will be the one visible in the devTools. (That is still pretty suboptimal, but at least predicable and not a use case that is requested / supported in the DevTools themselves atm)

There is still ugly DOM business going on, did put that in a stand alone component for now.
Didn't extract the shared logic with Hermes plugin yet, but did verify both are still working correctly.

Changelog: [React DevTools] Several improvements that should improve the overal experience, the plugin should load much quicker and behave more predictably.

Reviewed By: bvaughn

Differential Revision: D28382587

fbshipit-source-id: 0f2787b24fa2afdf5014dbf1d79240606405199a
2021-05-12 14:21:53 -07:00
Anton Nikolaev
b3274a8450 Plugin folders re-structuring
Summary:
Here I'm changing plugin repository structure to allow re-using of shared packages between both public and fb-internal plugins, and to ensure that public plugins has their own yarn.lock as this will be required to implement reproducible jobs checking plugin compatibility with released flipper versions.

Please note that there are a lot of moved files in this diff, make sure to click "Expand all" to see all that actually changed (there are not much of them actually).

New proposed structure for plugin packages:
```
- root
- node_modules - modules included into Flipper: flipper, flipper-plugin, react, antd, emotion
-- plugins
 --- node_modules - modules used by both public and fb-internal plugins (shared libs will be linked here, see D27034936)
 --- public
---- node_modules - modules used by public plugins
---- pluginA
----- node_modules - modules used by plugin A exclusively
---- pluginB
----- node_modules - modules used by plugin B exclusively
 --- fb
---- node_modules - modules used by fb-internal plugins
---- pluginC
----- node_modules - modules used by plugin C exclusively
---- pluginD
----- node_modules - modules used by plugin D exclusively
```
I've moved all public plugins under dir "plugins/public" and excluded them from root yarn workspaces. Instead, they will have their own yarn workspaces config and yarn.lock and they will use flipper modules as peer dependencies.

Reviewed By: mweststrate

Differential Revision: D27034108

fbshipit-source-id: c2310e3c5bfe7526033f51b46c0ae40199fd7586
2021-04-09 05:22:00 -07:00