Summary: It removes the ScribeLogger found in flipper-ui-core and also updates its references to point to the type defined in flipper-common.
Reviewed By: passy
Differential Revision: D48556328
fbshipit-source-id: 525d9e8ee9a80f68aecb8b8b2e25ffd4714649bd
Summary: It makes little sense to hide this info from developers. It was also requested by antonk52
Reviewed By: LukeDefeo
Differential Revision: D44631235
fbshipit-source-id: 1756c5ca2a95b2f815f8c4336621d3c057b704f2
Summary: On downloading the new flipper update some of the older plugins which are on a different release cycle may try to call getUser which was removed in this stack in favour of getCached user and fetchUser, adding this back temporarily so those calls dont fail. This can be removed down the road once those plugins have soaked into the user base
Reviewed By: ivanmisuno, aigoncharov
Differential Revision: D44541277
fbshipit-source-id: 95e67d5ba11bbc26590d2789127cbf6a68c54f16
Summary:
This diff introduces a few changes:
The login sheet is no longer closable via the x or clicking outside the modal, the cancel button is removed
On startup we check if we have a toke and throw up the sheet
if logout occurs for any reason we throw up the sheet
renamed write_keychain to login, to be consstent with the logout method. It does more than write to key chain since it manages the logged in atom also
Reviewed By: aigoncharov
Differential Revision: D44502483
fbshipit-source-id: 1d91d4eaae65ca523a08e205d1ad730d4d4d090f
Summary:
Logged in state now means that we have a valid token. On startup we try to retrieve a token, if its there then we are logged in, if we remove the tokem, due to explicit logout, or if its expired we are logged out.
Connected is more dynamic, it means we can actually hit intern with a sucessful response. It implicitly requires a token / being logged in
Reviewed By: aigoncharov
Differential Revision: D44502482
fbshipit-source-id: e3077101766cba5128a61d62be3bbd1ca1f00b4f
Summary:
Previously the left rail state was decided by prescense of user profile but we are moving to logged in state being based on the atom.
As a result we need to cache the user profile so we have something to display when user not on vpn on startup
Reviewed By: aigoncharov
Differential Revision: D44502477
fbshipit-source-id: 11462d24c773d6d364e844b4f606e124e5278348
Summary: Move User from reducers to flipper-common. User will now be usable by other modules.
Reviewed By: passy
Differential Revision: D37599802
fbshipit-source-id: 66412e7ed00bf27448fa2deae70f0e8e80303aba
Summary:
^
This change aims to extract some bits and pieces that are not specific to FBLogger and could be used by other Logger implementations.
Reviewed By: passy
Differential Revision: D36473286
fbshipit-source-id: 57f02d132673dbac97384da4dca51bf3e6fb8738
Summary:
This is PR on top of: https://github.com/facebook/flipper/pull/3473
It adds an option to Settings to allow distribution of marketplace plugins.
Also includes a simple fetch function to retrieve data from external API/server.
## Changelog
Allow marketplace plugins
Pull Request resolved: https://github.com/facebook/flipper/pull/3491
Test Plan:
1. Enable marketplace
2. Provide custom marketplace server (it will serve the list of internal plugins with downloadURL)
3. Test if can see Available plugins and can download/remove the plugin
4. If new update for the plugin, it should also allow auto update
Reviewed By: antonk52
Differential Revision: D34586339
Pulled By: nikoant
fbshipit-source-id: c887982aa0f0f9abd3b5360f22e8692a2445d345
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/3473
This diff is the first one which addresses https://github.com/facebook/flipper/issues/3320.
In this diff we are making a part of the code used for internal Flipper plugin distribution in Meta also available publicly for re-using in other orgs.
Some explanation on how plugin installation and updates is designed now:
1) We periodically poll for plugins available for download. API for retrieving available plugins list is abstracted and will be different between public and fb versions, however all other logic is re-used.
2) In addition to "Enabled" and "Disabled" plugins in the left panel Flipper shows "Detected in App" list. Plugins in this list are those which are known compatible with the currently selected device/app, but not yet installed.
3) User can install any of "Detected in App" plugins by clicking to "Download and install" button near them in the left panel similarly to enabling plugins in "Disabled" list.
4) If we detect that for some installed plugin we have a newer version available for download - we download it silently and store on disk.
5) If the plugin for which we have new downloaded version is disabled - we update it silently without any notifications by loading new version from the disk and unloading the previous version from cache.
6) If the plugin for which we have new downloaded version is enabled then we avoid updating it automatically (because we need to reset plugin state in such case) and instead show notification on top of the plugin and ask user to reload it to apply new version. On reloading we reset the plugin state.
7) On Flipper startup we always update all plugins to their latest versions available on the disk.
Reviewed By: aigoncharov
Differential Revision: D34380308
fbshipit-source-id: a94d724e42aa5ef78445af266fcd4c424226a703
Summary: This diff moves send intern request from the browser to the server. The reason to make this change is that making such requests from a browser environment causes CORS restrictions to kick in.
Reviewed By: nikoant
Differential Revision: D32835449
fbshipit-source-id: e8e92e51ca963aa50b3c859bb61c2381171e85ae
Summary: This diff moves keychain storage to the server. Figured to leave request logic itself in the UI-core, as basically all use cases happen there, except for streaming download for mobile build plugin, so sending the requests from the backend doesn't really seem to add value, unless we run into some CORS issues later.
Reviewed By: passy
Differential Revision: D32596715
fbshipit-source-id: f5ab9d794f91a6eb8a8dc07ae723bf2890726771
Summary:
This diff moves a lot of stuff from the client to the server. This diff is fairly large, as a lot of concept closely relate, although some things have split off to the earlier diffs in the stack, or are still to follow (like making intern requests).
This diff primarily moves reading and storing settings and GKs from client to server (both flipper and launcher settings). This means that settings are no longer persisted by Redux (which only exists on client). Most other changes are fallout from that. For now settings are just one big object, although we might need to separate settings that are only make sense in an Electron context. For example launcher settings.
Reviewed By: passy, aigoncharov
Differential Revision: D32498649
fbshipit-source-id: d842faf7a7f03774b621c7656e53a9127afc6192
Summary:
This diff moves all UI code from app/src to app/flipper-ui-core. That is now slightly too much (e.g. node deps are not removed yet), but from here it should be easier to move things out again, as I don't want this diff to be open for too long to avoid too much merge conflicts.
* But at least flipper-ui-core is Electron free :)
* Killed all cross module imports as well, as they where now even more in the way
* Some unit test needed some changes, most not too big (but emotion hashes got renumbered in the snapshots, feel free to ignore that)
* Found some files that were actually meaningless (tsconfig in plugins, WatchTools files, that start generating compile errors, removed those
Follow up work:
* make flipper-ui-core configurable, and wire up flipper-server-core in Electron instead of here
* remove node deps (aigoncharov)
* figure out correct place to load GKs, plugins, make intern requests etc., and move to the correct module
* clean up deps
Reviewed By: aigoncharov
Differential Revision: D32427722
fbshipit-source-id: 14fe92e1ceb15b9dcf7bece367c8ab92df927a70
