Summary:
Changelog: [internal]
`LayoutableShadowNode::findNodeAtPoint` was iterating children in incorrect order and wasn't taking zIndex into accout.
Reviewed By: JoshuaGross
Differential Revision: D23814866
fbshipit-source-id: 38eee297147a5c5912304d139bb10f8b16ae2ee1
Summary:
Now that the react-native-codegen produces the Android.mk for the JNI C++ output, let's compile them into its own shared library, to be included in the ReactAndroid final deliverable: libreact_codegen_reactandroidspec.so. This is gated behind `USE_CODEGEN` env var.
Note: RNTester specific C++ spec files are not compiled here.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809081
fbshipit-source-id: 7a90f420a923d5d02654facac01ffe025c321e44
Summary:
This adjusted the C++ output for Android codegen (NativeModule specs) so we can compile it with ndk-build in Gradle:
* Use `#include` instead of `#import` for header files
* Added `#pragma once`
* Removed direct include of `<fb/fbjni.h>` -- this is not necessary
* Added generated Android.mk file based on library name
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809082
fbshipit-source-id: 11ddfea7b48c8b2eb6efe885641ace4fc327d50d
Summary:
The current calculation on versionCodeOverride is not human-readable.
Imagine if we have an android app with **versionName** `4.0` and **version code** `4`.
In the current implementation, the result of **versionCode** `4` for `armeabi-v7a` will be the seemingly arbitrary **1048580**. This makes the version code to be seemingly arbitrary and hard to read for humans. This PR proposes to change this calculation closer to google implementation of build number in Flutter (`abiVersionCode * 1000 + variant.versionCode`).
39d7a019c1/packages/flutter_tools/gradle/flutter.gradle (L643-L647)
With this change, our app with `versionCode 4 versionName "4.0"` for `armeabi-v7a` will have **1004** as the version code instead of the seemingly arbitrary **1048580**. As you can see adopting the flutter style implementation make the version code easier to read and debug.
**1004**
**1** - The ABI Type `["armeabi-v7a": 1, "x86": 2, "arm64-v8a": 3, "x86_64": 4]`
**004** - Our versionCode.
Hopefully, this can prevent future issues like this https://github.com/facebook/react-native/issues/29790.
## Changelog
[Android] [Changed] - Making Android versionCodeOverride for new apps using the template human-readable
Pull Request resolved: https://github.com/facebook/react-native/pull/29808
Reviewed By: sammy-SC
Differential Revision: D23804632
Pulled By: fkgozali
fbshipit-source-id: 89b2c196b3bfe01fa608dfb595db6d3314ca1d63
Summary:
In this diff I simplify index adjustment and add comments to rigorously describe what we're doing at each step of index adjustment.
I've also made unflattening detection more correct, robust, and slightly more efficient.
Bugs that existed before:
1) The reparenting detection that existed in the animations layer had some subtle bugs. I don't have proof that it results in any correctness issues or crashes, but I suspect it.
2) Correctness of index adjustment: there were cases where the Android mounting layer would crash because LayoutAnimations would try to remove a View at an index, but the index was wrong. This is why I sat down and diagrammed the relationships between all the bits of data we have for index readjustment - I believe this to be correct now.
3) Correctness of INSERT index adjustment: I had the insight that when we have batches of INSERTs to consecutive indices, we essentially want them to be treated as a single INSERT for adjustment purposes, so that they're all placed consecutively in the view layer. I added `ConsecutiveAdjustmentMetadata` to deal with this, and there are more comments in the code.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23806163
fbshipit-source-id: cd9e94945034db8b840f2a806c6377034a91af61
Summary:
In the new Flattening differ, I experimentally verified that these two code paths are not hit (or redundant) and deleted them.
One of the branches did nothing and the other produced duplicate DELETE mutations for the same tag, that is handled elsewhere.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23806161
fbshipit-source-id: 9ad2929e2d719a7b9b34640ed35f7a696103604b
Summary:
This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS.
New shared libs:
* libreact_nativemodule_core.so: The TurboModule Android core
* libreact_nativemodule_manager.so: The TurboModule manager/delegate
To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23805717
fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9
Summary:
Changelog: [internal]
In D23648430 (a315e4cd30) I made a mistake. I prevented calling `onTextLayout` unless there are attachments in the component. It fixed the problem because I unintentionally prevented `onTextLayout` to be called. Therefore, changes from D23648430 (a315e4cd30) need to be reverted.
To prevent infinite loop in `onTextLayout`, ParagraphEventEmitter checks if `linesMeasurements` have changed before dispatching it to JS.
Reviewed By: shergin
Differential Revision: D23782717
fbshipit-source-id: 0e84ae4f46d79ce0cf4c7340cd32be6f562ae179
Summary:
In a previous recent diff we changed Android's Delete mount instruction to *not* recursively delete the tree. This is fine, but because of that, we stopped calling `onDropViewInstance` when views are normally deleted.
Bring back that behaviour.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23801666
fbshipit-source-id: 54e6b52ab51fff2a45102e37077fe41081499888
Summary:
This diff moves the code of TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule
For iOS: Pod spec name stays as "ReactCommon/turbomodule/..." for now, only the source/header location is affected. The target will be renamed/restructured closer to TurboModule rollout.
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D23362253
fbshipit-source-id: c2c8207578e50821c7573255d4319b9051b58a37
Summary:
Exceptions in C++ work quite differently from exceptions in other languages. To make exceptions actually work **correctly** all the code needs to be written with "exceptions in mind" (e.g., see https://www.stroustrup.com/except.pdf). In short, if the code is not "exceptions ready", throwing an exception causes memory leaks, dangling pointers, and invariant violations all over the place, which will probably cause another crashes down the road (which will be especially hard to investigate and attribute to the original issue).
Fabric Core (Layout, Props parsing, ShadowNodes management, and so on) does not use exceptions because in most (all?) the cases the exception is now recoverable. So, if a program detects some internal state invariant violation or missing some resource, *logically* it's fatal. We also don't want to pay code-size and performance tax for exception support, so that's why we don't use them. It's just not the right fit for Fabric Core.
This does not mean that exceptions don't happen though. C++ standard library can throw them... sometimes. And if our library is compiled with exceptions enabled (still the case, unfortunately), an exception can bubble to JavaScript code and losing all context down the road. And it's hard to investigate such crashes. To isolate those occasional exceptions inside C++ core we are marking all C++/JS boundaries with `noexcept` that stops the bubbling.
I hope that will give us much more informative crash reports.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23787492
fbshipit-source-id: 0822dbf36fc680c15b02b5cd0f2d87328296b642
Summary:
This is a revert of D23529233 (902611f148).
It turns out it was a bad idea. With this catch-all thing, we don't get new information. Yeah, we crash earlier now but seems we have even less information about the crash. :(
I think D23754284 (04c874bd9c) should fix the issue.
Changelog: [Internal] Fabric-specific internal change.
Original commit changeset: 7ac7fb26ac08
Reviewed By: sammy-SC
Differential Revision: D23786086
fbshipit-source-id: 86784df0193abfb7328c4d5a16a9af4214e9a161
Summary:
See additional assertion. Tests still pass, so no other change was necessary.
Changelog: [Internal]
Differential Revision: D23775553
fbshipit-source-id: 57d3191f25dd55ab4da189207f6d201a31b175e0
Summary:
Because BatchMountItem executes many items, sometimes it's unclear which MountItem causes a crash. Catch and log the exact item.
This shouldn't cause perf regressions because we have a try/catch block in FabricUIManager where execute is called.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775500
fbshipit-source-id: c878e085c23d3d3a7ef02a34e5aca57759376aa6
Summary:
There are cases where we Delete+Create a node in the same frame. Practically, the new differ should prevent this, but we don't want to rely on that necessarily.
See comments for further justification on why deleteView can do less work overall.
In reparenting cases, this causes crashes because dropView removes *and deletes* children that shouldn't necessarily be deleted.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775453
fbshipit-source-id: c577c5af8c27cfb185d527f0afd8aeb08ee3a5fe
Summary:
The current Flipper version included in new React Native is quite old, causing some bugs to be present which have long been solved, such as freezing the UI after inspecting it.
Fixes
This fixes https://github.com/facebook/react-native/issues/29492 /
https://github.com/facebook/flipper/issues/1399
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[general][changed] - Update Flipper to 0.54
Pull Request resolved: https://github.com/facebook/react-native/pull/29787
Test Plan:
Updated the RN 0.63.2 based test project https://github.com/mweststrate/flipper-issue-1399-repo with `use_flipper!('Flipper' => '0.54.0')` (in `ios/Podspec`) / `FLIPPER_VERSION=0.52.1` in `gradle.properties` in the test project https://github.com/mweststrate/flipper-issue-1399-repo and verified that everything builds and connects correctly, and that the bug is no longer present.
Tried to run RN-tester project in this repo. For iOS this succeeded, on Android I got a build error:
```
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
fcntl(): Bad file descriptor
[armeabi-v7a] Compile++ thumb: folly_json <= FileUtil.cpp
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/FileUtil.cpp:37:14: error: no matching function for call to 'wrapNoInt'
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
return int(wrapNoInt(open, name, flags, mode));
^~~~~~~~~
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/detail/FileUtilDetail.h:34:9: note: candidate template ignored: couldn't infer template argument 'F'
ssize_t wrapNoInt(F f, Args... args) {
^
1 error generated.
make: *** [/opt/android_sdk/ndk/21.3.6528147/build/core/build-binary.mk:478: /Users/mweststrate/Desktop/react-native/ReactAndroid/build/tmp/buildReactNdkLib/local/armeabi-v7a/objs/folly_json/folly/FileUtil.o] Error 1
make: *** Waiting for unfinished jobs....
fcntl(): Bad file descriptor
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
[armeabi-v7a] Compile++ thumb: folly_json <= Demangle.cpp
```
No idea if it is related. I guess not since without making the change I got the same error.
Reviewed By: mweststrate
Differential Revision: D23767388
Pulled By: fkgozali
fbshipit-source-id: 35f0d3ddec41942f5bbc96cb391975d84729ef5e
Summary:
Continuing the adding of a "cause" field for logging to GCs.
This allows embedders of Hermes (such as React Native) to specify
the cause of a call to `collectGarbage`.
Notably, this allows Hermes to know when a GC is triggered by a memory warning.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23742099
fbshipit-source-id: 99453e632328c00045b92a72f789d41c898dc518
Summary:
This flag was deleted in D23374948 (6729a3e0bf), reintroduce it.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23771273
fbshipit-source-id: ae9595194bf14bc740d05b2ca6e7b5e22bdd566f
Summary:
The `description` parameter is never used so we can simplify the API.
Changelog:
[Internal][Changed] Removed `description` option from performance logger timespans
Reviewed By: lunaleaps
Differential Revision: D23758829
fbshipit-source-id: 10900f86effc3e1f54a408cf8f9fbc9b3b52f569
Summary:
The way the performance logger is defined now is very unsafe regarding type safety, as all accesses to its properties is untyped (`any`) and it uses several `mixed` types in cases that could be more refined.
This migrates the creation of performance loggers to instances of a class to improve its type safety. If there's an impact in performance, it's expected to be positive.
Changelog:
[Internal][Changed] - Replaced object literals with class instances to create performance loggers
Reviewed By: lunaleaps
Differential Revision: D23758609
fbshipit-source-id: 0734742eb97d92a4a53f7b66a8ca45a2ae90946c
Summary:
Inside JavaTurboModule, the native `CallInvoker` is used to schedule work on the NativeModules thread. So, in ~JavaTurboModule(), I scheduled some work on the NativeModules thread. This work holds a copy of the JNI global reference to the Java NativeModule object, and when it's executed, it resets this global reference to the Java NativeModule object. This should ensure that the we don't access the JVM in ~JavaTurboModule, which could crash the program.
I also removed the redundant `quitSynchronous()` in `~CatalystInstanceImpl()`, to prevent the NativeModules thread from being deleted before we delete the `jsi::Runtime`. This shouldn't cause an issue, because we delete the NativeModules thread when we call [ReactQueueConfigurationImpl.destroy()](https://fburl.com/codesearch/p7aurwn3).
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D23744777
fbshipit-source-id: a5c8d3f2ac4287dfef9a4b4404a04b335aa0963d
Summary:
This enables a new state auto repeating mechanism built-in mechanism for all state updates which we already use for CK interop. This experiment is supposed to help with T74769670 and co.
This change is gated with MC.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23762508
fbshipit-source-id: f535513c724ace9ede570177281324eb507329c5
Summary:
Use the latest published release of hermes-engine.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.7.0
allow-large-files
Reviewed By: cpojer
Differential Revision: D23725129
fbshipit-source-id: 50938433147100e97699b717d77a687fbbfe892b
Summary:
The Apple documentation states: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Blocks/Articles/bxUsing.html#//apple_ref/doc/uid/TP40007502-CH5-SW1
> Typically, you shouldn’t need to copy (or retain) a block. You only need to make a copy when you expect the block to be used after destruction of the scope within which it was declared. Copying moves a block to the heap.
All blocks generated in the TurboModule infra, for callbacks and promise resolve/reject handlers, can be used after the destruction of the scope within which they were declared. Therefore, let's copy them in the hopes that they mitigate T75876134.
**Note:** We copy blocks before pushing them into the `retainedObjects` array in the legacy Infra as well. Context: D2559997 (71da2917e5), D5589246 (2a6965df90)
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23764329
fbshipit-source-id: e71360977bdff74dc570bd40f0139792860f811f
Summary:
Under Fabric only, we can enter an infinite layout loop where the emitted layout event oscillates between two height values that are off by a very small amount.
The cause is, in part, components that use layoutEvents to determine their dimensions: for example, using onLayout event "height" parameters to determine the height of a child. If the onLayout height changes rapidly, the child's height will change, causing another layout, ad infinitum.
This might seem like an extreme case but there are product use-cases where this is done in non-Fabric and layout stabilizes quickly. In Fabric, currently it may never stabilize.
Part of this is due to a longstanding issue that exists in Fabric and non-Fabric, that we cannot immediately fix: If in a single frame, C++ emits 100 layout events to ReactJS, ReactJS may only process 50 before committing the root. That will trigger more layout events, even though product code has only partially processed the layout events. At the next frame, the next 50 events will be processed which may again change the layout, emitting more events... etc. In most cases the tree will converge and layout values will stabilize, but in extreme cases in Fabric, it might not.
Part of this is because Fabric does not drop *stale* layout events. If 10 layout events are dispatched to the same node, it will process all 10 events in older. Non-Fabric does not have this behavior, so we're changing Fabric to drop stale events when they queue up.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23719494
fbshipit-source-id: e44a3b3e40585b59680299db3a4efdc63cdf0de8
Summary:
LayoutAnimations: at the end of every animation, issue an update mutation - this is so that the props data on the Mounting layer/StubViewTree layer is pointer-identical to the props data on the ShadowTree.
This unblocks iOS debug mode crashes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23753606
fbshipit-source-id: 407e0c2746a65e6d3ee29c1cce891cd7c1013593
Summary:
iOS needs this function to be marked as static.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D23749613
fbshipit-source-id: a8c160646853450fc7d849448bdbb45e02beb964
Summary:
Currently, MountingCoordinator's RN_SHADOW_TREE_INTROSPECTION code will crash often because it assumes there is always a "new" tree to compare the old tree to. In the LayoutAnimations context this is not always the case - in fact, the majority of the time, LayoutAnimations is producing mutations for animation without a "new" tree.
Just check that the tree exists before trying to print it.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23747289
fbshipit-source-id: a1ba22aeae32ed8915a53bc33cdc199e8ce5128a
Summary:
In MountingCoordinator override mode (used in LayoutAnimations) we must set the start and end `diff` time when no real diff happens, otherwise we will hit an assert in telemetry later.
I also ensure that the TransactionNumber is incremented in that case.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23746684
fbshipit-source-id: b1fe3864e453fdba89d43cc827bd37434abf7a4d
Summary:
`adjustDelayedMutationIndicesForMutation` asserts that the mutation is either Remove or Insert. At one callsite, we weren't checking the mutation type before calling `adjustDelayedMutationIndicesForMutation`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23746617
fbshipit-source-id: 6046fec2eb4821094937b1b16f40347bbc55c20e
Summary:
This change maps the three most used colors (black, white, clear) to corresponding predefined values in UIColor. This should meaningfully reduce the overall amount of allocated UIColor/CGColor objects. In my non-scientific measures, it reduces the number of CGColor objects from ~1500 to ~1000. And... it no much at least in terms of kilobytes. However, I still think it's a good idea to implement this because I hope that can remove some work from memory allocation infra and maybe enable some optimizations that UIKit hopefully does for black and white colors. (I tend to believe that this optimization exists because UIKit even has a classes called UIDeviceWhiteColor and UICachedDeviceWhiteColor.)
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753506
fbshipit-source-id: 46e58dc7e6b0dcab3c83d29c7257c90ffbd95246
Summary:
Finally, this diff changes the internal implementation of SharedColor to be `optional<int>`.
Initially, when we started working on the new renderer, it seemed like a good idea to allocated CGColor objects ahead of time and store them with Props. Now, this idea does not look so good, especially because:
* Having `SharedColor` as a `shared_ptr` is a quite big perf overhead for copying this thing. And the size of the object is not small.
* Having `SharedColor` as a `shared_ptr` creates huge interconnectedness among pieces of the core and rendering. E.g. improper releasing a pointer in some component view can cause a crash somewhere in the core (because both places might use the same shared `blackColor`.
On Android, we already use simple `int` as a representation of a color, and this works great. And this diff implements something very similar to Android, but a bit differently: here we use `optional<int>` instead of custom class with a single `int` field and some magic value that represents "empty value".
This approach should fix T75836417 because now we don't have allocation and deallocation when we simply assign color values.
If this solution works fine on iOS, I will do unify all implementations among all platforms.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753507
fbshipit-source-id: 42fd6cee6bf7b39c92c88536da06ba9e8cf4d4db
Summary:
This diff changes the implementation of `RCTCreateCGColorRefFromSharedColor` and `RCTUIColorFromSharedColor` in such a way that they don't rely on the fact that SharedColor is actually a `shared_ptr<CGColorRef>`. Instead, the methods just extract color components from SharedColor and create UIColor and CGColorRef objects on demand.
This allows us to change the implementation of SharedColor without worrying much about the rest of the system, which will do in the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753510
fbshipit-source-id: 340127527888776ebd5d241ed60c7e5220564013
Summary:
Even though we have wonderful helper functions converting SharedColor to UIColor and CGColorRef, in many places we still use some hardcoded things. This diff fixes that; it will be important for the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753508
fbshipit-source-id: 09d280b132266252753526c2735ab3e41b96c8d5
Summary:
This diff removes `RCTCGColorRefUnretainedFromSharedColor` function because it's not compatible with future changes we plan to make.
Converting SharedColor to unretained CGColorRef is actually quite dangerous because... it's an unowned pointer.
Reviewed By: JoshuaGross
Differential Revision: D23753509
fbshipit-source-id: df030ade69b63cbb872d6bdbde51575eedc6a4a6
Summary:
Added an explicit NDK version to the Android template. This allows tooling to detect which NDK version to install automatically.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Added] - Add an explicit NDK version to Android template
Pull Request resolved: https://github.com/facebook/react-native/pull/29403
Test Plan: Template builds as it should. NDK version gets installed with initial Android set up.
Reviewed By: passy
Differential Revision: D23752007
Pulled By: fkgozali
fbshipit-source-id: 31c33f275f94a4a62338a61e79b31c4b996969bf
Summary:
We don't need a shared_ptr here and without it the code will be faster and simpler.
This change is aligned with any clone-line callbacks we have in the Core which accepts a `const &` and return `shared_ptr<>`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D23725687
fbshipit-source-id: 1cd959f4273913175d342302e2f12752f0114768
Summary:
Previously, to get a current root shadow node for a shadow tree, we called `tryCommit` method and stole a pointer from this. That was not a very straightforward method to get things done, and most importantly we need to do this to change the shape of the ShadowTreeCommitTransaction signature (remove a shared pointer from the callback) to make it simpler, faster and allow future improvements (see the next diff).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D23725689
fbshipit-source-id: 51950b843a0e401828b6c6a38e5e2aaaf21ec166
Summary:
Instead of storing tree separate instance variables, we now store a single object that contains them. We will need it to be able to postpone the mounting stage (we save all info we need for mounting inside the new instance variable).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23725690
fbshipit-source-id: 09dd4a0912c6f5b34d805636b62f73ca12287329
Summary:
The implementation of this class is too complex for the purpose it serves. Making it simpler will make the code simpler and faster.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23725688
fbshipit-source-id: 5e1ecddb0dd3c4c4f94786e2ba0af9b67e7426ce
Samuel Susla
Kevin Gozali
Agastya Darma
Andrei Shikov
generatedunixname89002005287564
Mike Vitousek
Joshua Gross
Valentin Shergin
Michel Weststrate
Riley Dulin
Rubén Norte
Ramanpreet Nara
Xuan Huang
Jason Safaiyeh