Summary:
Build `FBReactNativeSpec.h` and `FBReactNativeSpec-generated.mm` using the new codegen script whenever the workspace is created using CocoaPods if the `USE_CODEGEN` envvar is set to 1.
Effectively makes use of the new codegen integration in CocoaPods opt-in.
The `USE_CODEGEN` envvar check should be removed when the generated files are removed from source control, at which point use of the new codegen in CocoaPods will be necessary.
```
cd RNTester
USE_CODEGEN=1 pod install
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22250128
fbshipit-source-id: 8f06bf1424ca2e003ecfd032ec03d7896569f9bd
Summary:
This introduces a new shadow node trait (`Hidden`) which disables emitting ShadowVides for such nodes and all their descendants.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22134220
fbshipit-source-id: 8ea1fc3186019005ad687eacaca0ba4a4d8343dc
Summary:
The change contains a bunch of additional asserts that verify some assumptions on which mounting relies on. Working on the previous diffs I realized that it's very easy to broke those and then spend hours trying to understand what exactly went wrong.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22324087
fbshipit-source-id: 1152c40248885d02bde62a493a574868c3732273
Summary:
In RN 0.62 support for `fontVariant` was added on Android.
Using that prop crashes the app on Android below KitKat (4.3 and below)
To reproduce just add any Text with the `fontVariant` styling prop in the app:
```js
<Text style={{fontVariant: ['tabular-nums']}}>This will crash</Text>
```
It will crash any device running Android below KitKat with the error:
This is caused by `java.utils.Objects` only being available on Android 4.4+
## Changelog
[Android] [Fixed] - Fix font variant crash on Android < 4.4
Pull Request resolved: https://github.com/facebook/react-native/pull/29176
Test Plan:
[TextUtils.equals](https://developer.android.com/reference/android/text/TextUtils#equals) was added as soon as API level 1, so no compatibility issue here.
Tested on Emulator running Android 4.1, no crash anymore.
I've searched for other occurences of `java.utils.Objects` in the project, and this was the only one, so no need to remove other occurences ✅
Reviewed By: JoshuaGross
Differential Revision: D22337316
Pulled By: mdvacca
fbshipit-source-id: 5507b21b237a725d596d47b5c01e269895b16d4a
Summary:
This is the first implementation stage of on-demand child views mounting for <ScrollView> feature.
It works this way. When mounting layer requests mounting of a subview of <ScrollView>, the component does not mount it immediately. Instead, it stores it in an internal collection, and then after the transaction finishes use that to mount views that are in a visible area.
Then we re-evaluate which child views are should be mounted and unmounted on every significant onScroll event. We use some leeway to do it not so often to save CPU cycles on scrolling.
This feature already works fine but to make it shippable we need to integrate it with an `overflow inset` feature to make it 100% reliable in complex cases when some views have overflow content.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22304012
fbshipit-source-id: be4ae21378d9d1c457cad2826da7d8c8d6395be5
Summary:
In https://github.com/facebook/react-native/commit/0b63c9464872fed9ff3eb388e32850f2f8c69561, I shipped "Early ViewCommand Dispatch" everywhere but didn't provide a good summary in the commit message.
Here it is:
The "Early ViewCommand Dispatch" experiment was a success, leading to improved UI responsiveness and fewer overall crashes.
Ship to all Fabric and non-Fabric users, and clean up the code a bit.
# Context: what?
ViewCommands are now used in React Native to do things like scroll ScrollViews to a certain position; focus or blur a TextInput; control the value of controlled TextInputs; and much more. These used to be done using setNativeProps, but we're moving everything to ViewCommands, and most of that migration has already finished.
# Context: Why?
Because Fabric does not support setNativeProps, there has been an effort to move all setNativeProps callsites to ViewCommands. Since these callsites are in JS where we can't tell if we're running in Paper or Fabric, both Paper and Fabric callsites are being migrated (mostly already done) to ViewCommands. One such example is Android TextInput, which has been using ViewCommands instead of setNativeProps for several months.
This migration was largely without issues, except TheSavior and I noticed early on that certain things were just... slower with ViewCommands. It was definitely noticeable, but we determined it to be acceptable and moved on.
Recently, it became clear to me that the perf regression may not be acceptable, but there might be an "easy" solution.
# Why are ViewCommands slower than SetNativeProps?
So, a couple things. SetNativeProps on Paper would actually cause a layout pass; the same is not true for ViewCommands, so they should actually be much faster. But they're not! The reason is that ViewCommands are treated as regular mount items, and they are queued up /after/ all other mount items. That means if you're trying to interact with the UI while some part of it is updating, your ViewCommands must wait for portions of the screen to finish rendering before they execute.
In some cases, those views may even disappear before the ViewCommand executes, causing increased exceptions as well as speed degredations.
# Proposal
This experiment that ran with successful results was: to execute ViewCommands /before/ all other types of mount instructions (by maintaining a separate queue). That means if you tap on a TextInput to focus it while the screen is doing some heavy rendering, the next time the UIManager executes a batch of instructions, it will execute the focus operation out-of-order, at the very beginning. From a user perspective this is actually quite noticeable, and works much better than the older behavior.
# Why it's Not That Dangerous
* Is it possible that we'll execute instructions after the corresponding view has disappeared? This was already possible, and is actually less likely now, since it's more likely that the ViewCommand will execute before the Delete instructions executes.
* Is it possible we'll execute instructions BEFORE the view is created? Yes, this is possible and I actually found a repro for it. My solution: allow ViewCommands to be retried, exactly once. If they throw an exception the first time, we requeue which will cause the command to be executed after the current batch of mount items. Interestingly, this seems to be unnecessary in Fabric, so the logic there is a bit simpler (probably because on Android we do view preallocation under Fabric, so views are created way before they're inserted into the view hierarchy, and apparently before ViewCommands have a chance to execute).
* ViewCommands are already an imperative feature that exists outside of the normal React commit cycle. So they're already dangerous. This doesn't change that, but it does make dangerous code *faster*, so that's good.
Changelog: [Android][Changed] ViewCommands on Android now execute earlier, as a perf optimization.
Reviewed By: mdvacca
Differential Revision: D22343648
fbshipit-source-id: 310d94977ac8ca3140ee8aa272272f660efafa36
Summary:
Changelog: [Internal]
I had to update the types-first flags in the giuthub flowconfigs because they are removed in 0.128. I updated the snapshot test as well
allow-large-files
Reviewed By: mroch
Differential Revision: D22336797
fbshipit-source-id: ebeb0c05479d2dac69a66645d042d5671453f5e8
Summary:
The current parser behavior flattens out any object type aliases into ObjectTypeAnnotations. Generators can treat these as regular objects and generate the applicable native code. This, however, can lead to repetition whenever an object type alias is re-used in the same native module.
I propose we treat these as a special case, using a TypeAliasTypeAnnotation to denote them as type aliases. Generators can look up the actual signature for a given object alias by referring to the "aliases" array that is provided in the schema.
**Proposed schema change:**
Adds an "aliases" key to each module in the schema:
```
export type NativeModuleShape = $ReadOnly<{|
properties: $ReadOnlyArray<NativeModuleMethodTypeShape>,
aliases: $ReadOnlyArray<{|
name: string,
typeAnnotation:
| $ReadOnly<{|
type: 'ObjectTypeAnnotation',
properties: $ReadOnlyArray<ObjectParamTypeAnnotation>,
|}>
| $ReadOnly<TypeAliasTypeAnnotation>,
|}>,
|}>;
```
Example:
```
{
modules: {
SampleTurboModule: {
nativeModules: {
SampleTurboModule: {
aliases: [],
properties: [],
},
},
},
},
}
```
Method parameters will now support the new 'TypeAliasTypeAnnotation' wherever a param might have used a 'ObjectTypeAnnotation':
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22200700
fbshipit-source-id: 15684620783c752f2fb482ba4b88d1fd1cc07540
Summary:
(1) As soon as we know we can StopSurface, stop executing all mountitems by clearing out the root tag.
(2) If a surface has been stopped and there's a batch of MountItems to execute against it, execute only the "delete" operations to clear views from memory.
Both of these should reduce memory usage and improve speed slightly around navigation pops.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22321389
fbshipit-source-id: 96a8292a8442528f1bba50d35208885cc4168170
Summary:
While in theory we should never delete views before removing them from the hierarchy, there are some exceptions:
(1) Some mysterious cases that don't seem like bugs, but where the child still seems to keep a reference to the parent:
(2) When deleting views as part of stopSurface.
On #1: in the past we had issues when we assumed that ViewManager.getChildCount() would return an accurate count. Sometimes it's just... wrong. Here, I've found at least one case where a View still has a parent after it's removed from the View hierarchy. I assume this is undocumented Android behavior or an Android bug, but either way, there's nothing I can do about it.
On #2: there are valid cases where we want to delete a View without explicitly removing it from the View hierarchy (it will eventually be removed from the hierarchy when the Root view is unmounted, but it may still be "in" a View hierarchy when it's deleted).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22321374
fbshipit-source-id: 9667bbe778c418f0216550638dc26ca48a58e5fa
Summary:
The Hermes inspector always logged the message for `console.assert`.
It instead should check the first argument, and only if that argument
is false should it log.
Also remove the polyfill code that tried to avoid this situation.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D22299186
fbshipit-source-id: cdf4f8957d4db3d171d6673a82c7fc32b7152af3
Summary:
Splits the codegen script into functions, and makes use of $YARN_BINARY for portability (defaults to `yarn` if not provided).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22148360
fbshipit-source-id: 9e86b3e0f7f77bf3a635bf6be204170333dd5e65
Summary:
Moving property handling functions to their own properties.js file. No changes other than adding types to params.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22208243
fbshipit-source-id: 4a7d2c6e19c151954da793d399af9a256a4a40b7
Summary:
These flags haven't been used in months. They were useful to uncover some race conditions, but will not be iterated further. The Venice project will obviate the concerns that sparked these experiments in the first place.
These flags have been hardcoded to false for a while.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22319204
fbshipit-source-id: 09415f3bb1ca56e15f357210e966d0483ff384f2
Summary:
According to our experiments it's not better than "stop surface on unmount" in any way, and might regress some metrics. Unclear why, but if it's not necessary and doesn't seem to help, it doesn't make sense to continue this experiment.
We still have a mechanism on the C++ side to stop outstanding surfaces on teardown that does the same thing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22318864
fbshipit-source-id: 7e678c63e4884382e57d996a7f4c4b7b24c8193a
Summary:
Changelog: [Internal]
Do not log warning for "Invalid view set to be the JS responder".
{F242140509}
Fabric doesn't store views in view registry, therefore this warning would be shown to the developer everytime `[RCTUIManager setJSResponder]` is called.
Reviewed By: shergin
Differential Revision: D22309447
fbshipit-source-id: cac8985cdc79ab2d03a246cc2d9377472a64a683
Summary:
motivation: I was just checking out https://github.com/facebook/react-native/commit/30cc158a875a0414cf53d4d5155410eea5d5aeea
and noticed that the commit, I believe, is missing logic for when `contentOffset` is actually `null`.
That is, consider you render `ScrollView` with `contentOffset` { x: 0, y: 100 } and then change that to null / undefined. I'd expect the content offset to invalidate (set to 0 - hope that's the default).
## 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] [Fixed] - ScrollView, HorizontalScrollView: do not ignore `null` `contentOffset` prop
Pull Request resolved: https://github.com/facebook/react-native/pull/28760
Test Plan:
Tested locally within RNTester
<details><summary>code</summary>
<p>
```js
const Ex = () => {
let _scrollView: ?React.ElementRef<typeof ScrollView> = React.useRef(null);
const [offset, setOffset] = React.useState({x: 0, y: 20});
setTimeout(() => {
setOffset(undefined);
}, 2000);
return (
<View>
<ScrollView
ref={_scrollView}
automaticallyAdjustContentInsets={false}
onScroll={() => {
console.log('onScroll!');
}}
contentOffset={offset}
scrollEventThrottle={200}
style={styles.scrollView}>
{ITEMS.map(createItemRow)}
</ScrollView>
<Button
label="Scroll to top"
onPress={() => {
nullthrows(_scrollView.current).scrollTo({y: 0});
}}
/>
<Button
label="Scroll to bottom"
onPress={() => {
nullthrows(_scrollView.current).scrollToEnd({animated: true});
}}
/>
<Button
label="Flash scroll indicators"
onPress={() => {
nullthrows(_scrollView.current).flashScrollIndicators();
}}
/>
</View>
);
};
```
</p>
</details>
Reviewed By: shergin
Differential Revision: D22298676
Pulled By: JoshuaGross
fbshipit-source-id: e411ba4c8a276908e354d59085d164a38ae253c0
Summary:
The method does not do anything besides calling a super method. Even if this method does nothing special, overriding it can have negative performance implications.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22309895
fbshipit-source-id: bd8237d15df20017629223f278b1b6ac628b0cc7
Summary:
It's a Yoga specific feature that does not need to exposed as LayoutableShadowNode.
Removing this we save many virtual calls and add simplicity.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22304717
fbshipit-source-id: f2dda8309dd86b78cd2775971721d29e5317ffd5
Summary:
`Overflow inset` is a field in LayoutMetrics that describes the external bounding box that covers area formed by all descendants of the view (that might stick out of the frame of the view).
This information can be used for various optimizations across all rendering pipeline. Here is some of them:
Improving hit-testing performance.
Implementing a robust "remove invisible native views" feature.
Improving `clipToBounds` performance.
Improving View Flattening versatility.
Most importantly, we need this for improving <ScrollView> performance (and memory footprint) which we have to do to match parity with Paper's `removeClippedSubviews` feature.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22297325
fbshipit-source-id: cb238f0505d11ccabbe9db26f36a98b3172c70db
Summary:
onAssetDidLoad is defined as bubbling event in iOS, change it to bubbling event and adde it to bubblingEventTypes to fix "missing: topAssetDidLoad" error in Viewpoints iOS.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D22209406
fbshipit-source-id: 5da779d9d1d62c70d85d84ad80807ff688e29e2f
Summary:
After years of trying to design a somehow decomposed and universal layout API, I think we chased a wrong goal. None of the solutions that I tried helped with simplicity, composability, performance, or readability. Besides that, a bunch of execution primitives we use (e.g. `setHasNewLayout`) are heavily influenced by Yoga and are far from being commonly applicable. Finally, we ended up with a situation where the current design does not allow us to implement the features we want (more about that in coming diffs).
The diff changes that. Now we have only one method that implements layout - `layout()`; all possible implementations are free to implement it in any way that makes sense for a particular approach. And, I think, even for the base case - Yoga powered layout - things are much simpler and faster now: it's easy to comprehend how a single method works and now we don't have two loops and an expensive call to `getLayoutableChildNodes`.
But most importantly, after this change will be able to implement the `Inset Overflow` feature quite easily.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D22297317
fbshipit-source-id: f8662b7e8e3b522bdd6e5b2b0ac6a06efb45be6d
Summary:
Changelog: [Internal]
Introducing InputAccessoryView.
There is one big difference between Fabric's implementation and Paper's implementation.
Fabric searches for text input from InputAccessoryView, unlike Paper where it is the other way around.
Reviewed By: shergin
Differential Revision: D22160445
fbshipit-source-id: 55313fe50afeced7aead5b57137d711dd1cfd3ae
Summary:
View elevation is an Android-only prop, and it's a float, not an int. https://www.codota.com/code/java/methods/android.view.View/setElevation
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22298431
fbshipit-source-id: 91edc3aa64e7254a5c4a4cb33f26e64ebae89b8d
Summary:
After animation has been finished using Native driver there is no final value passed from the native to JS side. This causes a bug from https://github.com/facebook/react-native/issues/28114.
This PR solves this problem in the same way as `react-native-reanimated` library. When detaching it is calling native side to get the last value from Animated node and stores it on the JS side.
Preserving animated value even if animation was using `useNativeDriver: true`
Fixes https://github.com/facebook/react-native/issues/28114
## 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
-->
[Internal] [Fixed] - Save native Animated node value on JS side in detach phase
Pull Request resolved: https://github.com/facebook/react-native/pull/28841
Test Plan: Unit tests for added getValue method passed. Green CI
Reviewed By: mdvacca
Differential Revision: D22211499
Pulled By: JoshuaGross
fbshipit-source-id: 9a3a98a9f9a8536fe2c8764f667cdabe1f6ba82a
Summary:
Here is why:
* It was with us from the very beginning but we never use it.
* The main purpose of this - snap-to-pixel layout - was moved to Yoga, where it should be.
* The current implementation has a bug.
* It's not really correct conceptually because the value becomes incorrect when an immutable subtree is being reused as part of a new tree.
* It over-complicates a new feature I am working on.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22284645
fbshipit-source-id: c4c2df8d24e8fe924725b465e04e8154d097d226
Summary:
A function in graphics/geometry which adjusts a rectangle by the given edge insets.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22284644
fbshipit-source-id: ad78abd7889b4457c450b2cc43fb73054aef2c79
Summary:
Early ViewCommand dispatch: ship the experiment everywhere on Android.
Since ViewCommands are totally divorced from the commit cycle currently, and since they are inherently unsafe, we can create a separate queue for them
and retry them if they fail with a specific category of exceptions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22173050
fbshipit-source-id: 494b7c6b5dfd2aec8ba77ae35d0d58d4d727b9b4
Summary:
This diff avoids accessing window and activities object that has dissapear
changelog: [Android][Fix] Fix crash when updating RN dialog props after the activity disappeared
Reviewed By: JoshuaGross
Differential Revision: D22264672
fbshipit-source-id: 89c9895c8c6b6fec383a0e160847e5059616e265
Summary:
Changelog: [Internal]
In D8552360 (https://github.com/facebook/react-native/commit/48b9a6f887c09f78944053a6658106a01dc20fea) an experimental integration between old and new UIManager has been introduced.
It isn't needed anymore.
I did some measurements and it is the slowest part of `[RCTComponentViewDescriptor dequeueComponentViewWithComponentHandle]`.
{F241943384}
Reviewed By: shergin
Differential Revision: D22274782
fbshipit-source-id: 799ba047f1c57f68f00b0b6fa7c58782874991bc
Summary:
Need to publish a new version now that we want to not publish Flow code
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: kacieb
Differential Revision: D22265050
fbshipit-source-id: a9a0d03b1e2c1ec72e642b0af070ba48426825f8
Summary:
The docs suggest that TouchableNativeFeedback [inherits `TouchableWithoutFeedback` props](https://reactnative.dev/docs/touchablewithoutfeedback#props) but `accessibilityHint` was missing.
## Changelog
[Android] [Added] - Add accessibilityHint to TouchableNativeFeedback
Pull Request resolved: https://github.com/facebook/react-native/pull/29154
Test Plan: Not sure how this should be tested, but I'm happy to implement what others may suggest
Reviewed By: kacieb
Differential Revision: D22109459
Pulled By: TheSavior
fbshipit-source-id: 573267a26414a97ba23a1a7995bff1608f9ba34f
Summary:
PlatformColorExample RNTester page crashes when running on platforms other than iOS/Android.
Changed some very minor logic to take into account that platforms other than iOS/Android exist.
## Changelog
[Internal] [Fixed] - PlatformColorExample RNTester page crashes when running on platforms other than iOS/Android.
Pull Request resolved: https://github.com/facebook/react-native/pull/29120
Reviewed By: sahrens
Differential Revision: D22109188
Pulled By: TheSavior
fbshipit-source-id: 853bea0ac4ea5c67f35d89d1a2bf55f5c89823b4
Summary:
Provide a mocked `DevSettings` implementation for jest.
## 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] [Added] - Add mock for `DevSettings` to jest preset
Pull Request resolved: https://github.com/facebook/react-native/pull/29223
Test Plan: None
Reviewed By: cpojer
Differential Revision: D22279962
Pulled By: TheSavior
fbshipit-source-id: 667cecb0a558a4267564702ee9d30380756bdd92
Summary:
Changelog: [Internal]
The methods were out of order, this diff reorders them.
Reviewed By: shergin
Differential Revision: D22233255
fbshipit-source-id: ea66bc701c4d021ec5721e191bc0d3413b3d36ae
Summary:
In an effort to simplify and clean up the `EventEmitter` abstractions in React Native, this removes `once()` and `removeCurrentListener()`. Across the Facebook codebase, there were only two callers of `once()` and no callers of `removeCurrentListener()`.
The same behavior can be achieved using:
```
const subscription = emitter.addListener('event', () => {
subscription.remove();
// ...
});
```
Changelog:
[General][Removed] - Removed `once()` and `removeCurrentListener()` fom `DeviceEventEmitter` and `NativeEventEmitter`.
Reviewed By: cpojer
Differential Revision: D22196474
fbshipit-source-id: 06ced186fd812e91d5c57f6580e647c100505807
Summary:
https://github.com/facebook/react-native/issues/27264 changed stylesheet validation to avoid enumerating properties on the prototype of a style. It introduces a secondary behavior change, where null/undefined styles used to be tolerated but now lead to an exception. This is because `for in undefined` will noop where `for of Object.keys(undefined)` will throw.
This scenario of undefined/null styles seems to actually show up in practice and was previously well tolerated. E.g. `Button.js` has code that looks like this:
```jsx
const styles = StyleSheet.create({
button: Platform.select({
ios: {},
android: {
elevation: 4,
// Material design blue from https://material.google.com/style/color.html#color-color-palette
backgroundColor: '#2196F3',
borderRadius: 2,
},
}),
```
For non ios/Android platforms, that creates a style object which looks like:
```js
{
button: undefined,
...
}
```
This previously meant that the component would be unstyled if created, but now means out-of-tree platforms throw if the builtin Button component is required.
This change restores the previous `for in` loop but adds a `hasOwnProperty` check to avoid properties on prototypes.
## Changelog
[General] [Fixed] - Restore Previous Behavior for StyleSheet Validation of Null/Undefined Styles
Pull Request resolved: https://github.com/facebook/react-native/pull/29171
Test Plan: Validated that importing Buttons will no longer cause an exception, and that invalid properties are still caught.
Reviewed By: JoshuaGross
Differential Revision: D22118379
Pulled By: TheSavior
fbshipit-source-id: 650c64b934ccd12a3dc1b75e95debc359925ad73
Héctor Ramos
Valentin Shergin
almouro
fabriziobertoglio1987
Joshua Gross
Jordan Brown
generatedunixname89002005287564
Benjamin Henrik Robson
Riley Dulin
Samuel Susla
Vojtech Novak
Lulu Wu
TMaszko
David Vacca
Eli White
Chris Dadabo
Andrew Coates (REDMOND)
Marco Scabbiolo
Tim Yung
Nick Gerleman
Omer Peleg
