Summary:
I'm removing an ill-informed "optimization" that resulted in some StateUpdates being dropped. For some components (including TextInput) we rely on State updates to request a layout from the ShadowNode layer.
In the past we were performing an optimization that didn't update the View layer if the data contained in the State container is identical, but in the case of TextInput and other components, we simply pass an opaque
object with no meaningful data to trigger the layouts. In those cases, it could cause a permanent rift between the View layer's StateWrapper and the most recent state object from the C++ perspective.
In the case of TextInput this didn't cause tangible bugs because you can always update state using an out-of-date State object, but it's better this way anyway.
The other issue is that for some components, we want to know when there's a State update from the Cxx layer. This optimization broke certain logic in those components.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23306222
fbshipit-source-id: 8ef83149b814de50776674b5fd22406be1db14ba
Summary:
# What is this?
For a very long time, we've discussed the possibility of detecting Node Reparenting in the Fabric Differ. Practically, from the developer perspective, ReactJS and React Native do not allow reparenting: nodes cannot be reparented, only deleted and then recreated with entirely new tags.
However, Fabric introduced the idea of View Flattening where views deemed unnecessary would be removed from the View hierarchy entirely. This is great and improves memory usage, except for one issue: if a View becomes unflattened, or becomes flattened, the entire tree underneath it must be rebuilt.
In a past diff we introduced a mechanism to detect sibling reordering cleverly, and produce a minimal instruction set. This diff is very similar: we know the invariants around flattening and unflattening of views and we take advantage of them to produce an optimal set of instructions efficiently.
# What's different from previous attempts?
No global maps! Those are slow!
This seems to work and (hopefully) might even improve performance, since way less work is being done on the UI thread in cases when views are (un)flattened.
This *only* does extra work when flattening/unflattening happens, which gives product engineers a little more control over perf.
# So, how's it work?
This algorithm is intuitively simple (I think) but tricky to pull off, because there are lots of edge-cases.
In short: In the past, that information was hidden from the Differ: the differ didn't know if views were being reparented, it would see them
as entirely new views or as views being deleted if a View was flattened or unflattened. We very subtly change the information given to the differ:
all nodes are visible to the differ, but marked as Flattened or Unflattened. Thus, when the differ compares two nodes in the "old" and "new" tree,
it can tell not just if there are updates to the node but if it has been unflattened or flattened as well.
For example, take this tree, where * indicates that a View is flattened:
```
A
+
+----+---+
B* X
+ +
| |
+---+--+ +
E F Y
```
When the Differ asks for the children of A, in the past it would get a list `[E, F, X]`. That is, B* and X are both its children, but since B is flattened, it is omitted entirely from the list and
its children are substituted.
Now, when the Differ asks for the children of A, we give it this list instead: `[B*, E, F, X]`. That is: we give it a list which includes B, but B is marked as flattened.
Another wrinkle: A node `X` could have its children flattened, but still be a concrete view: so flattening/unflattening is a different operation from making a view "concrete" or "unconcrete", which can change independently of flattening.
There is one additional wrinkle: because of zIndex/stacking order, the children of `B` might not actually appear after `B` in the list. Depending on zIndex, a tree that looks like this:
```
A
+
+------+------+
B* C*
+ +
| |
+--+--+ +--+--+
D E F G
```
Could actually be linearized as: `[D G B* F C* E]` (as an extreme example; but basically all permutations as possible).
This is the reason, and the *only* reason that the inner Flattener/Unflattener
## The cases we need to handle
There are 7 cases/edge-cases of flattening and unflattening that we need to handle. Practically, all cases of reordering + flattening/unflattening, and taking recursive cases into account:
1. View A and A' (A in the old tree, A' in the new tree) are matched in the differ, and A* has been flattened or unflattened. These two cases are the easiest to handle.
2. View A' has been reordered with its siblings, and has been flattened or unflattened. These cases are slightly trickier to handle.
3. While flattening or unflattening, we encounter a child that has also been unflattened or flattened. So we need to handle four cases here in total: Flatten-Flatten, Flatten-Unflatten, Unflatten-Flatten, and Unflatten-Unflatten.
Other things to think about, also covered above:
1. Ordering. Views can be reordered and flattened/unflattened at the same time.
2. zIndex ordering: children in a certain order from the ShadowNode perspective may be stacked differently from a View perspective. We use the zIndex ordering for everything in the differ, and this prevents us from performing certain optimizations (see above: we cannot assume that children come after their parent in a list; they may come before, may be interwoven with children from other parents, etc).
# Perf Implications?
Practically, there should be very little negative overhead. There is some overhead in actually performing a flattening/unflattening operation, but... not much more than before. We don't use global maps, so the cost of flattening/unflattening is basically `O(number of nodes reparented)` - note that that's direct nodes reparented, *not* descendants.
tl;dr the perf hit should be similar to reordering, which is non-zero, but close to zero, and zero-cost for any diff operations on parts of the tree that don't involve flattening/unflattening. AFAICT this is very close to an ideal solution for that reason (but I wish it was simpler overall).
# In Summary?
I hope this works out and I think it could improve a number of things downstream: perf, LayoutAnimations, Bindings, certain crashes because of platform assumptions about mutations, etc.
Is it worth it? This new implementation is substantially harder to reason about, harder to read, and harder to understand. This is an important consideration. All I can say there is that I trust the test suite I've been using, but
the decreased readability is a big negative. Hopefully we can improve this in the future.
The rest is fiddly implementation details that I sincerely hope can be improved and simplified in the future.
# Followups?
The part that makes this algorithm the most expensive is that because of zIndex ordering, we cannot assume that children are linearized after their parents and so we rely more heavily on maps for the flattening/unflattening. Our TinyMap implementation should make these `find` operations fast enough unless trees' children are constantly being reordered, but it's still worth thinking of ways to make this even faster.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D23259341
fbshipit-source-id: 35d9b90caf262d601a31996ea2cb37e329c61ffc
Summary:
Simplify the TextInput measurement mechanism.
Now, data only flows from JS->C++->Java and from Java->JS. C++ passes along AttributedStrings from JS if JS updates, and otherwise Java maintains the only source of truth.
Previously we tried to keep all three in sync. This was complicated, slow, and even lead to some crashes.
This feels a bit hacky but I believe it's the simplest way to achieve this short-term. Ideally, we would use something like `AttributedStringBox` and pass that to State from Java,
but currently everything passed through the State system from Java must be serializable as `folly::dynamic`. So, instead, we just cache one Spannable per TextInput component and
use ReactTag as the cache identifier for lookup.
An interesting side-effect is that `measure` could race with TextInput updates, but the race condition favors measuring the latest text, not outdated values.
Followups:
- Can we do this without copying the EditText Spannable on every keystroke? Maybe this approach is too aggressive, but I don't want a background thread measuring a Spannable as it's being mutated.
- Do we need to support measuring Attachments?
- How can we clean up this API? It should work for now, but feels a little hacky.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23290230
fbshipit-source-id: 832d2f397d30dfb17b77958af970d9c52a37e88b
Summary:
In MountingManager.java in Fabric, if we drop a view with any attached views, we also drop all children. If verbose logging is turned on, log all instances of that happening.
This has no impact unless you switch the flag on manually in debug mode.
Changelog: [Internal]
Differential Revision: D23257749
fbshipit-source-id: fce4476aa47cc1b7137cd9fd2fd0241af1593288
Summary:
This diff updates the directory hierarchy of AndroidTextInput C++ files to be compatible with Android OSS build system
changelog: [internal] Internal
Reviewed By: PeteTheHeat
Differential Revision: D23179390
fbshipit-source-id: 1c52e4f882853799a58d44876cadd392b4a35050
Summary:
This comment shouldn't be committed, and should just be part of the template that generates new BUCK files.
Changelog: [Internal]
Differential Revision: D23225700
fbshipit-source-id: a1728e1a4ac0f3f94c4d1330d489bfae7a76a82d
Summary:
This diff filters the iOS C++ friles that are generated by the oss-android-codegen script
Also, as part of this diff I'm inlcuding .cpp files into the output.
These files are only used and compiled in Android
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23169268
fbshipit-source-id: 404607f3cd6e59197291ea67701774c9c492a282
Summary:
Twilight doesn't have TMPerfLogging enabled. However, the TurboModule infra uses the TMPerfLogger java class everywhere, which loads the turbomodulejsijni library on class load. For some reason, this class load doesn't work, and causes Twilight prod to crash.
To mitigate that crash, this diff delays the so load until it's absolutely necessary, which is by the time we call jniEnableCppLogging. This should never be called in Twilight, because it doesn't have TMPerfLogging enabled. Therefore, the crash should disappear on Twilight.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23192072
fbshipit-source-id: b73ece580e4345dbf835b0fc2f7d43b90f202411
Summary:
This diff extends test-react-native-oss-android-legocastle to test the build of RNTester with fabric enabled in Sandcastle
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23141524
fbshipit-source-id: 396dae1c0a23ce03db1053de1627eacb09a6df94
Summary:
This diff reintroduces the CoreComponentsRegistry class to register core components in the RN Tester app.
This class was previously deleted as part of D23091020 (https://github.com/facebook/react-native/commit/7fb1afae7f4b78970463e272b7d4f3230e84887d). Different from a past approach, this diff doesn't use inheritance for Hybrid classes (which seems to bring problems in Android 4 devices)
I'm planning to land this diff after I verify that D23091020 (https://github.com/facebook/react-native/commit/7fb1afae7f4b78970463e272b7d4f3230e84887d) fixed RC (maybe I will wait until sunday's cut)
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23109856
fbshipit-source-id: 5220e522e197f701c782ab5089f9f1036ec90c19
Summary:
This diff removes the CoreComponentsRegistry class that was recently created to expose Fabric components in OSS
changelog: [internal] internal
Reviewed By: JoshuaGross, shergin
Differential Revision: D23091020
fbshipit-source-id: 9d851608ed0eddb98367265b5e346d5298f5f732
Summary:
This diff adds a new mechanism to enable or disable the build of Fabric in RN OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23084586
fbshipit-source-id: b7b0b842486392ec4ccb91ad1e6441ba3a1f48b2
Summary:
In the past I tried a few heuristics to guess when a batch of Animated Operations were ready, and none of these were super reliable. But it turns out we can safely allow JS to manage that explicitly.
Non-Fabric still uses the old behavior which seems fine.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23010844
fbshipit-source-id: 4c688d3a61460118557a4971e549ec7457f3eb8f
Summary:
This diff extends fabric module to compile in OSS
NOTE: As a side effect of this diff, Fabric will be included into "reactnativejni" which is used by RN OSS.
I'm planning to remove this dependency in the near future - T71320460
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22991877
fbshipit-source-id: 0ab3ee410dd448bbd87130114bec27c6e6bc65c6
Summary:
This diff introduces the class CoreComponentsRegistry that is responsible of registering core components in fabric.
This is required to make RN Tester to work in Fabric, in the future we'll extract this registry into another module (once we figure it out what's the best way to do this)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22991876
fbshipit-source-id: 15e85e15aac5dd981161d9eae35eb2cee4fa66b6
Summary:
This diff refactors the ComponentFactoryDelegate class. It also introduces a new class called ComponentRegistry that will be used to register components into fabric
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22985313
fbshipit-source-id: e33a3d4fcb3a1c509b80c6ff1f43889480b1c2c3
Summary:
This diff extends the 'textlayoutmanager' module to compile in OSS
As part of this diff I also moved Android files in order to make the module compatible with Android.mk system
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22963706
fbshipit-source-id: 14a7309f589fe12c21131c7d5cef02b4323d4a93
Summary:
This diff refactors the class Runnable into a struct to make it work in OSS
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22963704
fbshipit-source-id: 2212c8f1e4a62b2bcad5c061709e29b247454fc1
Betty Ni
Joshua Gross
David Vacca
Sahil Jain
Ramanpreet Nara
Jiawei Lv
Oleg Lokhvitsky