Files
react-native/ReactAndroid/src/main/java/com/facebook/react/flat
Cory Reed d2f0abdf4e Fix Android comment and docblock typos
Summary:
👋 Hello! Thanks for react-native, it’s a great project.

I was digging into the Android implementation in _ReactAndroid_ and noticed a couple typos in the documentation. I went through and tried to fix all the typos I could find using [aspell](http://aspell.net).

Not applicable: these changes are only to comments, and CI should be skipped.

[ANDROID][ENHANCEMENT][*] - Correct comment and docblock typos
Closes https://github.com/facebook/react-native/pull/17049

Differential Revision: D6472182

Pulled By: shergin

fbshipit-source-id: 7e62cab118609596b483d1cf16c3abf651d6753b
2017-12-03 20:16:36 -08:00
..
2016-12-19 13:40:28 -08:00
2016-12-19 16:58:30 -08:00

Nodes

Nodes is an experimental, alternate version of UIImplementation for ReactNative on Android. It has two main advantages over the existing UIImplementation:

  1. Support for overflow:visible on Android.
  2. More efficient generation of view hierarchies.

The intention is to ultimately replace the existing UIImplementation on Android with Nodes (after all the issues are ironed out).

How to test

In a subclass of ReactNativeHost, add this:

@Override
protected UIImplementationProvider getUIImplementationProvider() {
  return new FlatUIImplementationProvider();
}

How it Works

The existing UIImplementation maps all non-layout tags to Views (resulting in an almost 1:1 mapping of tags to Views, with the exception of some optimizations for layout only tags that don't draw content). Nodes, on the other hand, maps react tags to a set of DrawCommands. In other words, an <image> tag will often be mapped to a Drawable instead of an ImageView and a <text> tag will be mapped to a Layout instead of a TextView. This helps flatten the resulting View hierarchy.

There are situations where DrawCommands are promoted to Views:

  1. Existing Android components that are wrapped by React Native (for example, ViewPager, ScrollView, etc).
  2. When using a View is more optimal (for example, opacity, to avoid unnecessary invalidations).
  3. To facilitate the implementation of certain features (accessibility, transforms, etc).

This means that existing custom ViewManagers should continue to work as they did with the existing UIImplementation.

Limitations and Known Issues

  • LayoutAnimations are not yet supported
  • zIndex is not yet supported