Summary:
I created a separate folder under src called facedbook, which
1. isnt synced to github
2. isnt build by gradle
I also needed to exclude the file with the duplicate symbol from buck. I seemed to have to move both the src/facebook and src/main under one buck file to get the exclude to work
Reviewed By: lblasa
Differential Revision: D41612114
fbshipit-source-id: a8386e1b1eabdeca2a800d98d8732b2ca694836b
Summary:
This is temporary solution to get to parity with the old plugin. In future would like to make this more flexible on the desktop side
Additionally getData was renamed to getAttributes for consistency
Reviewed By: lblasa
Differential Revision: D41845248
fbshipit-source-id: 50e94a7712f5d42938229134e212cef5d379475d
Summary:
Although conceptually it made sense, it creates an issue with registration.
### Let me explain
Effectively, as an engineer, what constitutes static and dynamic metadata and how can I ensure that is treated as such?
It may be trivial to answer those questions but there was a fundamental assumption for static metadata that no longer holds true. Static metadata was registered when descriptors were first referenced, which most of the times happens when added to the descriptors registry.
This used worked fine until we introduced the concept of deferred attributes.
Deferred attributes, even though static, may register its metadata only when requested to.
The issue is even more fundamental as not all the objects that declare static metadata will be loaded into memory by the time the plugin is connected and sends this.
### Solution
To simplify, as the concept was never really used, there's only metadata.
There's only pending metadata which is metadata that is yet to be sent to Flipper Desktop.
Reviewed By: LukeDefeo
Differential Revision: D41614186
fbshipit-source-id: 85d62eeff81ff22ae6e969d7b5aed8628b336258
Summary: Global Id is stable as the component is rerendered. It is not stable if the whole component tree updates so we might want to deal with this in the future
Reviewed By: lblasa
Differential Revision: D41581346
fbshipit-source-id: 0c2834ba452ddcfc3e0a7392672825fc040901d9
Summary:
Attributes Inspector didn't have support for inspectable arrays.
This change addresses an issue with the inspectable itself and adds basic support to it in the visualiser.
Reviewed By: LukeDefeo
Differential Revision: D41522879
fbshipit-source-id: f9cad42470541039c8157477b0fe9bc58f18f1ba
Summary: Due to litho component instances being immutable we are able to process them later if we hold on to the instance. We have added a Maybe deferred type which sort of resembles a Monad. It wraps a value which may or may not be calculated later.
Reviewed By: lblasa
Differential Revision: D41474251
fbshipit-source-id: 2ba6e688518dba55cf4aa5ba53f390a92cf0921f
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:
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:
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:
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: 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:
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:
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:
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:
There are some situatuins where a litho view can move without a mount occuring in that view. One situation is a litho view in a recycler view. If a neighbouring view is deleted or changes its width/height this will shift the whole recycler view. Since each view in the recycler view is typically a separate comonent tree. The children of the recycler view are not aware of their siblings changes through mount. And these situations do not count as a scroll which was the previous method of detecting change.
This is a work around to listen to on draw which seems to be fired in all situations.
Reviewed By: lblasa
Differential Revision: D40430777
fbshipit-source-id: a9c8196f31a6bdfd4a2fed398cfcaed190972959
Summary:
Initial implementation of Litho extensions using mount extension. After mount is called on the main thread and we traverse the hierachy. In future we can use mount extensions to construct a sparse tree rather than sending everything every time.
Scroll is handled with a native UI scroll listener for each litho view. This may break if the litho view is not a direct child of the scroll view.
Reviewed By: mihaelao
Differential Revision: D40021840
fbshipit-source-id: b09086a7a16660225885620609009dddf5b90d3b
Summary: Getting the boxes to line up is quite hard to do right and has undetermined value
Reviewed By: mihaelao
Differential Revision: D40430776
fbshipit-source-id: 6093c4874f39ecf0c673407da2bd03ef06ca017e
Summary:
This change adds support for more inspectables and also introduces more complex types to be used as a value.
This become specially useful for more complex yet primitive types like coordinate, size, bounds, etc.
Reviewed By: LukeDefeo
Differential Revision: D40307885
fbshipit-source-id: 125e832f06d6b31f56eb5405182d1c0d61388930
Summary: Moved to separate directory. These additional descriptors are useful for debugging the implementation but might not be useful for the end users so could potentially be removed down the road
Reviewed By: lblasa
Differential Revision: D40021834
fbshipit-source-id: f88c1186dd65cdabc816d5cd8256bb81c404a80c
Summary: There are other situations where we want to overide the offset than for litho mounted views
Reviewed By: lblasa
Differential Revision: D40021833
fbshipit-source-id: 1411a4a67e88f6893bb38e36fb6a81eead3edd1a
Summary:
DecorView owns a BitmapPool to take snapshots of the view. These snapshots are later on serialised by the manager.
There's a couple of unrelated changes in this diff but that were already in place making it hard to split.
(1) Renamed 'traverseAndSend' to 'processUpdate'. Why?
The observers as a whole shouldn't necessary know that their 'observation' is being sent to any place. Future changes should move the send logic altogether from the observer too. But that can be made within the scope of a different diff.
(2) There was a bug for nodes that were being observed but then unsubscribed from. If the nodes were being marked for observation and observer was already into place, these were not being told to subscribe again for changes.
Reviewed By: LukeDefeo
Differential Revision: D39812943
fbshipit-source-id: af98c5caf54e1c69f97043bae95049395a2e4545
Summary:
This change introduces a new Descriptor method to obtain snapshots of an item in the layout hierarchy.
Only implemented by the ViewDescritor but it can be potentially extended to Windows, Fragments, Activities, ...
Reviewed By: LukeDefeo
Differential Revision: D39690548
fbshipit-source-id: cf3a1ccd63eb28c1de328310e8635829a40964dd
Summary: It was always the system hash code and in many places it was inconvient to get the descriptor to just end up calling the same function
Reviewed By: lblasa
Differential Revision: D39700215
fbshipit-source-id: b1439d56cd8f39ba8735f933662ad79b87ffbdbe
Summary: We had an issue where the offset for a native view was effectively caclculated twice and summed, once by litho and once by android. Given the UI debugger expects a nodes bounds to be w.r.t its parent the android systems x,y offset is 'wrong' from ui debuggers perspective, we set it to 0,0 and rely on the calculated offsets by the litho component hierachy
Reviewed By: lblasa
Differential Revision: D39695663
fbshipit-source-id: d9c2be950fc68bc2286359a62746356e89299cfd
Summary: This is to support a future diff where we will draw a basic wireframe for debugging
Reviewed By: lblasa
Differential Revision: D39509407
fbshipit-source-id: d99fd6fe39404996a0ed944c10905331262fd0c6
Summary:
^
After this change lands, it is safe to remove most of the Stetho fragment support types.
Reviewed By: LukeDefeo
Differential Revision: D39460121
fbshipit-source-id: 0e7d4ce71e828ee7bc9c6e945b8fe27dbd6f08f8
Summary:
1. The base class descriptor was removed, this was given that we have chained descriptor there is no need for this anymore
2. The Base interface node descriptor no longer has a mutable list based api. You simply return a list. The mutable list based api was specifically to allow chaining and this quirk is isoltated to the chained descriptor
3. AbstractChainedDescriptor and ChainedDescriptor were merged
Reviewed By: lblasa
Differential Revision: D39496073
fbshipit-source-id: fb3ec629ec3b27f587bdbd0b323624a4bc4ebea3
Summary: Each observer was doing a similar job of traversing, and setting up child observers and its easy to not clean up child observers in some cases. This provides a helper utility for the common use case
Reviewed By: lblasa
Differential Revision: D39466930
fbshipit-source-id: e74ae5c3709297b73c020cd148a0485ac9fc0f8f
Summary: Added an initial litho Tree observer and descriptors, its quiet naive and will be improved in a future diff
Reviewed By: lblasa
Differential Revision: D39466931
fbshipit-source-id: 66a462882af2e585b9719ee2f61595449f99c5e5
Summary:
This removes Bintray/JCenter specific code and replaces it with a new plugin recommended by [Chris Banes](https://chris.banes.dev/publishing-to-maven-central/).
Pull Request resolved: https://github.com/facebook/flipper/pull/1914
Test Plan:
Manually uploaded as snapshot and full release, but with this setup still requires all sorts of manual setup, including GPG. Next PR will include automation for this.
CI here should also verify that I didn't split this diff up incorrectly.
Reviewed By: jknoxville
Differential Revision: D26367350
Pulled By: passy
fbshipit-source-id: faa6b488d6c95bc643d2f9328362e29fb4b05ded
Summary:
The current ownership and release model prevents cleanly releasing new versions of the plugin while the code is split between two repos.
This diff moves the flipper-litho plugin to the Litho repository. You'll find new releases as `litho-editor-flipper` that'll be reexported via gradle's `api` to the old artifact.
Reviewed By: colriot
Differential Revision: D23962234
fbshipit-source-id: 7884423342904219ae9b41632c6df90cda870798
Summary: FlipperEditor has migrated to `litho-editor-flipper`, so this diff fixes the dependency tree and deletes the file.
Reviewed By: muraziz
Differential Revision: D23380023
fbshipit-source-id: 75f5f037dc392194212fc156499f090c381999bd
Summary:
Adds a link to the Yoga playground atop all properties of Yoga-based views.
We could make the playground match the properties below if I figure out the hashing mechanism the website uses. This is a start.
Reviewed By: muraziz
Differential Revision: D23758538
fbshipit-source-id: 6a3f206914aa9962e55852df548f8026783506e9
Summary: This change removes the dependency of FlipperEditor from AndroidX, which prevents it from moving to the Litho repository
Reviewed By: Andrey-Mishanin
Differential Revision: D23475867
fbshipit-source-id: a330c676859ed9ce9a0ab186dd206310d2eccca5
Summary:
Related diff [CK]: D23243009
This diff adds support for a protocol for layout messages where the type is recursively encoded as:
```
{
kind: "type",
data: ???
}
```
The meat of the diff is on FlipperEditor.java, SetDataOperations.java and InspectorFlipperPlugin.java. The others are there just for a change on an interface.
We check if the message adheres to the new encoding, otherwise we fall back to the old behavior. If it's the new encoding, the message is traversed recursively flattening the types to EditorValue using the type hints provided.
Reviewed By: muraziz
Differential Revision: D23243009
fbshipit-source-id: 0f313455885930f3beaaadb66f3bf394f109ea23
Summary: Useful for next diffs: enables to detect whether we have LithoComponent or CKComponent
Reviewed By: adityasharat
Differential Revision: D23128972
fbshipit-source-id: b9aef358c1426df4f05213c42e43402e8cae984f
Summary:
Populate class name for Litho Sections.
See D22922106 (86cafb9e80) for reference
Reviewed By: adityasharat
Differential Revision: D22949896
fbshipit-source-id: d804971708cf8c8466dd74eda3e750957dc95fc9
Summary: Populate class name for Litho Components.
Reviewed By: adityasharat
Differential Revision: D22922106
fbshipit-source-id: e18b748e0e0bd6f511558124a28b4b58d217ded7
Summary:
This diff implements the integration between a Litho Editor and Flipper. It does so by converting the Editor format to FlipperObject, and then converting it back from FlipperDynamic.
This conversion works for both `State` and `Prop`. We already provide default implementations for primitive + wrapped types and String, so the functionality should match the existing one.
Reviewed By: passy, Katalune
Differential Revision: D22455220
fbshipit-source-id: f7f633765f3d997ce6de09d2c1277019e72c0802
