Summary:
Previously every single visualisation node would have jsx for a tooltip and would control its own tooltop. now we have the overlay we can have just one. this improves perf a bit and simplifies the code.
i also increased the delay slightly
Reviewed By: lblasa
Differential Revision: D46274098
fbshipit-source-id: cb8afbc4804c549da9abf33d69aaf190397f74c7
Summary:
The previous approach of setting some of the borders to be thicker and different colours was flakey, sometimes parts of the border would be cut off by a parent
With this approach we figure out the offset relative to the root of the visualiser, and draw a box that is definatley on top. It works much more reliably
Also fixed a couple of other niggles:
1. Can unselect when clicking again
2. Going into focus mode clears selection since your selection may not be in the focused area and there is a phantom box
Reviewed By: lblasa
Differential Revision: D46224034
fbshipit-source-id: 24bed8db38cddab796f786e7e0a4acfe7c6a9089
Summary:
Previously we used an overlay to indicated selected but this was kind of hard to see due to <1 opacity. I think this approach where we enchance the border is clearer.
Also we used border colour earlier to indicate type of node which i think was never obvious to the user. Given that nodes heavily overlap we should remove this design language
changelog: UIDebugger, improve selected and hover state of the visualiser
Reviewed By: antonk52
Differential Revision: D45737758
fbshipit-source-id: 5299043656787d6479cff6ec2b38cebe8417fd53
Summary: This feature is annoying and useless
Reviewed By: antonk52
Differential Revision: D45696921
fbshipit-source-id: 01c007d3e196a7511b940b7973bb8e6a880e27e5
Summary: This is purely a cosmetic change but more accurately reflects the nature of how we send data from device to desktop. Ie its always an entire frame rather than subtrees. This helps with correctness great Both ios and android are like this and have been for a while.
Reviewed By: lblasa
Differential Revision: D45080088
fbshipit-source-id: 8f68047056c4825b0b1dd89f26c7fa462e2ecb1b
Summary:
An issue was reported for the visualiser whereas there seemed to be some cropping taking place on the right hand side.
https://pxl.cl/2BhPT
The issue was the resizable panel and visualiser both were set with the same width.
The resizable panel was set as to have a gutter which was not taken into consideration, add this width to the panel width and that fixes the issue.
Also change box sizing model as to not affect the dimensions of the wireframe.
Reviewed By: LukeDefeo
Differential Revision: D44664377
fbshipit-source-id: e640af2090f7c3378e624626fe3ea5df631caa11
Summary:
Based on the stack trace in T145744183, `activeChildIdx` could point to a non-existent array element.
Previously, we used to:
1) Find the index of the activeChild in the non-filtered array of children
2) Filter the array
As a result, it could lead to some of the elements in the child array to be filtered and shifting activeChildIdx, making it invalid.
Now, we search activeChild in the already filtered array.
Reviewed By: LukeDefeo
Differential Revision: D44575170
fbshipit-source-id: 2cb9a0b24badc8509a859011694f77b048d93316
Summary:
Fixes https://fb.workplace.com/groups/443457641253219/permalink/522118536720462/
On android for some reason our display metrics for the application, activity and winow were smaller than the decor view. We were using the root view as the base static view for the visualiser with overflow hidden. Since it will slightly smaller than the decor view we were losing some of the lower pixels of the snapshot
The decor view is the one that is actually snapshot so any bounds for nodes above are meaningless . The fix is to simply have the visualiser start at the snapshot view. We know this bounds is correct.
Tested on ios and android and all looks ok
Reviewed By: lblasa
Differential Revision: D43356523
fbshipit-source-id: 4d6177c8242365f33b1d64fc149a10baff7c85d6
Summary:
For the visualiser we use the same trick as with the hover state. We subscribe to selection changes and only render if the prev or new state concerns us.
For the tree we change from object identity to the node id + and indent guide are added to the memoisation equal check.
Depending on teh change this tree memoisation can vary in effectiveness. If you go from nothing selecting to selecting the top element nothing is memoised since react needs to render every element to draw the indent guide. If you have somethign selected and select a nearby element the memoisation works well.
There are ways to improve this more down the road
changelog: UIDebugger improve performance of selecting nodes
Reviewed By: lblasa
Differential Revision: D43305979
fbshipit-source-id: 5d90e806ed7b6a8401e9968be398d4a67ed0c294
Summary:
Listen to framework events and store in a map based on node id
Added UI to allow for monitoring framework event types.
The event type is a string separated by : Each segment of this string represents a level in the dialog hierachy. For example Litho:Layout:StateUpdateSync would have levels, Litho Layout StateUpdateSync
When event type monitored and event comes in for a node flash the visualiser node briefly
Reviewed By: lblasa
Differential Revision: D42074988
fbshipit-source-id: 52458ad87ab84bf7b1749e87be516ed73106a6c0
Summary:
The root view resolver will always find all root views but there was a bug in the listrootviews method. The code was very complex and most of the code seemed to be unneeded. Its now working. The listrootviews method now just returns teh contents of the observable array.
The reason we needed this is that Certain activities dont seem to tracked by the listener we add to `registerActivityLifecycleCallbacks` Its as if there is a floating decor with no activity. One example in FB4a is clicking on a notification in the notifications panel
Reviewed By: lblasa
Differential Revision: D41522791
fbshipit-source-id: b49b0104ddf758f097e1fd3f9ac6588de2d3646e
Summary: With the previous approach it was hard to read the name of the node, this should be a lot clearer. The tool top comes in a after a delay, the reason for this is because when i tried without a delay when you moved the mouse fast a ton of tooltips would appear and disappear when you passed over diffferent nodes and it was very distracting. 200ms seems to be about the sweet spot
Reviewed By: lblasa
Differential Revision: D41548248
fbshipit-source-id: 76460347730d5b1d2e968984e845be0c65255456
Summary: Should be a bit easier to see what UI state we are holding at the plugin instance level
Reviewed By: lblasa
Differential Revision: D41498272
fbshipit-source-id: 6d88086766efd9c39f71be7e2ce32c5058494c96
Summary: We have to do a couple of odd things to get the context menu items to behave. The code was duplicated between tree and visualizer. This custom component removes duplication and makes the approach a bit clearer (via js doc)
Reviewed By: antonk52
Differential Revision: D41495718
fbshipit-source-id: ec98d5101e636a2c9034c656d29991d4fe348762
Summary: Added context menu to visualizer similar to what we have on the tree
Reviewed By: lblasa
Differential Revision: D41494948
fbshipit-source-id: 0cfa4c98b7a68462a7103ed1ce9eaaff8c99aeee
Summary: If a node has a global negative offset (e.g from a view pager) its position will be outside of the visualizors bounds and could potentially be where the tree is. The user doesnt see the wireframes since overflow hidden is on the parent node. A situation can arise where when the mouse is over the tree the hit test returns an offscreen node and causes us to hover a random node rather than the tree node hover effect taking place. We are just adding a guard to say if the mouse is outside the dom rect for the root visualization node than dont run the hit test
Reviewed By: lblasa
Differential Revision: D41493001
fbshipit-source-id: ea7974de7f2b80126d52490526a21e2a3b487d3d
Summary: Introduced an outer div which is the size of the real root node so that focusing doesnt shift the UI.
Reviewed By: antonk52
Differential Revision: D41492999
fbshipit-source-id: 336104e5d18d773953e0a58a699acc7660c4045f
Summary: In order to support focus mode we need to have only 1 snapshot. In practice this is the case but we are making this more apparant in this diff.
Reviewed By: lblasa
Differential Revision: D41493003
fbshipit-source-id: 19ed7213d15adaea4732f4ec60309efa8dae6f94
Summary:
There was an issue whereas snapshots were not properly rendered on retina devices.
After running a few tests, the issue seems to be solved by changing the snapshot format from jpeg to png.
Reviewed By: antonk52
Differential Revision: D41520939
fbshipit-source-id: 1563fe89162e41f71418357a7e58caaf46581f04
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 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:
Old hover state is now selection state
New hover state is a slightly thicker border
Reviewed By: lblasa
Differential Revision: D40637724
fbshipit-source-id: 7b13bc864bc1f626cf0982517befcb80615e7cc0
Summary:
Upgraded from ant tree library to the much more capable React complex tree. Added the following:
1. Ability to expand / collapse nodes while automatically expanding / collapsing active/inactive children when they change
2. Keyboard controls of tree all the time
3. Basic search functionality
4. Selecting node in tree focuses and scrolls in the tree
5. Hover state for tree
Reviewed By: lblasa
Differential Revision: D40633876
fbshipit-source-id: 8dcef5ec2c277e476a3eb3cdaef62b15c25323c0
Summary:
Clicking on a node a second time will unselect which was impossible before.
The behaviour of the on click handler doesnt always line up what is currently hovered, this is a temporary work around. There are deeper issues with this in that on exit we hover the parent, but in some situations the parent is too small to propagate. In future we will use the mouse position and do a hit test and drive selection / hover from that
Reviewed By: lblasa
Differential Revision: D40637356
fbshipit-source-id: 9df19dbf619845891bb46624730d7cf74f73cf25
Summary: This makes the vizualiser a lot less cluttered
Reviewed By: lblasa
Differential Revision: D40021837
fbshipit-source-id: 8901c9bff6f05ee3fa4517e103c770be1fcfa403
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:
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:
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
