Summary:
Enumeration used to be a type containing a single property value of type string.
The InspectableEnum is a type that had an Enumeration value and possible values.
As we removed possible values from the enum value, this structure no longer serves its purpose.
Reviewed By: antonk52
Differential Revision: D41400874
fbshipit-source-id: e5c2d1e15ee9b3074ddd69f75ee9b8150d44379f
Summary: Wanted to write about this for a while as we're reinventing the rules every time we get to this time of the year. :)
Reviewed By: LukeDefeo, antonk52
Differential Revision: D41434886
fbshipit-source-id: 445c6c259bee74874472cf246fdc209e82514fcd
Summary:
As metadata got split from attributes, raw data became harder to read.
This change annotates raw data with attribute names to ease readability and thus usability.
Reviewed By: antonk52
Differential Revision: D41400622
fbshipit-source-id: 8bebb2bd368490b9d7a2b4435749cdf0570b7571
Summary: If there are no attributes for a given section, display a 'No data available' message rather than having an empty panel.
Reviewed By: antonk52
Differential Revision: D41400252
fbshipit-source-id: 0337702f638b9b917e6b3be5962838d2eb15c20d
Summary:
Litho margins/padding/borders have the following attributes:
- left, top, right, bottom
- horizontal, vertical
- all
- start, end
This change processes these attributes and creates a SpaceBox inspectable which enables the margin visualiser in Flipper Desktop.
Reviewed By: LukeDefeo
Differential Revision: D41375299
fbshipit-source-id: be8bac1819f2b17c2fd1b1b86678aa0559278609
Summary: If we have a milliseconds portion of a date that's <100, we'd fill in zeroes in a symmetrical way (around the value) rather than filling in at the front, which led to some confusion.
Reviewed By: mweststrate
Differential Revision: D41342194
fbshipit-source-id: a8f60110dcad8bfa77b81abed88df0b0643c780e
Summary:
Before this change, possible values for an enumeration were embedded within the attribute value itself.
After this change, possible values are located within the attribute metadata.
Reviewed By: LukeDefeo
Differential Revision: D41337003
fbshipit-source-id: cef5654a679e9b961e82993abb201b518fcbcd00
Summary:
There were 2 situations where the UI hadn't changed but we were sending a nodes with a different Id accross traversals which confuses things on the desktop
1. By removing the litho observer we are repeatidly scanning the entire hierachy on scroll or when a video plays. The debug component that represents litho views are not stable, they are generated each time even if the underlying component is the same
2. Offset child is generated by us each time and the old id refered to the generated offset child not the underlying object
This diff addresses these 2 cases by allowing a descriptor to choose the ID.
The nodeId convience method was used in a lot of places. For the places where the id ended up in the protocol we have migrated to the descriptors getID. In some other places it is only used internally or for logging. In this case I have renamed the method and changed the return type from Id to int so it cant be accidently used in the protocol
Reviewed By: lblasa
Differential Revision: D41307239
fbshipit-source-id: 655b230180a6d02d66888e86b2293eead3385455
Summary: In a previous diff the Bounds was made mandatory and the fragment bounds was set to be the same as the underlying view. this caused the offset to be doubled since the underlying view would also apply that offset. Since fragments dont contribute to layout and are purely for lifecycle we can set it to 0 and handle it on the desktop
Reviewed By: lblasa
Differential Revision: D41304500
fbshipit-source-id: 39591b3ef0c746bd7a4ec8d61fed623cc7c94944
Summary:
Previously we would only consider a node hit if the nouse pos was inside every parents. There are a few reason why this isnt ideal:
1. Fragments are return 0 bounds
2. Many hierachys (particually in litho ) have nonsensical strucutres where your parent may have hieght 0, or children overflow parents bounds. Therefore it was impossible to select many nodes but unclear why
Reviewed By: lblasa
Differential Revision: D41304499
fbshipit-source-id: d75c8060f71fa0b972f136cb11258b62a9c98ebc
Summary:
There seem to be a number of issues with registering to all changes properly for litho observer.
Removing it and allowing the decor view to do a full traversal fixes a number of problems. The performance with hardware rendering seems to be fine. This should be stopgap untill we tackle time travel properly
Reviewed By: lblasa
Differential Revision: D41304501
fbshipit-source-id: 5b7cdbd0dac04ba0dbf8dd5e449c99f0db4d0863
Summary: Pretty much copy/paste from Pascal's post on data pipelines as it provides a quick overview of things involved
Reviewed By: passy
Differential Revision: D41274753
fbshipit-source-id: 337b034d2460ba448582b9dea70b835898627faa
Summary: This change alphabetically sorts the 'Under the Hood' section and adds a 'Meta' parent category for everything that is internal as to add a visual cue of what is internal and whats not.
Reviewed By: passy
Differential Revision: D41273678
fbshipit-source-id: 1acf8da184762d5924bff90b6691be1e4be92c46
Summary:
In our organization, Flipper is distributed in a version controlled way. As a result, we do not want users to manually update or receive prompts to update when a new version is available. There is already a `--updater` flag in the command line arguments for flipper.exe, but it isn't piped through. This change pipes it through and disables all update related UI when `--no-updater` is passed in.
## Changelog
Support --updater and --no-updater options for flipper.exe
Pull Request resolved: https://github.com/facebook/flipper/pull/4277
Test Plan: Ran `yarn build --win` in flipper/desktop, and launched flipper.exe from flipper/dist/win-unpacked with the `--updater`, `--no-updater` and no flags and ensured the proper behavior was observed (update UI shows by default or when `--updater` is specified, and doesn't show when `--no-updater` is specified).
Reviewed By: passy
Differential Revision: D41298321
Pulled By: mweststrate
fbshipit-source-id: 5ddfede2700954f0fdd6a111b20d0836fab25565
Summary:
There are situations where multiple siblings overlap and they are both hit. Previously we picked the first one in the hierachy. Now we produce a list of hit children. The list will not have 2 nodes in the same ancestor path.
We store the hovered nodes as a list as we may want to present a modal in future to ask user which node they indented to select. That said simply sorting nodes by area seems to give decent results so we can start with this
Reviewed By: lblasa
Differential Revision: D41220271
fbshipit-source-id: 643a369113da28e8c4749725a7aee7aa5d08c401
Summary:
The Dom events for the divs that are very close together were not firing correctly causing the old implementation to not track the hovered node correctly. This was really frustrating trying to select a node amongst many close neighbours.
The new approach uses the mouse x,y position and performs a hit test. Currently we do a dfs looking for the first deepest child that interests the mouse x,y. In a future diff we will extract a list when there are multiple candidates.
Hovered node was removed from react props since both the tree and visualisor depend on it meaning when hover state changes the whole app is rerendered. Instead we have moved hover state to an atom which is subscribed to by each visualsation node. Only if the old or new value matches the particular nodes id do we set state. The viz nodes were memo'd to prevent children renderning. The result is that for a hover change at most 2 nodes out of the 500 or so will rerender.
I attempted to do the same with the tree but it wasnt working with the controlled tree environment + focus state. The perf seems fine as is so will leave it for now
Reviewed By: lblasa
Differential Revision: D41218324
fbshipit-source-id: 7f80bcee256abad2689a88d7e209f92417aab672
Summary: This structure makes sense for the vizualiser which itself is a nested structure. It also saves the awkward branch of there is no key in the map.
Reviewed By: lblasa
Differential Revision: D40670371
fbshipit-source-id: 6c1b960a77749be9e8a193decf6b8d50ce6c7968
Summary: This makes life on the desktop easier as 99% of the time bounds were there but we were dealing with non sensical non null branches.
Reviewed By: lblasa
Differential Revision: D41218325
fbshipit-source-id: e490d3775720c1c55dcb8f4a2a85520294f5e2a9
Summary:
Not in all environments keytar is available, but still it will be useful to be able to login to intern with Flipper, even for temporarily sessions. This solution falls back to in memory storage.
Note that the underlying assuption is that multiple different users are not connected to the same Flipper server, as this would share their session!
https://fb.workplace.com/groups/flippersupport/permalink/1498550730625580/
Reviewed By: passy
Differential Revision: D41218132
fbshipit-source-id: 6e518d742df639bfbdc9a36ed1fa56ecb363a0b0
Summary:
We want to enable backing up and restoring debug settings between app installations.
Currently it is a manual process to click into menu and perform multiple operations.
With this feature, we can export and import shared preferences which will eliminate manual steps on devices.
Reviewed By: mweststrate
Differential Revision: D40987341
fbshipit-source-id: 15dd9600ee5cfd80a085117bdba4d434e4d2198f
Summary:
This diff adds support for layout and component props from Litho.
Notes:
- Each component could register a descriptor for itself.
Reviewed By: LukeDefeo
Differential Revision: D40680095
fbshipit-source-id: 57c78a199db58e05dd6dac4ed32ff6a869a73b0a
Summary: This change extracts most styles used across the inspector components and puts them in Styles.tsx
Reviewed By: passy
Differential Revision: D41026862
fbshipit-source-id: 461a78fb4a707d9a455281ec020bac95191ddfce
Summary:
Our descriptors currently have a method to return the name as it will be displayed on the elements hierarchy.
However, it doesn't provide enough context if the name is to be used to discover the type in our code base.
This change adds a qualified name method that can provide a more complete name which can indeed be used by the Open In IDE functionality, for example.
Reviewed By: passy
Differential Revision: D40936785
fbshipit-source-id: 790ae02b9ebf37501765c52a24307fcaaaf9c14d
Summary:
This change exposes the env variables via the FlipperLib interface used by plugins.
The variables are already white-listed and safe to be used by plugins according to documentation.
Reviewed By: antonk52
Differential Revision: D40852147
fbshipit-source-id: bbb3b052d33bf5cf75c81166af2400fe6a359256
Summary:
Before this change, attributes and attribute metadata were intermingled and sent as one unit via subtree update event.
This represented a few issues:
- Repetitiveness. For each declared and dynamic attribute, metadata was included on each value unit.
- Metadata can vary in size and thus can have a negative impact on payload size.
- The attribute name which is part of metadata is a string which always overhead on processing.
- Metadata instantiation is not cheap thus this also incurs in processing overhead i.e. even instantiating a single string can have an impact.
The proposal is to separate metadata of attributes from the actual node reported attributes. This solves the problems mentioned above.
Reviewed By: LukeDefeo
Differential Revision: D40674156
fbshipit-source-id: 0788551849fbce53065f819ba503e7e4afc03cc0
Summary: Doing this to get better logging in case we get transient failures again when fetching code snippets
Reviewed By: antonk52
Differential Revision: D41118788
fbshipit-source-id: f6cb9e20a08920f5935b14d765ac4c053ac5c78f
Summary: On older Android devices (API 24) `-printf ` is not available
Reviewed By: lblasa
Differential Revision: D40980640
fbshipit-source-id: d1a1bcadc496deaf3d514c1e45b2e0104a937b18
Summary:
Logging data for this event turnslogs into unreadable mess
{F789339377}
Reviewed By: lblasa
Differential Revision: D40978819
fbshipit-source-id: ac0894b2a490aa902180c50e7712b168211c7013
Summary: FlipperServerClient can use any socket to transfer the data. Since we do not control the socket, we cannot guarantee what comes out of it (hello, Jest E2E tunnel!). We need to handle unexpected messages gracefully.
Reviewed By: passy
Differential Revision: D40891384
fbshipit-source-id: 6f873037aa49bac3fc4c09fa49483cdec537ae40
Summary: Remove `window` reference to use flipper-server-client in NodeJS context (windows is not defined there)
Reviewed By: passy
Differential Revision: D40859805
fbshipit-source-id: 23415f9d504e4dbba4035b942c73add86edf02de
Summary: Re-expose one of the legacy exports we had before. Requested by MSYS
Reviewed By: passy
Differential Revision: D40979328
fbshipit-source-id: 7e8f089a182a62f392f3a720bee9b81698930f9d
Summary:
FlipperServerClient is a useful abstraction for any JS-based client of headless Flipper. No need to bundle it with flipper-frontend-core, as the rest is not useful for external clients.
Currently, I am planning to add it to jest-e2e to send commands to Flipper
Reviewed By: lblasa
Differential Revision: D40765668
fbshipit-source-id: af48710bb15444ac1ecd649fe9a2ab252f3088f3
Summary:
Flipper plugins fail when importing css from third-party dependencies. This diff tries to fix that.
Effectively, the plugin can import the css and export it when is bundled.
When we load the plugin, we check if there's a css file for it. If there's one, we return it and try to use it.
Reviewed By: aigoncharov
Differential Revision: D40758178
fbshipit-source-id: e53afffcc481504905d5eeb1aea1f9114ee2a86b
Summary:
This is an automated PR to update the Podfile.lock.
- Make sure that the Podfile.lock contains latest FlipperKit and Flipper pod versions.
- Also make sure that all the dependencies are updated to the latest one.
- This is auto-generated by [create-pull-request](https://github.com/peter-evans/create-pull-request)
Pull Request resolved: https://github.com/facebook/flipper/pull/4271
Reviewed By: passy
Differential Revision: D40755392
Pulled By: aigoncharov
fbshipit-source-id: f296fe36535ff8744ddee6b6f9d2575d71c429f9
