Summary:
This diff removes an option from the codegen and replaces it with two new options
Removes:
- `isDeprecatedPaperComponentNameRCT`
Adds:
- `paperComponentName`: a better version of the removed option that allows more than just adding RCT
- `paperComponentNameDeprecated`: a new option that allows migrating native code to a new name
```
// Use for components with no current paper rename in progress
// Does not check for new name
paperComponentName?: string,
// Use for components currently being renamed in paper
// Will use new name if it is available and fallback to this name
paperComponentNameDeprecated?: string,
```
For example, Slider uses `paperComponentName: 'RCTSlider'` because it has a different name in fabric but is not currently being migrated to a new name. Because of other work in progress, we don't want to use UIManager check if we don't need to
Reviewed By: shergin
Differential Revision: D15857629
fbshipit-source-id: ca0d3b7dc4a75e00d136ae1f5c84f7423960399d
Summary:
When a synchronous call from JS to native code throws an error, it doesn't include a useful stack trace from the native side. To improve error attribution, this diff pops the frames in `MessageQueue.js` and `NativeModules.js` from the stack traces of such errors. This uses the `error.framesToPop` convention understood by RN's global error handler.
For now we limit this to errors converted from C++ exceptions in host functions, since those are not likely to ever contain further JavaScript frames at the point where we catch them; if they did, it would violate our assumption that the top two frames of the stack are in the JS bridge code.
Reviewed By: cwdick
Differential Revision: D15805054
fbshipit-source-id: 8c1dd7c81b00b6a88e31473271889af1f88f7263
Summary: Adds a test for synchronous methods (`type === 'sync'`) in NativeModules. This doesn't modify any behaviour.
Reviewed By: amnn
Differential Revision: D15804757
fbshipit-source-id: 4db76dbd0b0b111ed9311d4b7ec35a077c377f01
Summary: Adds a test for promise-returning methods (`type === 'promise'`) in `NativeModules`. This doesn't modify any behaviour.
Reviewed By: cwdick
Differential Revision: D15802452
fbshipit-source-id: 8dc1f862d33742ef4ba355ca36338e0dbabf8edb
Summary:
Types the last 3 members of the `ModuleConfig` tuple (functions, promise method IDs, and sync method IDs) as nullable and immutable arrays. This is in line with how they are used in the code; one debug-only call site had to be fixed to account for nullability.
Also updates the test data in `MessageQueueTestConfig` to explicitly conform to this type.
Reviewed By: amnn
Differential Revision: D15899159
fbshipit-source-id: b6955ba92efc73253de48e2ce7c3034fa91adce3
Summary:
When calling a prop of type `RCTDirectEventBlock` or `RCTBubblingEventBlock` it uses a completely different code path than events using `[RCTEventDispatcher sendEvent:]` and those were not dispatched to the `RCTEventDispatcherListener`s. We also do some event name normalization which caused issues between the JS and native event names. To fix that I simply remove the parts we normalize from the event key.
## Changelog:
[iOS] [Fixed] - Support events using RCT{Direct|Bubbling}EventBlock
Pull Request resolved: https://github.com/facebook/react-native/pull/15611
Test Plan: Added a Slider (it used RCTBubblingEventBlock for it's onValueChange event) that can control a native animated value in RNTester to reproduce the bug and made sure this diff fixes it.
Differential Revision: D15896806
Pulled By: cpojer
fbshipit-source-id: c0ae463f4c3f890062238575e813ed7ab3b7a7e6
Summary: For better perf with TurboModule, cache the return value of NativePlatformConstants*.getConstants() in JS so that we avoid going back into native (from JS) for each call. This specific method is called very frequently throughout RN codebase.
Reviewed By: mdvacca
Differential Revision: D15893289
fbshipit-source-id: ce8016ed7d3efb420df93e27dbfa77d7d4f06cf8
Summary: Previously, we didn't provide any LayoutContext to the very first commit (aka startSurface); apparently it causes problems.
Reviewed By: mdvacca
Differential Revision: D15891472
fbshipit-source-id: b2a785bdad5764eb97b41f5bf5679807107bd8a0
Summary: Some TM lookup from native will fail assertion if done too early, because TM Manager is not initialized yet.
Reviewed By: mdvacca
Differential Revision: D15872776
fbshipit-source-id: 7616c1424816f73a45aa1d9723e7807ae10392a7
Summary:
To avoid unnecessary class loads, and better modularity, let's use string keys (enum) to access JSIModule's. For now all JSIModule's are all known inside the core infra (only FabricUIManager and TurboModuleManager right now), so let's keep it simple and explicitly list them out.
The only problem here is we lose some form of type safety...
Reviewed By: JoshuaGross
Differential Revision: D15872777
fbshipit-source-id: 9c2de7ef1e88ef3a6dff5888d644f9d8963af2a3
Summary: I added this function in D15810990, not sure why lint didn't complain about this...
Reviewed By: zackargyle
Differential Revision: D15880129
fbshipit-source-id: 4d207ba26be46186dc3904c82d82a4a83d4d4eb7
Summary:
ComponentName is used by many core component of React Native, such as ComponentDescriptor, ShadowNode, ShadowView and so on. In all those cases this value represents the actual name of the component which came from `concreteComponentName` template parameter of ConcreteShadowNode. In all of those cases, it's raw `char const *` type. So, we don't need to use owning representation of the string (std::string) in all those places.
The only exception from this is a part where we receive the name of the component from JS side. In this case, the source string comes from JS and has to be analyzed as a character sequence to find corresponding ComponentDescriptor.
In my experiments, 20% of the time during diffing is spent on copying (this) `std::string`.
Reviewed By: mdvacca
Differential Revision: D15844407
fbshipit-source-id: a2e71505e22d09107e001bdf661d4a826bcf2dea
Summary:
It is possible that race conditions exist in access of scheduler and UIManager in Binding.cpp, such that deallocated or null schedulers/UIManagers could be passed as arguments into various functions, causing strange and exotic crashes down the line once garbage memory (or null pointers) are dereferenced.
I think it's possible that navigating away from a Fabric screen while there's high memory pressure could cause things to get deallocated more aggressively and cause scheduler and/or UIManager to disappear while mounting instructions are being created, for instance.
Reviewed By: mdvacca
Differential Revision: D15863193
fbshipit-source-id: a85cb71d88ea54826b40f44e788931dfc422f045
Summary:
The problem happens only from native debug build, i.e.
`NATIVE_BUILD_TYPE=Debug ./gradlew ...`
During Java exception happens, [only limited methods are allowed](https://developer.android.com/training/articles/perf-jni#exceptions_1).
RN uses smart pointer to manage JNI reference.
There is an assert() in smart pointer constructor that will call other JNI method and lead to VM crash.
Since assert() do things in debug build by default, the problem will not happens on native release build.
### Crash backtrace
Java exception happens:
```
java_vm_ext.cc:534] JNI DETECTED ERROR IN APPLICATION: JNI GetObjectRefType called with pending exception com.facebook.react.uimanager.IllegalViewOperationException: No ViewManager defined for class Text
java_vm_ext.cc:534] at com.facebook.react.uimanager.ViewManager com.facebook.react.uimanager.ViewManagerRegistry.get(java.lang.String) (ViewManagerRegistry.java:57)
java_vm_ext.cc:534] at com.facebook.react.uimanager.ViewManager com.facebook.react.uimanager.UIImplementation.resolveViewManager(java.lang.String) (UIImplementation.java:134)
java_vm_ext.cc:534] at com.facebook.react.bridge.WritableMap com.facebook.react.uimanager.UIManagerModule.computeConstantsForViewManager(java.lang.String) (UIManagerModule.java:325)
java_vm_ext.cc:534] at com.facebook.react.bridge.WritableMap com.facebook.react.uimanager.UIManagerModule.getConstantsForViewManager(java.lang.String) (UIManagerModule.java:319)
java_vm_ext.cc:534] at void com.facebook.react.bridge.queue.NativeRunnable.run() (NativeRunnable.java:-2)
java_vm_ext.cc:534] at void android.os.Handler.handleCallback(android.os.Message) (Handler.java:790)
java_vm_ext.cc:534] at void android.os.Handler.dispatchMessage(android.os.Message) (Handler.java:99)
java_vm_ext.cc:534] at void com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(android.os.Message) (MessageQueueThreadHandler.java:29)
java_vm_ext.cc:534] at void android.os.Looper.loop() (Looper.java:164)
java_vm_ext.cc:534] at void com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run() (MessageQueueThreadImpl.java:232)
java_vm_ext.cc:534] at void java.lang.Thread.run() (Thread.java:764)
```
Native crash backtrace:
```
#00 pc 00000000000276f8 /system/lib64/libc.so (syscall+24)
https://github.com/facebook/react-native/issues/01 pc 0000000000027905 /system/lib64/libc.so (abort+101)
https://github.com/facebook/react-native/issues/02 pc 000000000052f32e /system/lib64/libart.so (art::Runtime::Abort(char const*)+558)
https://github.com/facebook/react-native/issues/03 pc 00000000006341a8 /system/lib64/libart.so (android::base::LogMessage::~LogMessage()+1016)
https://github.com/facebook/react-native/issues/04 pc 0000000000399339 /system/lib64/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+1657)
https://github.com/facebook/react-native/issues/05 pc 00000000003994c2 /system/lib64/libart.so (art::JavaVMExt::JniAbortV(char const*, char const*, __va_list_tag*)+82)
https://github.com/facebook/react-native/issues/06 pc 0000000000178aab /system/lib64/libart.so (art::ScopedCheck::AbortF(char const*, ...)+187)
https://github.com/facebook/react-native/issues/07 pc 00000000001785b8 /system/lib64/libart.so (art::ScopedCheck::CheckThread(_JNIEnv*)+472)
https://github.com/facebook/react-native/issues/08 pc 0000000000176871 /system/lib64/libart.so (art::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::JniValueType*)+801)
https://github.com/facebook/react-native/issues/09 pc 000000000017614a /system/lib64/libart.so (art::CheckJNI::GetObjectRefType(_JNIEnv*, _jobject*)+778)
https://github.com/facebook/react-native/issues/10 pc 0000000000123831 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (_JNIEnv::GetObjectRefType(_jobject*)+49)
https://github.com/facebook/react-native/issues/11 pc 00000000001236b1 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (facebook::jni::LocalReferenceAllocator::verifyReference(_jobject*) const+81)
https://github.com/facebook/react-native/issues/12 pc 0000000000046f40 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libfb.so (facebook::jni::base_owned_ref<_jthrowable*, facebook::jni::LocalReferenceAllocator>::base_owned_ref(_jthrowable*)+64)
https://github.com/facebook/react-native/issues/13 pc 0000000000046ef7 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libfb.so (facebook::jni::basic_strong_ref<_jthrowable*, facebook::jni::LocalReferenceAllocator>::basic_strong_ref(_jthrowable*)+39)
https://github.com/facebook/react-native/issues/14 pc 000000000003648b /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libfb.so (_ZN8facebook3jni11adopt_localIP11_jthrowableEENS0_16basic_strong_refIT_NS0_23LocalReferenceAllocatorEEES5_+27)
https://github.com/facebook/react-native/issues/15 pc 0000000000036333 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libfb.so (facebook::jni::throwPendingJniExceptionAsCppException()+99)
https://github.com/facebook/react-native/issues/16 pc 000000000018652f /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (facebook::react::MethodInvoker::invoke(std::__ndk1::weak_ptr<facebook::react::Instance>&, facebook::jni::alias_ref<facebook::jni::detail::JTypeFor<facebook::react::JBaseJavaModule, facebook::jni::JObject, void>::_javaobject*>, folly::dynamic const&)+4559)
https://github.com/facebook/react-native/issues/17 pc 00000000001616fa /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (_ZN8facebook5react16JavaNativeModule26callSerializableNativeHookEjON5folly7dynamicE+954)
https://github.com/facebook/react-native/issues/18 pc 000000000021bbd6 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (_ZN8facebook5react14ModuleRegistry26callSerializableNativeHookEjjON5folly7dynamicE+486)
https://github.com/facebook/react-native/issues/19 pc 000000000022d90b /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libreactnativejni.so (_ZN8facebook5react16JsToNativeBridge26callSerializableNativeHookERNS0_10JSExecutorEjjON5folly7dynamicE+75)
https://github.com/facebook/react-native/issues/20 pc 000000000004a6fa /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libjscexecutor.so (facebook::react::JSIExecutor::nativeCallSyncHook(facebook::jsi::Value const*, unsigned long)+202)
https://github.com/facebook/react-native/issues/21 pc 000000000004b7a2 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libjscexecutor.so
https://github.com/facebook/react-native/issues/22 pc 0000000000056475 /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libjscexecutor.so
https://github.com/facebook/react-native/issues/23 pc 00000000000c3a0a /data/app/com.facebook.react.uiapp-NEO_tjqQpFriZwGleZxJeQ==/lib/x86_64/libjsc.so
```
Java exception code from [ViewManagerRegistry.java](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/uimanager/ViewManagerRegistry.java#L45-L58) :
```java
public ViewManager get(String className) {
ViewManager viewManager = mViewManagers.get(className);
if (viewManager != null) {
return viewManager;
}
if (mViewManagerResolver != null) {
viewManager = mViewManagerResolver.getViewManager(className);
if (viewManager != null) {
mViewManagers.put(className, viewManager);
return viewManager;
}
}
throw new IllegalViewOperationException("No ViewManager defined for class " + className);
}
```
It is an expected exception as [legacy JS try to find view manager](https://github.com/facebook/react-native/blob/master/Libraries/ReactNative/PaperUIManager.js#L44-L50) and Text has no ViewManager registered in fact.
From C++ assert:
`adopt_local` will call to base_owned_ref() and [there is an assert to ensure JNI reference type](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/jni/first-party/fb/include/fb/fbjni/References-inl.h#L203-L209).
```C++
template<typename T, typename Alloc>
inline facebook::jni::base_owned_ref<T, Alloc>::base_owned_ref(
javaobject reference) noexcept
: storage_(reference) {
assert(Alloc{}.verifyReference(reference));
internal::dbglog("New wrapped ref=%p this=%p", get(), this);
}
```
In the verifyReference(), [there is a GetObjectRefType() call which is an invalid call at exception pending state](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/jni/first-party/fb/include/fb/fbjni/ReferenceAllocators-inl.h#L57-L62).
```C++
inline bool LocalReferenceAllocator::verifyReference(jobject reference) const noexcept {
if (!reference || !internal::doesGetObjectRefTypeWork()) {
return true;
}
return internal::getEnv()->GetObjectRefType(reference) == JNILocalRefType;
}
```
The fix moves `adopt_local()` wrapping after `ExceptionClear()` and we could call `GetObjectRefType()` without problems.
## Changelog
[Android] [Fixed] - Fix Android native debug build assert crash
NOTE this might be ignored in RN release changelog.
Since the problem should exist for years and no user tried native debug build.
Pull Request resolved: https://github.com/facebook/react-native/pull/25263
Test Plan:
Try to run RNTester from native debug build and make sure no crash happens.
(It is a launch crash and should be easy to verify)
`NATIVE_BUILD_TYPE=Debug ./gradlew clean :RNTester:android:app:installDebug`
Differential Revision: D15873691
Pulled By: cpojer
fbshipit-source-id: fb93b85daa1136cdf44e7fd7f217a2767391d8dd
Summary:
HTTPS is good and this prevents a HTTP redirect
## Changelog
[Internal] [Fixed] - https link to EditorConfig.org
Pull Request resolved: https://github.com/facebook/react-native/pull/25267
Differential Revision: D15873696
Pulled By: cpojer
fbshipit-source-id: 2d769fe163816c75d1461d09837ec9c06a929e04
Summary: This diff forces the method: scheduler.constraintSurfaceLayout to run on the JS thread.
Reviewed By: JoshuaGross
Differential Revision: D15845768
fbshipit-source-id: de2aa69f301770aaf6cb7c3f5670548a3b6110df
Summary: Seems RCTImageLoader is not thread-safe, so we need to compensate for this for now. Classic RN mostly accesses the loader from the main thread (non-concurrently), so it mostly works for Paper.
Reviewed By: mdvacca
Differential Revision: D15867574
fbshipit-source-id: 4aad5570b57a136aa0bbe31d65f1afe2ae6e380e
Summary: We should not use `self.contentView` accessor to insert container views (views that might be used as a container for nested views) into component view otherwise it causes double applying of padding values.
Reviewed By: mdvacca
Differential Revision: D15862075
fbshipit-source-id: aad834aeca06f66b19c2f7bbaa0b58f937e66994
Summary: Requiring legacy native modules fails in bridgeless mode because they use the batched bridge, so we need to check for turbomodules first to avoid crashing. In D15703655 I reversed the order of this check for everyone, but this had some unintended side effects (everyone got turbomodules). This time I'm just using my flag to check for bridgeless mode so we can bail out of legacy native modules instead.
Reviewed By: fkgozali
Differential Revision: D15857106
fbshipit-source-id: 9d33161ae059e7a357f135c82b6865f4d2a57add
Summary: Scheduler.startSurface accepts LayoutConstraints and LayoutContext, but for some reason we don't use these on Android. This diff adds new methods to Binding and FabricUIManager to start a surface with the provided measurespecs. I created new methods to avoid affecting the functionality of any surfaces already using Fabric, but if we want this behavior everywhere then I can just add it to the existing `addRootView` and `startSurface`.
Reviewed By: JoshuaGross, shergin
Differential Revision: D15810990
fbshipit-source-id: 6cd9a58b125461f91253458905405298cfb723ce
Summary:
This adds the Fresh Babel plugin and runtime to React Native dependencies. **They're not actually being used or enabled yet**. This is purely additive and just gets the deps setup out of the way for future diffs.
The `react-refresh` source of truth is in the React repo.
Reviewed By: cpojer
Differential Revision: D15828330
fbshipit-source-id: 67ec2dea8c896477ff8b434445f1730e388ea67a
Summary: This diff adds the generated view config for View (in DEV)
Reviewed By: ejanzer
Differential Revision: D15780039
fbshipit-source-id: 1ec8ed1b57fd2341552746051980129848cb8e85
Summary:
## Context
At the moment, the codegen process does not expect any types defined in a native component (*NativeComponent.js) to be exported. For example, the `NativeProps` type may be defined as:
```
// RCTSegmentedControlNativeComponent.js
type NativeProps = $ReadOnly<{|
...
onChange?: ?(event: BubblingEvent<Event>) => mixed,
|}>;
```
However, it would be helpful to be able to reuse `NativeProps` in the user facing component:
```
// SegmentedControlIOS.js
type Props = $ReadOnly<{|
...NativeProps
onValueChange?: ?(value: number) => mixed,
|}>;
```
## Changes
- updates the `getTypes` function to unwrap the type declaration inside exported declarations
- add test to verify that exported types are parsed as expected
Reviewed By: rickhanlonii
Differential Revision: D15851693
fbshipit-source-id: a9cd375c69cbb8fe9a38be3d2a681227444fb33d
Summary:
Adds the ability to `MarkerSection` to end the marker before it goes out of scope.
This unlocks two scenarios:
- reuse the data associated with a marker after ending it.
- end markers in the middle of a function without adding arbitrary blocks.
Reviewed By: SidharthGuglani
Differential Revision: D15837840
fbshipit-source-id: c0afaeeabd169c65189b5028be54ea7dac3e3b84
Summary: Counts how many times measure callbacks have been invoked during a layout pass. This is made available via the marker and event APIs.
Reviewed By: SidharthGuglani
Differential Revision: D15836983
fbshipit-source-id: 3835bef94e497375821c9f2ad8209447b4f11518
Summary: Just adding a few systrace sections to add perf visibility in a few more areas.
Reviewed By: ejanzer
Differential Revision: D15823394
fbshipit-source-id: 6ac1773cbd8e01a747ad015726e16c0bf0e8596b
Summary:
There's an issue with TextInput on Android where if you have TalkBack enabled, double tapping doesn't focus the text input. It turns out this is because we ignore all focus events that aren't from JS in ReactEditText. This diff makes an exception for the accessibility click event.
I think this should also fix https://github.com/facebook/react-native/issues/17624
Reviewed By: lunaleaps
Differential Revision: D15818103
fbshipit-source-id: 354728b58f1023c4d44edd48337c8daa8ea15c0c
Summary: `Stringish` is commonly used in components to accept either strings or values coming from Fbt tags. The codegen should support them as they can be used transparently as strings.
Reviewed By: rickhanlonii
Differential Revision: D15821882
fbshipit-source-id: fb94f702d82820677c5a737325b7b46ff4c88151
Summary: Easy diff to create a ReactFeatureFlag to enabled logging in Fabric
Reviewed By: JoshuaGross
Differential Revision: D15803582
fbshipit-source-id: d735f24850bddf43c27b97d006100cbb8f0cc6e3
Summary: This diff fixes an issue with generated view configs due to react-native-gesture-handler adding events to view which are not in the view config on javascript. These will need removed later when react-native-gesture-handler is updated for the new system
Reviewed By: fkgozali
Differential Revision: D15813596
fbshipit-source-id: 8914c093d9cb03e320406d154bb88abf557a951e
Summary:
There can be a race condition between bridge invalidation (hence TM binding invalidation) with pending Promise reject/resolve invocation. If invalidation happens first, invoking the resolve/reject from ObjC class might end up accessing destroyed PromiseWrapper, causing hard crash randomly.
The proper fix is to switch the objc promise resolve/reject block (objc block) to use C++ PromiseWrapper directly, such that the lifecycle of the shared_ptr<> can be correct.
Reviewed By: RSNara
Differential Revision: D15801403
fbshipit-source-id: 9b0c7d323b18d94e920ea3eafc3a6916dadba247
Summary: Make `TurboCxxModule::get` return `undefined` when trying to access methods that don't exist. This is what `TurboModule::get` does. So, it makes sense that this behaviour is preserved in TurboCxxModule.
Reviewed By: mdvacca
Differential Revision: D15780044
fbshipit-source-id: 13aeae081655735ef634f1dc09c0dc70a3a3a893
Summary: Developer tools have a lot of dependencies on the bridge, so for now I'm just disabling them in bridgeless mode entirely by guarding everything in `setUpDeveloperTools` with the `RN$Bridgeless` flag. Also consolidating some of the stuff Dan added to `InitializeCore` for hot reloading in here.
Reviewed By: zackargyle
Differential Revision: D15797924
fbshipit-source-id: 360ea81a2844e49f7281eed259fc16a541148ac2
Summary:
This diff reimplements the prop parsing infrastructure in a part where it interacts with RawProps value.
Local synthetic tests show that the new way is 3x faster but the actual production result is quite unpredictable. MobileLab tests show some improvements about 10-20 ms on iPhone 6.
In short, the new way is faster because it inverts the lookup order and heavily relies on actual data types (and their properties) that we use. The old approach required about 130 hash-map lookups (where the key is `std::string`) to parse a single *Props object.
The new approach prepares concrete-props-specific tables with indexes of coming values ahead of time, iterates over raw data and puts it into those tables, and then performs a lookup in a very efficient manner.
Reviewed By: JoshuaGross
Differential Revision: D15752968
fbshipit-source-id: 847106e652eb7fc7ef7b99884a6f819ea3b9fd06
Summary: Even though it makes no sense to construct RootProps from RawProps, we need to support that (even if it's no-op) to be able to call this once from generic `ConcreteComponentDescriptor`. We will need it in the coming diff.
Reviewed By: mdvacca
Differential Revision: D15752970
fbshipit-source-id: b75a4023c5d0425a8dbe0f104a36a0f265eb6084
Rick Hanlon
Moti Zilberman
Dan Abramov
Anton Domashnev
Janic Duplessis
Kevin Gozali
Valentin Shergin
Emily Janzer
Joshua Gross
Vojtech Novak
Kudo Chien
Christian Oliff
David Vacca
Cameron Bourke
David Aurelio
Logan Daniels
Luna Wei
Rubén Norte
Eli White
Michał Pierzchała
Ramanpreet Nara
Mikael Sand