Updating #1
Merged
Updating #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: This fixes the [Align Items example](http://facebook.github.io/react-native/releases/next/docs/flexbox.html#align-items) in Layout with Flexbox -documentation page by fixing a broken example. <img width="892" alt="screen shot 2016-07-06 at 20 59 08" src="https://cloud.githubusercontent.com/assets/482561/16629040/ee0e819e-43bc-11e6-8ca1-eb9b90869b59.png"> EDIT: Seems like 34adde9 tried to cover all of these but missed one case :) Closes #8608 Differential Revision: D3523445 Pulled By: JoelMarcey fbshipit-source-id: ffc8be2b2e85d3b821a37e387e9385e57820a200
…ListView Summary: This is simple fix to SwipeableListView. According to SwipeableListViewDataSource, the only method available is cloneWithRowsAndSections. If you try to get the data from a SwipeableListView, without this fix it won't work. This change fixes the problem so that SwipeableListView can work correctly. Closes #8493 Differential Revision: D3523384 fbshipit-source-id: 359ff274fabcab676ed6dee24f0652c4146cde69
Reviewed By: gabelevi Differential Revision: D3522895 fbshipit-source-id: 52f28c7f3142566a07d8bc845be882aeda098809
Differential Revision: D3521227 fbshipit-source-id: 57db97ea2af2b2c9e55f380ce05d9e78a5f9d48c
Summary: A couple changes people requested. None of the author links were doing anything, so now they link to Twitter profiles, and also the references to react-native-web have a standardized style w\ react-native-web-player. Closes #8617 Differential Revision: D3524125 Pulled By: JoelMarcey fbshipit-source-id: 68afa1bafeceed98f82fa4ced766da143790b5ba
Summary: This closes #8610. The release of 1.6.2 of yeoman-environment break react-native (since there is no lib folder) Yeoman will be removed from RN as #8197 anyway. Thanks cpsubrian, RobTS **Test plan (required)** I installed the 1.2.7 version and copied it in react-native nodes_modules. Then I ran react-native upgrade <img width="1337" alt="screen shot 2016-07-06 at 21 09 33" src="https://cloud.githubusercontent.com/assets/13785185/16631160/075fc422-43be-11e6-8625-92f03075b007.png"> Closes #8614 Differential Revision: D3524043 fbshipit-source-id: 1def4854ca0fd881b8a935f37c86eb373dfd97c5
Reviewed By: astreet Differential Revision: D3510875 fbshipit-source-id: a7042434b68cb849f5b0c4ef782befff6a27ef5c
Summary: Delete the bridge functions(isRTL, allowRTL()) in internal module and move to OSS. Create bridge for RCTI18nUtil Reviewed By: fkgozali Differential Revision: D3519224 fbshipit-source-id: 3853edcfcc78777d957874448117de72ae0700b5
Reviewed By: davidaurelio Differential Revision: D3528031 fbshipit-source-id: baf74d68127038659f88fd65b8eb3fe41444d9aa
Summary: Adds: - getType so you can switch on type - getPrivate Reviewed By: lexs Differential Revision: D3515510 fbshipit-source-id: d574b04f563ac650bacec3751b50be6345e8439a
…xecutor Summary: JSCExecutor has something like this, but for methods on JSCExecutor itself. Open to better ideas around how to share code Reviewed By: lexs Differential Revision: D3516314 fbshipit-source-id: 4b1265916c52d582bb0b9348e9b4a099f566d6c9
…sistent with iOS Summary: So `PanReponder.onPanResponderRelease/onPanResponderTerminate` receive a `gestureState` object containing a `onPanResponderTerminate.vx/vy` property. On Android and iOS, they appear to be orders of magnitude different, which appear to be due to the different scale of timestamps that are used when generating touch events. This pull request fixes the timestamps to be milliseconds on both platforms (since I assume iOS is the more authoritative one, and is the one that `react-native-viewpager`'s vx thresholds written written to compare against.) As far as I can tell, the RN code doesn't use the `vx/vy` properties, so they should be okay. And looks like the RN code only cares about relative values of `startTimestamp/currentTimestamp/previousTimestamp` though, so should be fine too. it's quite possible there will be downstream android breakage with this change, particularly for those who are already compensating for the RN discrepancy. Closes #8199 Differential Revision: D3528215 Pulled By: dmmiller fbshipit-source-id: cbd25bb7e7bb87fa77b661a057643a6ea97bc3f1
Reviewed By: javache Differential Revision: D3509004 fbshipit-source-id: c4ab12b3f1defa32c2b1c211e775f6782ede4b7f
Summary: So `PanReponder.onPanResponderRelease/onPanResponderTerminate` receive a `gestureState` object containing a `onPanResponderTerminate.vx/vy` property. On Android and iOS, they appear to be orders of magnitude different, which appear to be due to the different scale of timestamps that are used when generating touch events. This pull request fixes the timestamps to be milliseconds on both platforms (since I assume iOS is the more authoritative one, and is the one that `react-native-viewpager`'s vx thresholds written written to compare against.) As far as I can tell, the RN code doesn't use the `vx/vy` properties, so they should be okay. And looks like the RN code only cares about relative values of `startTimestamp/currentTimestamp/previousTimestamp` though, so should be fine too. it's quite possible there will be downstream android breakage with this change, particularly for those who are already compensating for the RN discrepancy. Closes #8199 Differential Revision: D3528215 Pulled By: davidaurelio fbshipit-source-id: d81732e50a5ece2168e8347309d8d52a0db42951
Reviewed By: frantic Differential Revision: D3509012 fbshipit-source-id: 66742ebed80ecf48ce8291b1816ef0ec672febee
Reviewed By: michalgr Differential Revision: D3207541 fbshipit-source-id: d53599c3cf36ae7c89e85a29f637987bc7139159
Reviewed By: mhorowitz Differential Revision: D3469140 fbshipit-source-id: 77a00a7150573e44f219972556cbb936a57d7054
Reviewed By: astreet Differential Revision: D3475592 fbshipit-source-id: 37148bb8d8d47e9301ad549b183029337f7c4ca0
Summary: This adds proper support for tracking a TextInput content size as discussed in #6552 by adding a new callback that is called every time the content size changes including when first rendering the view. Some points that are up for discussion are what do we want to do with the onChange callback as I don't see any use left for it now that we can track text change in onChangeText and size changes in onContentSizeChange. Also a bit off topic but should we consider renaming onChangeText to onTextChange to keep the naming more consistent (see [this naming justification](https://twitter.com/notbrent/status/709445076850597888)). This is split in 2 commits for easier review, one for iOS and one for android. The iOS implementation simply checks if the content size has changed everytime we update it and fire the callback, the only small issue was that the content size had several different values on initial render so I added a check to not fire events before the layoutSubviews where at this point the value is g Closes #8457 Differential Revision: D3528202 Pulled By: dmmiller fbshipit-source-id: fefe83f10cc5bfde1f5937c48c88b10408e58d9d
Summary: If stacktrace-parser can't parse a stack trace, it'll return null. This can cause us to accidentally enter a crash loop where whenever you start your app, you load the last JS bundle you had, get a crash, and then hard crash trying to print the stack trace. Reviewed By: frantic Differential Revision: D3528141 fbshipit-source-id: 1146f43bc40492bfa79b6a1c0f81092383896164
Summary: Previously, trying to parse an empty network body would throw "Unexpected EOF" from JSON.parse. Now we explicitly call out the error and provide steps for possible mitigation. Reviewed By: frantic Differential Revision: D3528297 fbshipit-source-id: 3b52c9491c1504c282eb9bc12ed46069cb6cbd60
…arge codebases Reviewed By: jingc Differential Revision: D3528913 fbshipit-source-id: f04eff42327bd729ebfcd71856a1d38ef9810986
…ries/FBReactKit/BUCK Reviewed By: javache Differential Revision: D3442470 fbshipit-source-id: 584a2bb3df5f7122166778b8fd44fae45560491e
Summary: The subspec for `RTCAnimation` defines a `preserve_paths` attribute of `Libraries/NativeAnimation/*.js` (https://github.com/facebook/react-native/blob/master/React.podspec#L60) but there is no JavaScript file in that repository. Linting the podspec therefore fails. The fix was to simply remove `preserve_paths` for this subspec. Closes #8626 Differential Revision: D3529959 fbshipit-source-id: b187f6ce3898493d9f6a03960caf5ec25c9e4ac2
Reviewed By: javache Differential Revision: D3517664 fbshipit-source-id: cafda7eccbf25f6e197ba9bd18e82c814f08e3bb
Summary: No need to keep it open; it just makes it harder to reason about error handling. Reviewed By: majak Differential Revision: D3518200 fbshipit-source-id: dc1af6eb0f75de7e9f73513ed1dd522048f76670
Summary: No need to have these way at the top; they're not used until later. Reviewed By: majak Differential Revision: D3518364 fbshipit-source-id: 3e7461665e90dea5c6d323d45b1ffb11fb610b09
…agic number Summary: Reading four bytes is not slow. Don't bother dispatching for that. Reviewed By: javache Differential Revision: D3518405 fbshipit-source-id: 910079cec2a1f624dd71760438765bd035055229
Summary: It's not widely used, and you can do something equivalent anyway by using existing public API. Reviewed By: javache Differential Revision: D3518896 fbshipit-source-id: 6995a5d840aecfff4ffd78ac43f3f592a4f47f91
Summary: This leaves no optional methods on `RCTJavaScriptExecutor`, which is certainly a good thing. Reviewed By: majak Differential Revision: D3518915 fbshipit-source-id: e606b9076c3299f81a225a181ea244148a1832cb
Summary: In Android `RecyclerViewBackedScrollView` didn't provide the `scrollTo` API, however iOS does. If a ListView was created with `RecyclerViewBackedScrollView` as its `renderScrollComponent`, then calling `scrollTo` wouldn't work. This diff enables the `scrollTo` API in `RecyclerViewBackedScrollView` on Android. Reviewed By: dmmiller Differential Revision: D3605233 fbshipit-source-id: f192053361f45453e5fce3fb6038ab03ac4025af
Summary: In Timing.java, the key provided to the remove function of mTimerIdsToTimers is not correct, that may introduce bugs. Closes #8966 Differential Revision: D3605291 Pulled By: astreet fbshipit-source-id: 97563b6846e8f3f40d20b48b3852dd557c9932f3
Summary: Closes #8964 Differential Revision: D3605729 fbshipit-source-id: 517a06d5100742af2fa57bc5ccf8e8e957165f7c
Reviewed By: mmmulani Differential Revision: D3599003 fbshipit-source-id: 25090309c92127b403d1df6a8b7c18ad5a088b5e
Reviewed By: javache Differential Revision: D3600752 fbshipit-source-id: 84cea3b67daa67b92a8845454aecf1462c857b50
Reviewed By: majak Differential Revision: D3598946 fbshipit-source-id: fdbbbf3b9bd262e0b14b5b9a40171a1c039695a7
Differential Revision: D3604593 fbshipit-source-id: f7f77bfb01ca51e660b68945ff7271a492df1bcb
Summary: Add a batch addition operation for ViewPager. Differential Revision: D3597840 fbshipit-source-id: 1c9c42e03da2492444298220e75f547b6567b4e5
Reviewed By: javache Differential Revision: D3600853 fbshipit-source-id: 46ef2d0e54e4ce417cc3d4138c8d8f60d5c34173
Differential Revision: D3604593 fbshipit-source-id: fe792739dbe4af294ef0071b4db4ab181adcb874
Reviewed By: majak Differential Revision: D3598946 fbshipit-source-id: fb70f5b031a85f30a6207eb95b7fd0ccd7d78039
Summary: Missing import throws variable error Closes #8988 Differential Revision: D3611142 fbshipit-source-id: b50edf52cdf6c723abaa7bd021cf11ee5b4d874d
Summary: Added a fix to the GettingStarted guide, for when npmlog module isn't found. Solution copied from: tj/n#101 (comment) Closes #8994 Differential Revision: D3612345 Pulled By: JoelMarcey fbshipit-source-id: 10e7381adc530bb97c795cae022da3525745122a
Summary: Closes #8991 Differential Revision: D3612777 Pulled By: dmmiller fbshipit-source-id: d8da5ef8354cdaf55d8a3efbc2bfbc2aef74a044
Summary: revision of #5476 It has only one method `shareTextContent` and next will be`shareBinaryContent`. In Android, Promise can't receive a result, because `startActivityForResult` is not working with `Intent.ACTION_SEND`. Maybe we can use `createChooser(Intent target, CharSequence title, IntentSender sender)` which requires API level 22. Closes #5904 Differential Revision: D3612889 fbshipit-source-id: 0e7aaf34b076a99089cc76bd649e6da067d9a760
Reviewed By: majak Differential Revision: D3610634 fbshipit-source-id: 1dc9017c0a34ced231b5bebe334591f3d0b89bf3
Summary: Thanks for submitting a pull request! Please provide enough information so that others can review your pull request: > **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.** (You can skip this if you're fixing a typo or adding an app to the Showcase.) Explain the **motivation** for making this change. What existing problem does the pull request solve? I'm new to React-Native and noticed a broken link in the documentation. It's just a quick fix. Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it. **Test plan (required)** Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. Make sure tests pass on both Travis and Circle CI. **Code formatting** Look around. Mat Closes #8982 Differential Revision: D3612982 fbshipit-source-id: 2996730e51ae7a243697f305cd2ed2eb0d2985a8
Summary:
`./scripts/run-android-local-unit-tests.sh` raise error
```
05: error: cannot access com.facebook.react.bridge.CatalystInstance
verify(mCatalystInstanceImpl).loadScriptFromOptimizedBundle(
^
class file for com.facebook.react.bridge.CatalystInstance not found
```
and this PR fix it.
Closes #8957
Differential Revision: D3613491
Pulled By: bestander
fbshipit-source-id: 53b52fca13482e6474d7ffec9c19c0e7d6e4d100
Summary: The links was a mix of W3Schools, CSS-Tricks and MDN. Everything is now a MDN link now. [Why?](http://www.w3fools.com/) Closes #9005 Differential Revision: D3613520 fbshipit-source-id: 86585613a822a9027f42b61ac5d0abb7c351fa80
Summary: Hi folks ! 🔧 Fix the navigation card stack pan responder when the `vertical` direction is enabled. **Issue:** When using a `ScrollView` with the `vertical` direction enabled, the pan handler catch the gesture before the `ScrollView`. I don't know why there was no default value here for `RESPOND_POSITION_MAX_VERTICAL` 5162eb3 ericvicenti could you tell me what you think about setting a default value for `RESPOND_POSITION_MAX_VERTICAL` ? 😃 Thanks !! **EDIT June 15, 2016** I'll update this PR this week end to provide a way to give custom values as there is no magic value for `RESPOND_POSITION_MAX_VERTICAL` **EDIT June 24, 2016** I've added a props `gestureResponseDistance` to control both the `RESPOND_POSITION_MAX_VERTICAL` and `RESPOND_POSITION_MAX_HORIZONTAL` Closes #8076 Differential Revision: D3605973 Pulled By: ericvicenti fbshipit-source-id: 158d88cf8ebbab742bf0b38c217ae502e9dd1963
Reviewed By: mhorowitz Differential Revision: D3507905 fbshipit-source-id: cbe55495a991bf6eef961319ba8b219e660dce05
Summary: lineBreakMode only in rc so I think we can replace property without any deprecation warnings. satya164 Closes #9008 Differential Revision: D3614901 fbshipit-source-id: 724227c0a89192825a24850b930b80884571a51f
Fanghao
pushed a commit
that referenced
this pull request
Sep 14, 2016
Summary: > It also must be useful considering that the majority of readers only speak English. So, each app in the showcase should link to either: 1/ An English-language news article discussing the app, built either by a funded startup or for a public company 2/ An English-language technical post on a funded startup or public company blog discussing React Native For each app in the showcase, use infoLink and infoTitle to reference this content. - We wrote a technical post on [medium](https://engineering.huiseoul.com/building-a-conversational-e-commerce-app-in-6-weeks-with-react-native-c35d46637e07#.776ll9ram) - My company was funded, also. Reference [#1](http://besuccess.com/2015/08/huiseoul/), [#2](https://www.crunchbase.com/organization/trillionaire#/entity) Closes facebook#9807 Differential Revision: D3843024 Pulled By: lacker fbshipit-source-id: d76b2996f8aade42923d268f9308ae8796364083
SEAPUNK
pushed a commit
that referenced
this pull request
Sep 20, 2017
Summary: A blog post with notes from the first React Native monthly meeting. I've gathered notes after the meeting in this blog post. Think it might be useful for a broader audience in React Native community. No test plan, submitting just a documentation file. cc hramos ericvicenti Closes facebook#14665 Differential Revision: D5294423 Pulled By: hramos fbshipit-source-id: be7641622902cda47f391a2364e0f5aac45403ea
adgarcia
pushed a commit
that referenced
this pull request
Apr 23, 2019
Summary: In D14571128, we made it so that when a JS object's property was `undefined`, we wouldn't insert that property into the corresponding NSDictionary. Here are two important observations about that diff: 1. ALL JS `null`s were now being converted to `NSNull`, and JS `undefined`s were now being converted to `nil`. 2. If a JS object's property was explicitly `null`, then we'd insert `NSNull` into the corresponding dictionary. Considering that when a property doesn't exist in a `NSDictionary`, property access returns `nil`, I've made it so that if a JS object's property is either `null` or `undefined`, then we simply do not insert it in the corresponding `NSDictionary`. Also, I've reverted #1 and made it so that `undefined` and `null` always map to the ObjC `nil`. This shouldn't unfix the problem that D14571128 was trying to fix. Here's my understanding of the problem that D14571128 was trying to fix (to make sure I'm not breaking something by this diff). This method was invoked from JS. ``` RCT_EXPORT_METHOD(logEvents:(NSDictionary *)events) { RCTAssert(events, @"You should provide events for logger"); [[NSNotificationCenter defaultCenter] postNotificationName:@"FBReactPerfLoggerDidReceiveEventsNotification" object:nil userInfo:@{@"FBReactPerfLoggerUserInfoPerfEventsKey" : [events copy]}]; } ``` The above dispatch calls into this method, which appends `events` into `_pendingJSPerfEvents`. ``` - (void)reactPerfLoggerDidReceiveEvents:(NSNotification *)notification { NSDictionary *events = notification.userInfo[@"FBReactPerfLoggerUserInfoPerfEventsKey"]; if (events) { dispatch_async(_eventQueue, ^{ if (self->_sessionData.perfLoggerFlagId != nil) { if ([self processJSPerfEvents:events]) { [self reportMetricsIfFinished]; } } else { [self->_pendingJSPerfEvents addObject:events]; } }); } } ``` Then, in `_processJSPerfEvents`, we do the following (link: https://fburl.com/tr4wr2a7): ``` NSNumber *actionId = events[@"actionId"]; if (actionId) { self->_sessionData.actionId = actionId; } ``` So, if `undefined` or `null` was passed in as the `actionId` property of the `events` JS object in `FBReactPerformanceLogger logEvents:`, then we'd default the `NSDictionary` to have `NSNull` in the corresponding property. This is bad because we had this line in FBReactWildePerfLogger (link: https://fburl.com/2nsywl2n): `actionId ? [actionId shortValue] : PerfLoggerActions.SUCCESS`. Essentially, this is the same problem that my diff is trying to fix. Reviewed By: fkgozali Differential Revision: D14625287 fbshipit-source-id: c701d4b6172484cee62494256175e8b205b23c73
jonwu
pushed a commit
that referenced
this pull request
Nov 24, 2020
Summary:
changelog: [internal]
Prevents 2 type converions:
1. int <-> size_t
2. int <-> int32_t
# Why is using size_t better when working with indexes.
## 1. Type conversion isn't for free.
Take this example
```
size_t calculate(int number) {
return number + 1;
}
```
It generates following assembly (generated with armv8-a clang 10.0.0):
```
calculate(int): // calculate(int)
sub sp, sp, #16 // =16
str w0, [sp, #12]
ldr w8, [sp, #12]
add w9, w8, #1 // =1
mov w8, w9
sxtw x0, w8
add sp, sp, #16 // =16
ret
```
That's 9 instructions.
If we get rid of type conversion:
```
size_t calculate(size_t number) {
return number + 1;
}
```
Assembly (generated with armv8-a clang 10.0.0):
```
calculate(unsigned long): // calculate(unsigned long)
sub sp, sp, #16 // =16
str x0, [sp, #8]
ldr x8, [sp, #8]
add x0, x8, #1 // =1
add sp, sp, #16 // =16
ret
```
Compiler now produces only 7 instructions.
## Semantics
When using int for indexing, the type doesn't say much. By using `size_t`, just by looking at the type, it gives the reader more information about where it is coming from.
Reviewed By: JoshuaGross
Differential Revision: D24332248
fbshipit-source-id: 87ef982829ec14906ed9e002ea2e875fda4a0cd8
stevenpetryk
pushed a commit
that referenced
this pull request
Nov 28, 2023
Summary: Pull Request resolved: facebook#41466 ## Context In open source, all apps use the same turbomodulemanager delegate (i.e: the default delegate). This diff introduces the buck infra that makes the oss default delegate work for meta apps. Concretely, we are going to make React Native use the same delegate for **all** Meta apps. Each Meta app will: 1. At build time, generate a unique TMProvider map 2. At app init time, initialize the default delegate with the TMProvider map. ## Implementation **Step #1:** At build time, generate a unique TMProvider map **Insight:** Buck genrules can accept, as input, the output of a buck query. So, here's how we get this done: 1. Buck query (i.e: input to Genrule): Given the app's deps, query all the schemas in the app. 2. Genrule: Read the schemas to generate the TMProvider map. The TMProvider map will also contain **all** the app's C++ module codegen. Concretely: 1. This diff introduces a macro: rn_codegen_appmodules(deps). 2. rn_codegen_appmodules(deps) generates appmodules.so, which contains the TMProvider map. **Step #2:** At app init time, initialize the default delegate with the TMProvider map. This is how we'll initialize the DefaultTurboModuleManagerDelegate: 1. DefaultTurboModuleManagerDelegate will load appmodules.so during init. 2. When loaded, appmodules.so will assign the code-generated TMProvider map to DefaultTurboModuleManagerDelegate. ## Impact This should allow us to: 1. Get one step closer to getting rid of the `js1 build turbomodule-manager-delegates --target <app>` script 3. Remove the TurboModuleManagerDelegate from React Native's public API. (Because we use one delegate for all React Native apps in Meta and OSS) Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D50988397 fbshipit-source-id: 0ca5dec14e2dae89ec97f5d39a182c7937c5c7bf
Flewp
pushed a commit
that referenced
this pull request
Feb 27, 2024
…gets Summary: Changelog: [Internal] # This diff 1. Provides all Targets with an `executorFromThis()` method, which can be used from within a Target to access a *`this`-scoped main thread executor* = a `std::function` that will execute a callback asynchronously iff the current Target isn't destroyed first. 2. Refactors how (all) Target objects are constructed and retained, from a plain constructor to `static shared_ptr create()`. This is because `executorFromThis()` relies internally on `enable_shared_from_this` plus two-phase construction to populate the executor. 3. Creates utilities for deriving scoped executors from other executors and `shared_ptr`s. The concept is very much like `RuntimeExecutor` in reverse: the #1 use case is moving from the JS thread back to the main thread - where "main thread" is defined loosely as "anywhere it's legal to call methods on Target/Agent objects, access session state, etc". The actual dispatching mechanism is left up to the owner of each `PageTarget` object; for now we only have an iOS integration, where we use `RCTExecuteOnMainQueue`. Coupling the ownership/lifetime semantics with task scheduling is helpful, because it avoids the footgun of accidentally/nondeterministically moving `shared_ptr`s (and destructors!) to a different thread/queue . # This stack I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts. Overall, this will let us: * Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object. * Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc). * Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance. The core diffs in this stack: * ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`. ~~ * ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`). ~~ * ~~Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`.~~ * ~~Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`.~~ * ~~Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.~~ * Provide RuntimeTarget with mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event. *← This diff* ## Architecture diagrams Before this stack: https://pxl.cl/4h7m0 After this stack: https://pxl.cl/4h7m7 Reviewed By: hoxyq Differential Revision: D53356953 fbshipit-source-id: 152c784eb64e9b217fc2966743b33f61bd8fd97e
hannomargelo
pushed a commit
that referenced
this pull request
May 20, 2025
…tion for existing view (facebook#51294) Summary: Pull Request resolved: facebook#51294 changelog: [internal] Fix a crash where a node that is supposed to be culled doesn't get visited because culling context is not updated. The differentiator would generate a create instruction for a view that already exists. Stack trace for the crash: ``` * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x0000000111740874 libsystem_kernel.dylib`__pthread_kill + 8 frame #1: 0x00000001117aa2ec libsystem_pthread.dylib`pthread_kill + 264 frame #2: 0x0000000180171ea8 libsystem_c.dylib`abort + 100 frame #3: 0x00000001802b0144 libc++abi.dylib`abort_message + 128 frame #4: 0x000000018029fe4c libc++abi.dylib`demangling_terminate_handler() + 296 frame #5: 0x000000018006f220 libobjc.A.dylib`_objc_terminate() + 124 frame #6: 0x00000001375d1964 INFRAFramework`meta_terminate() + 5468 frame #7: 0x00000001802af570 libc++abi.dylib`std::__terminate(void (*)()) + 12 frame #8: 0x00000001802b2498 libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 32 frame #9: 0x00000001802b2478 libc++abi.dylib`__cxa_throw + 88 frame #10: 0x0000000180093904 libobjc.A.dylib`objc_exception_throw + 384 frame #11: 0x0000000180e6999c Foundation`-[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 268 frame #12: 0x000000031a3bcfc8 XPLAT_6_Framework`-[RCTComponentViewRegistry dequeueComponentViewWithComponentHandle:tag:] + 528 frame #13: 0x000000031a3ccdec XPLAT_6_Framework`RCTPerformMountInstructions(std::__1::vector<facebook::react::ShadowViewMutation, std::__1::allocator<facebook::react::ShadowViewMutation>> const&, RCTComponentViewRegistry*, RCTMountingTransactionObserverCoordinator&, int) + 356 frame #14: 0x000000031a3ccc7c XPLAT_6_Framework`-[RCTMountingManager performTransaction:]::$_1::operator()(facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) const + 80 frame #15: 0x000000031a3ccc20 XPLAT_6_Framework`decltype(std::declval<-[RCTMountingManager performTransaction:]::$_1&>()(std::declval<facebook::react::MountingTransaction const&>(), std::declval<facebook::react::SurfaceTelemetry const&>())) std::__1::__invoke[abi:ne190102]<-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&>(-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 40 frame #16: 0x000000031a3ccbc8 XPLAT_6_Framework`void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ne190102]<-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&>(-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 40 frame #17: 0x000000031a3ccb94 XPLAT_6_Framework`std::__1::__function::__alloc_func<-[RCTMountingManager performTransaction:]::$_1, std::__1::allocator<-[RCTMountingManager performTransaction:]::$_1>, void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)>::operator()[abi:ne190102](facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 44 frame #18: 0x000000031a3cba1c XPLAT_6_Framework`std::__1::__function::__func<-[RCTMountingManager performTransaction:]::$_1, std::__1::allocator<-[RCTMountingManager performTransaction:]::$_1>, void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)>::operator()(facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 44 frame #20: 0x000000032f219804 XPLAT_1_Framework`std::__1::function<void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)>::operator()(this=0x000000016d4f0c78, __arg=0x000000016d4f0a10, __arg=0x000000016d4f0978) const at function.h:989:10 frame #21: 0x000000032f219668 XPLAT_1_Framework`facebook::react::TelemetryController::pullTransaction(this=0x00000003f4680f00, willMount=0x000000016d4f0c98, doMount=0x000000016d4f0c78, didMount=0x000000016d4f0c58) const at TelemetryController.cpp:39:3 frame #22: 0x000000031a3c5b28 XPLAT_6_Framework`-[RCTMountingManager performTransaction:] + 544 frame #23: 0x000000031a3c5864 XPLAT_6_Framework`-[RCTMountingManager initiateTransaction:] + 456 frame #24: 0x000000031a3c5240 XPLAT_6_Framework`__42-[RCTMountingManager scheduleTransaction:]_block_invoke + 308 frame #25: 0x0000000131f81b84 BOTTOMFramework`__RCTExecuteOnMainQueue_block_invoke + 40 frame #26: 0x000000018017c788 libdispatch.dylib`_dispatch_call_block_and_release + 24 frame #27: 0x0000000180197278 libdispatch.dylib`_dispatch_client_callout + 12 frame #28: 0x00000001801b2fcc libdispatch.dylib`_dispatch_main_queue_drain.cold.7 + 24 frame #29: 0x000000018018c1c4 libdispatch.dylib`_dispatch_main_queue_drain + 1184 frame #30: 0x000000018018bd14 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 40 frame #31: 0x0000000180427fec CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12 frame #32: 0x00000001804229f8 CoreFoundation`__CFRunLoopRun + 1920 frame #33: 0x0000000180421e3c CoreFoundation`CFRunLoopRunSpecific + 536 frame #34: 0x0000000190f62d00 GraphicsServices`GSEventRunModal + 164 frame #35: 0x0000000185bcec98 UIKitCore`-[UIApplication _run] + 796 frame #36: 0x0000000185bd3064 UIKitCore`UIApplicationMain + 124 frame #37: 0x0000000115fbf0bc PRODUCTFramework`main + 200 frame #38: 0x00000001114293d8 dyld_sim`start_sim + 20 frame #39: 0x0000000111506b4c dyld`start + 6000 ``` Reviewed By: rubennorte Differential Revision: D74654157 fbshipit-source-id: 9181bcd28524c71d0ca4620bd630dc0baa172386
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.