Summary:
All code styles are terribly ugly. We have the only choise - choise something and embrace it.
This particular code style was borrowed from a neibour Fabric-friendly project because it follows established Facebook guides and respects client-side traditions.
Reviewed By: mdvacca
Differential Revision: D10218598
fbshipit-source-id: 8c4cf6713c07768566dadef479191661c79988f0
Summary: That should save us some app size kilobytes.
Reviewed By: mdvacca
Differential Revision: D10081499
fbshipit-source-id: 2b950768c609b412f9be332c22b6b1e96657e5ea
Summary: This diff introduces the concept of Local Data in Android Fabric C++ and as an example we uses it to implement Text View.
Reviewed By: shergin
Differential Revision: D9583970
fbshipit-source-id: ab7478b16ef4327ff574ca1467870ab9cb684ea0
Summary: In this diff I added support to be able to measure C++ shadowNode in Android. As an example I implemented the measurement of TextViews
Reviewed By: shergin
Differential Revision: D9583972
fbshipit-source-id: 1344782d4c586c94a4576b18a4acfa4775e46952
Summary: This diff introduces a way to convert ParagraphLocalData object to dynamic objects
Reviewed By: shergin
Differential Revision: D9801892
fbshipit-source-id: e50217042a216ea67f28178bb80b136cbb8fb195
Summary:
The source of truth has already moved, so now we just need to fix references
This diff is mostly the result of running:
```
$ tools/mobile-unification/loadmod --fixup xplat/configurations/buck/apple/flag_defs.bzl tools/build_defs/apple/
```
Then I committed with `hg commit -I xplat/`
The controller you requested could not be found.
Differential Revision: D9772194
fbshipit-source-id: 93d23ae8e1c62440c7876cad965d963bde960db9
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
I was watching a classic magnificent talk about modern C++ by Herb Sutter and I was totally sold on double down on using `auto` in our codebase. Surprisingly, 95% of the code base already follows Herb's guidence; I just changed the last 5% to make it consistent.
All those changes must work *exactly* like it was before.
The talk: https://youtu.be/xnqTKD8uD64?t=28m25s
Reviewed By: mdvacca
Differential Revision: D9753301
fbshipit-source-id: 9629aa485a5d6e51806cc96306c297284d4f90b8
Summary:
This diff includes two changes:
1. `TextShadowNode` represents virtual texts. For the time being, virtual text nodes only need touch capabilities so that they can handle `onPress` events for their children. Therefore, we should set the `TextShadowNode`'s `EventEmitterT` to `TouchEventEmitter`.
2. Since `ParagraphShadowNode` extends an instance of the `ConcreteViewShadowNode` template, it automatically uses the `ViewEventEmitter` if no event emitter is specified. I think it's better to make the event emitter explicitly specified. So, I've included that change in this diff.
Reviewed By: shergin
Differential Revision: D9696906
fbshipit-source-id: ac053ffdde4c2fbc6351f177c07a2ada4445cbb8
Summary:
When a user clicks on some text, `RCTSurfaceTouchHandler` will call into a method on `RCTParagraphComponentView`. That method (i.e: `touchEventEmitter`) would be responsible for identifying the closest ancestral `<Text/>` component to which we should dispatch the `onPress` event, given the point where the user clicked. To answer this query, we'll use a data structure called `UIAttributedString`.
This data structure represents a string, and a corresponding mapping from sequences of its characters to some arbitrary data. In this attributed string, we'll map sequences of characters to their closest ancestral `ParagraphShadowNode` or `TextShadowNode`. That way, when we get a click event on `RCTParagraphComponentView`, we can just look at the character that was clicked, and use that information to do a lookup in the attributed string to find the shadow node who's EventEmitter is responsible for processing the click event.
Reviewed By: shergin
Differential Revision: D9696904
fbshipit-source-id: a199649981ad271afa85414ce4c3f056851348be
Summary: Previously, `BaseTextShadowNode::getAttributedString` used to recurse on a list of `SharedShadowNode`s (i.e: the children). In the `RawText` base case of this recursion, we'll need to record the parent of the current `RawText` (so that we can dispatch the `onPress` event to it). Therefore, we need to start recursing using the `SharedShadowNode` itself, and not its children.
Reviewed By: shergin
Differential Revision: D9696908
fbshipit-source-id: dbf3f9c21a7ae4de421d0355c4e5900b3947dc2a
Summary: Unused loads hurt readability and take time to process.
Reviewed By: hramos
Differential Revision: D9494120
fbshipit-source-id: 455b56efadab1cb976344cffcb427772bfda2f71
Summary:
@public
Previously, all ConcreteShadowNode subclasses had to override `getComponentName()` function to specialize a name of the component. And often it was all that those subclasses do. Now, it's a template argument; and many ShadowNode classes can be created as oneliners via *just* specializing ConcreteShadowNode template.
Unfortunately, C++ does not allow to use `std::string`s or string literals as template arguments, but it allows to use pointers. Moreover, those pointers must point to some linked data, hence, those values must be declared in .cpp (not .h) files. For simplicity, we put those constants in Props classes, (but this is not a strong requirement).
Reviewed By: mdvacca
Differential Revision: D8942826
fbshipit-source-id: 4fd517e2485eb8f8c20a51df9b3496941856d8a5
