Summary: Reverting D9304307 and also adding CountEnum annotation to ReactMarkerConstants. This way we get the typesafety of the enum with the optimization of converting to int in production builds. More on the count: https://our.intern.facebook.com/intern/wiki/Android-java-transforms/the-count/
Reviewed By: achen1
Differential Revision: D9623235
fbshipit-source-id: ab992e7edb6cf999f5f122faee31075a63782411
Summary:
@public
EdgeInsets and CornerInsets are now just qualifications of those generics:
using EdgeInsets = RectangleEdges<Float>;
using CornerInsets = RectangleCorners<Float>;
We will need more concrete types like that in the future diffs.
Reviewed By: mdvacca
Differential Revision: D9614428
fbshipit-source-id: e4d48a11d9083958c3ada68e6368afb150c64f6b
Summary:
@public
Previously, we amitted `default` argument in `convertRawProp` functions assuming that all default values are equal to results of their default constructors (which was something between "wrong" and "lucky coincidence"). Now we use a `YGStyle` default value as a source of all semantic default values of all layout props/styles.
Reviewed By: mdvacca
Differential Revision: D9626469
fbshipit-source-id: 5cfc9c518772556f59da46f608181145cc744928
Summary:
@public
Now it's clear that we don't need to store/handle ShadowTree objects as `shared_ptr`s; Scheduler should own it. This diff changes that to using unique_ptr and removes a base class of ShadowTree.
Reviewed By: mdvacca
Differential Revision: D9403567
fbshipit-source-id: 6e411714b632a04233fd5b25c8ab7cdd260105fd
Summary:
@public
Voalá, this small change actually implements view flattening. Obviously, it does not work right now because there are no `ShadowNode` classes which implement `isLayoutOnly`.
Surprisingly, correct implementing of `isLayoutOnly` is quite tricky, we will work on this in coming diffs.
Reviewed By: mdvacca
Differential Revision: D9403565
fbshipit-source-id: 1f16f912cb5c6841405a1fc3cf36aec28698c11f
Summary:
@public
This is quite a big diff but the actual meaningful change is simple: now we use ShadowView class instead of ShadowNode in mutation instructions.
Note:
* In some places (especially during diffing) we have to operate with ShadowNodeViewPair objects (which represents a pair of ShadowNode and ShadowView). The reason for that is that we cannot construct child ShadowViews from parent ShadowViews because they don't have any information about children.
* `ShadowTree::emitLayoutEvents` is now much simpler because ShadowView better represents the specifics of this kind of object.
* The code in RCTMountingManager also became simpler.
This change will allow us to implement more cool tricks soon.
Reviewed By: mdvacca
Differential Revision: D9403564
fbshipit-source-id: dbc7c61af250144d6c7335a01dc30df0005559a2
Summary:
@public
We need some another object like ShadowNode (but not ShadowNode) to represent an instance of the component in the mutation instructions. This is
the main motivation for introducing ShadowView.
Why not use ShadowNode? ShadowNode is designed to represent a node in ShadowTree, not be a part of a mutation instruction.
* ShadowNode exposes some APIs that should not be exposed to the mounting layer;
* ShadowNode is an immutable data structure, so we cannot mutate it in some way which can be meaningful for mounting;
* We should not add to ShadowNode any functionality which is needed only for mounting;
* ShadowNode is a bit more heavy object to share that it needs to be; it's exposed (embedded into Mutation) as a `shared_ptr` which is not optimal from the performance perspective;
* Retaining ShadowNode from mounting code can unnecessarily extend its lifetime which can negatively affect memory usage.
Reviewed By: mdvacca
Differential Revision: D9403562
fbshipit-source-id: 72ad81ed918157a62cd3d1a03261f14447649d0b
Summary:
@public
Trivial. Those operations are very useful in layout algorithms.
Reviewed By: mdvacca
Differential Revision: D9403566
fbshipit-source-id: e76967aaaac3a36bf6d3e7a468b5ae7769a4dcac
Summary: Unused loads hurt readability and take time to process.
Reviewed By: hramos
Differential Revision: D9494120
fbshipit-source-id: 455b56efadab1cb976344cffcb427772bfda2f71
Summary:
release method of local_ref and global_ref doesn't call deallocator, in fact, it leaves the caller responsible for deletion of the reference, while otherwise the reference is released on scope left.
Fixes#18292.
Pull Request resolved: https://github.com/facebook/react-native/pull/20913
Differential Revision: D9616237
Pulled By: hramos
fbshipit-source-id: 021aa3e4f039e6b7a98da3e4224c1ee49d5a4921
Summary: Add native android nav bar. Title and button info are from FBDynamicNavigationOption. Set through setBarOption.
Reviewed By: achen1
Differential Revision: D9367058
fbshipit-source-id: 0f3f790d2c4d3af97568927993964678bc028bc3
Summary:
Use GitHub PR Reviews instead of individual comments. The result is similar to the existing implementation, but there will be a top level comment indicating possible next steps for the PR author.
Verified on Circle.
Pull Request resolved: https://github.com/facebook/react-native/pull/20927
Differential Revision: D9596595
Pulled By: hramos
fbshipit-source-id: 3628b0097aa9a21a40089f2cbe1859bd64ccd8b7
Summary:
This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest.
For example, React Native Dom would have an entry like:
```json
{
"rnpm": {
"haste": {
"providesModuleNodeModules": [
"react-native-dom"
],
"platforms": [
"dom"
]
}
}
}
```
Support for more keys (path blacklists perhaps?) could be added in the future.
This succeeds #20662, as per a discussion I had with matthargett.
I've got an open discussion over here as well: https://github.com/react-native-community/discussions-and-proposals/issues/21
Pull Request resolved: https://github.com/facebook/react-native/pull/20825
Differential Revision: D9596429
Pulled By: hramos
fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Summary: A cell syntax load crept into RN. Remove it so it works with oss
Reviewed By: scottrice
Differential Revision: D9596187
fbshipit-source-id: 1f3138b760f63ae4b1fa23a034e6b9a86396ff50
Summary: Added `snapToStart` and `snapToEnd` props to ScrollView which work together with `snapToOffsets` and determine whether the beginning and end of the list automatically count as snap offsets or not. If not, the list is allowed to free-scroll between its start/end and the first/last snap offset.
Reviewed By: sahrens
Differential Revision: D9442386
fbshipit-source-id: 47a5fdb20f884542434b01b1f0a486ed2b478c6e
Summary:
* Added snapToOffsets prop to ScrollView. Allows snapping at arbitrary points.
* Fixed pagingEnabled not being overridden by snapToInterval on iOS.
* Fixed Android *requiring* pagingEnabled to be defined alongside snapToInterval.
* Added support for decelerationRate on Android.
* Fixed snapping implementation. It was not calculating end position correctly at all (velocity is not a linear offset).
* Resolves https://github.com/facebook/react-native/issues/20155
* Added support for new content being added during scroll (mirrors existing functionality in vertical ScrollView).
* Added support for snapToInterval.
* Resolves https://github.com/facebook/react-native/issues/19552
Reviewed By: yungsters
Differential Revision: D9405703
fbshipit-source-id: b3c367b8079e6810794b0165dfdbcff4abff2eda
Summary: Splitting this into a separate diff for OSS
Reviewed By: yungsters
Differential Revision: D9551085
fbshipit-source-id: 8ca08351c6b89cd0011aab3c47ef6cc28b763450
Summary: Exposes a bool in the config which will help log the yoga hierarchy. Also added a test case
Reviewed By: IanChilds
Differential Revision: D9560577
fbshipit-source-id: ef4998107ed51ea374853bab7cbe09e3232caa0c
Summary: This diff fixes a couple of edge cases that caused Metro to keep the process running when there were some specific errors (specially around the `dependencies` command and the transformer path).
Reviewed By: jrwats
Differential Revision: D9551834
fbshipit-source-id: 959cefcec9e2687dff89c94a871ae74c50d2dd77
Summary:
Makes a couple improvements to `ViewPropTypes`.
- Remove deprecated transform props. We are now using exact object types, so they are already disallowed.
- Remove garbage types for `accessibilityLabel`.
Reviewed By: TheSavior
Differential Revision: D9542088
fbshipit-source-id: f9128353e19cff22caf52c896c9c137f01aea276
Summary:
To be able to test out new approach for NativeModules, introduce a simple runtime flag to enable the new system (doesn't exist yet). In addition, each module should declare a static `+ (BOOL)allowJSIBinding` in the objc class to be considered for the new approach. Doing so skips the processing of the module during bridge startup.
Note: this doesn't do anything special for `- (NSArray *)extraModulesForBridge:(RCTBridge *)bridge` impl yet.
Differential Revision: D9554296
fbshipit-source-id: 3508db6589e9f72367f62aa7ca15fce3d3adda72
Summary: This diff reverts the changes in the name for AndroidHorizontalScrollView and AndroidHorizontalScrollContentView that caused a redbox for continuous OTA users
Reviewed By: fkgozali
Differential Revision: D9561972
fbshipit-source-id: 3d8e9ee8bb6081107bc8d315af16885bb003148e
Summary: And migrated ReactRootViewTestCase to use ReactNativeTestRule.
Reviewed By: mdvacca
Differential Revision: D9557362
fbshipit-source-id: 1469d0ad8c125b5ea729371d81956e61780c56cf
Summary: Now that babel7 is stable, we can upgrade Metro and fbsource to use it, yay!!!!!
Reviewed By: mjesun
Differential Revision: D9518571
fbshipit-source-id: c85569cb3058235f4f9310949897f7955ecf7324
Summary: It's unclear if this was a recent regression or not (too lazy to find out), but instrumentation tests are failing because FrescoModule is never initialized (see task for trace). Based on the initial introduction of this class (D2448321) it appears that FrescoModule was always intended to be initialized on startup. Let's eagerly init Fresco in that case.
Reviewed By: fkgozali
Differential Revision: D9556864
fbshipit-source-id: 0b670dec46f5087b3794330931ddf5d7782c8367
Summary: This diff updates the size of RootShadowNode and re-render RN views when the Size of the Android React View changes
Reviewed By: achen1
Differential Revision: D9173758
fbshipit-source-id: 7cc6bbfb646025c3ec1773ab041eb9207623af71
Summary: This diff implements the HorizontalScrollView component for Android Fabric C++, as part of this diff I also re-named the components AndroidHorizontalScrollContentView for RCTAndroidHorizontalScrollContentView and AndroidHorizontalScrollView for RCTAndroidHorizontalScrollView. This might sound against our plan of removing the RCT preffix, but it is to make it simpler to map components between current implementation of RN and Fabric (otherwise we don't know when to add the RCT preffix in Android side to find the right View Manager), later we can just remove the preffix from C++, Android, iOS and JS.
Reviewed By: shergin, achen1
Differential Revision: D9122729
fbshipit-source-id: e9299552857c6dd0c18abfa5fa49a3d50e221729
Summary: D9070810 introduced a breaking change, making the `--transformer` CLI argument able to override the generic transformer instead of `babelTransformer`. Since we still have some scripts that assume `--transformer` is being used for overriding the babelTransformer path, we cannot do this breaking change yet, so this diff reverts the CLI handling to the old behaviour.
Reviewed By: jrwats
Differential Revision: D9550157
fbshipit-source-id: 8b4e26fcb5bca6e4b2f63b1e1a014bce23a31452
Summary:
The full idea for eagerly creating Native Modules is articulated here https://fb.quip.com/vWcLAup3a6kR
TLDR:
1) Move lazy native module work from the mqt_js thread to the background thread which processes packages. This also moves it from post-network to pre-network.
2) For a quick test, decide which modules to eagerly create with a QE flag.
3) Eagerly create the modules by opting-out of the ReactModuleInfo pipeline which was built for lazy native modules.
Reviewed By: achen1
Differential Revision: D9503934
fbshipit-source-id: 0cd8337ad294cd0f8be692fecbf4292d204f3ec4
Summary:
@public
Now, one of the main purposes of `EventEmitter`s is to create RawEvent instances for all specific event invocations.
Reviewed By: mdvacca
Differential Revision: D8886226
fbshipit-source-id: 82a489174efcda097887e70650a2038dc986d149
Summary:
@public
Now, it's not just an abstract class, it's a regular class which unifies event delivery priorities using specific event beats and event pipe.
Reviewed By: mdvacca
Differential Revision: D8886232
fbshipit-source-id: c4360511e5fd477ca7407fc3ebbd99ca578e79cc
Summary:
@public
The existing code does not use that at all but we need that for testing things and we will need this in the future.
Reviewed By: mdvacca
Differential Revision: D8886236
fbshipit-source-id: 5ca33e4f4d4ca13a6be0f55cc04b59d5f9b27fa9
Summary:
@public
We need that to ensure that we will not deliver events to nodes with invalid state.
Reviewed By: mdvacca
Differential Revision: D8886234
fbshipit-source-id: 1d6ca129c97a5dca0411e85909aea48185f46c54
Summary:
@public
Instead of having two methods it's easier to have just one which can be abstracted as `EventPipe`.
Reviewed By: mdvacca
Differential Revision: D8886231
fbshipit-source-id: af9fd92dc4afa1219a11acce0aa021a85c94d232
Summary:
@public
EventQueue is a queue of events that synchronizing event dispatching with given Event Beat.
The only difference between UnbatchedEventQueue and BatchedEventQueue is that UnbatchedEventQueue `induce` an Event Beat right after enqueing an event.
Reviewed By: mdvacca
Differential Revision: D8886225
fbshipit-source-id: fedba6fdff2ecb6f3c615cea09b5fdaa58890479
Emily Janzer
Valentin Shergin
Tim Yung
Taras Tsugrii
Sergei Dryganets
Héctor Ramos
Jiaqi Wu
George Zahariev
Héctor Ramos
empyrical
Jonathan Kim
Oleg Lokhvitsky
Pritesh Nandgaonkar
Rafael Oleza
Kevin Gozali
David Vacca
Andrew Chen (Eng)
Ram N
Eli White
Peter Argany