Summary:
Some module classes may not be loaded yet, so looking up via classes may not always give the correct instance. This diff added a new lookup method that delegate to the bridge delegate to force load the modules as needed.
The existing moduleForName: method was left untouched because it's solely used by RCTUIManager at the moment.
Reviewed By: dshahidehpour
Differential Revision: D13033876
fbshipit-source-id: 4082fcd68498004f678b4b95adc82b5b134fefdf
Summary:
D12911108 fixed a UBN race condition by adding a flag for module registry.
This flag was never reset if react instance gets reset, causing an assert to fire in IG.
Reviewed By: fkgozali
Differential Revision: D13010651
fbshipit-source-id: e20453f3c546d759a58fd7fb93553f774410905f
Summary: Depending on when Chrome debugger is attached, modules may get double registered. Simply ignore it for this case. The redbox was not a fatal error, which can be dismissed.
Reviewed By: shergin
Differential Revision: D12996107
fbshipit-source-id: 292f63102337077848842ca46b3daed08b1cae12
Summary: Before lazily-loading code existed, modules that were already loaded into memory took precedent over modules that were additionally registered. With lazily loading modules, instead of giving eagerly loaded modules precdence, it throws a redbox. This diff fixes that behavior.
Reviewed By: PeteTheHeat
Differential Revision: D12983805
fbshipit-source-id: fe4fcf35d5c2ca6f9f4e3f0d1d8c2ca35468fb1b
Summary:
Previously, asking for an instance of NativeModule from the native side gave `nil` if the lazy modules have not been loaded, which is not consistent with the access from JS. This at least attempts to force load the lazy modules when asked from native.
p.s. one asks for a module by doing `[bridge moduleForClass:[FooBar class]]`.
Reviewed By: spredolac
Differential Revision: D12931640
fbshipit-source-id: 15d2dc574067d3386ef921512ce4bc837749dabd
Summary:
D12904277 was my sad, optimistic attempt to fix this crash.
As @[100006577537606:Slobodan] mentioned on T35879909, the real issue is that moduleRegistry is being created (using _moduleDataByID dict) concurrently while we try to append to this dict.
I added locks around these usage of _moduleDataByID.
Reviewed By: fkgozali
Differential Revision: D12911108
fbshipit-source-id: 2435b7a477c27585898f351c4a0d4c1bd4056756
Summary:
T35879909 is a UBN caused by a race condition in RN initialization. I haven't been able to repro, but the crash logs point to a bad memory access in this method. Another thread must be deallocating something concurrently.
This is a quick fix to patch into v197.
Reviewed By: fkgozali
Differential Revision: D12904277
fbshipit-source-id: 5740183f9a7c8f2c45ca627662891cb0c1048764
Summary:
@public
This allows apps to specify custom lazy modules that they need to load during chrome debugging. This is because lazy modules won't be available on start up, hence these modules will be missing in JS land, causing problems.
Reviewed By: shergin
Differential Revision: D12899408
fbshipit-source-id: dca313648e994b22e3ee5afec856ef76470065f9
Summary:
This diff introduces a new integration concept (called RuntimeExecutor) which consolidates `Runtime` and the dispatching mechanism.
As simple as that:
`using RuntimeExecutor = std::function<void(std::function<void(facebook::jsi::Runtime &runtime)> &&callback)>;`
Reviewed By: fkgozali
Differential Revision: D12816746
fbshipit-source-id: 9e27ef16b98af861d494fe50c7e50bd0536e6aaf
Summary:
[RN] Relax the requirement that lazy module cannot be initialized on the main thread
I tried to understand the D5364734 that intoduced this, and I am not sure, but belive that asserting here is too strict. If you have a module that you want to lazily initialize, and module does not demand the main queue, it should be just a warning if you run on the main queue, not necessarily an error.
Reviewed By: mmmulani
Differential Revision: D10429880
fbshipit-source-id: 018c211d45b98dd8c552bf0289fe517d05e56d47
Summary:
JSI+JSCRuntime replaces direct use of JSC. This is like the previous
diff, except for iOS.
Reviewed By: RSNara
Differential Revision: D9369108
fbshipit-source-id: 4ed2c0d660ba2a30edf699d95278c72cabcc9203
Summary:
change RCTCxxBridge to use JSIExecutorFactory+JSCRuntime
instead of JSCExecutorFactory. Also remove JSC usage from RN in other
files. This allows deleting files, too, which is done further down
the stack.
Reviewed By: RSNara
Differential Revision: D9369111
fbshipit-source-id: 67ef3146e3abe5244b6cf3249a0268598f91b277
Summary: The current buffer size isn't enough even to capture a short TTI trace.
Reviewed By: mhorowitz
Differential Revision: D10112538
fbshipit-source-id: 266fa6ffa916049245b21d7725a364d75589c776
Summary:
RCT_DEBUG is always defined - it is just rather 0 or 1 so
```#ifndef RCT_DEBUG is always true```
Pull Request resolved: https://github.com/facebook/react-native/pull/21232
Differential Revision: D9982316
Pulled By: hramos
fbshipit-source-id: 5408bfcf95a6ed2beae38217a6ad1ee43950857d
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:
Instead of asking existing modules to implement `+allowJSIBinding`, introduce a temporary "empty" protocol so modules can just adopt it for migration purpose.
Eventually this protocol may just go away.
Modules need to adopt both `RCTBridgeModule` and `RCTJSINativeModule` for time being for backward compatibility.
p.s. the entire system isn't enabled yet, this is just some of the pre-reqs for NativeModule improvements.
Reviewed By: mmmulani
Differential Revision: D9762913
fbshipit-source-id: 470f640f11a5991e5cfa9c48a1931da660ebfcd2
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:
[RFC] WIP: Way to register RCT_MODULE in Plugin2.0 instead of +load
This seemed like the simplest way to do this to register in the existing
didNotFindModule callback so that we don't have to touch any opensource code.
NOTE: The new version of this fixes the problems with dylibs, but not the -ObjC flag removal. This seems like the right call to avoid users having to implement c-functions to return their classes; instead we used objc_getClass.
Reviewed By: dshahidehpour
Differential Revision: D9112719
fbshipit-source-id: cf8df97d7c443cafa0e06a1e61bdf2612944ed87
Summary: This array can be modified while it's being iterated, so we need to take a copy. I also found another crash and guarded against it.
Reviewed By: fkgozali
Differential Revision: D8955708
fbshipit-source-id: 76250bc5d451776e74505733c0f3c14e555fb576
Summary:
@public
The bridge may send the reload event twice when reloading JS in some rare condition. The 2nd one was actually when the "new" bridge wasn't valid yet, so log an error if that happens. This may happen if the connection to Metro server gets into a weird state. Restarting Metro would solve the problem.
The issue was that `RCTBridgeWillReloadNotification` fired twice for each reload with metro connected.
Reviewed By: mmmulani
Differential Revision: D8509448
fbshipit-source-id: 647fb98c0a97503409a10451b8f152145947ae20
Summary: Calling the event emitters on the main thread seems to be problematic, so let's dispatch it via the JS thread. This requires some changes to make "eventTarget" single-use because otherwise the binding would need to synchronize the actual JS call with the act of releasing the target.
Reviewed By: shergin
Differential Revision: D8375291
fbshipit-source-id: bd2b42731176ae209f4a19c232309c163fb1c01b
Summary:
Fixes: #18384
Previously line 42 had a warning of: `Field 'm_jsThread' will be initialized after field 'm_delegate'`
This appears to be because the private member fields are declared in a different order than the initializer-list was told to initialize things.
I chose to re-order the initializer list because that fixes the warning by matching the code structure to what the compiler was telling us it was going to do.
An alternate fix would be to change the order of the member variables declared in the `private:` section to match the coded order in the initializer list. This might be the right move if the initializer list had the correct intent, but this would be a breaking change from a behavior perspective, so I'd need somebody with more knowledge to suggest this is the right move.
A. Examine line to see the warning is gone.
B. Get a C++ guru to figure out the intent of this file and see if this actually exposed a bug that recommends we go with the alternate fix suggested above.
[IOS][MINOR][React/CxxBridge/] - Build warning fix
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Closes https://github.com/facebook/react-native/pull/18385
Differential Revision: D7328272
Pulled By: mhorowitz
fbshipit-source-id: 59d7ace6222c4609ac7d023f97e522e85e02a9db
Summary:
`RCTJavaScriptWillStartLoadingNotification` is being posted when starting the bridge, not when starting to execute JS code.
Here, we add `RCTJavaScriptWillStartExecutingNotification`, and in post it before executing JS with `RCTCxxBridge`.
Reviewed By: fromcelticpark
Differential Revision: D7153659
fbshipit-source-id: 902075308d54a47bef43b6f57edf2e624f621ceb
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
I've talked to several major community users, and they're all ok with deleting this
code. There's several doc fixes which will make it easier for third
party developers which should land about the same time this will.
Also buried along with it is RCTJSCExecutor.
Reviewed By: javache
Differential Revision: D6880781
fbshipit-source-id: b4cb1143def6fd23a96290e478fa728adbedacd3
