To reduce reduntant code by repeating the logging functionality in each JS module, this commit introduces a factory for creating a logger with a given prefix.
- Create factory `createLogger`
- Remove redundant log implementations
- Changed to use factory in hermes.js and ios-prebuild.js
When checking if we should download hermes artifacts, the path to the folder we're checking was wrong, causing hermes to always be downloaded.
This commit fixes this by renaming it from `Libraries` -> `Library`
Summary:
The Flow team is improving the way Flow infers type for primitive literals. This diff prepares the codebase for the new behavior by adding type annotations, or annotations of the form `'abc' as const`.
Changelog: [internal]
Reviewed By: marcoww6
Differential Revision: D75188179
fbshipit-source-id: be50990f23f79cf2d8dae7576af5190218adcafe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51502
While working on a case for Editor on mac, it took me a while to figure out what enum was the root cause:
{F1978470518}
Adding the blaming enum name in the error message would have made my life much easier.
## Changelog:
[GENERAL][Added] - Improve error messages when enum members are missing
Reviewed By: rshest
Differential Revision: D75141414
fbshipit-source-id: 3625d817b218788891252add225f8fffb99e3145
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51481
# Changelog: [Internal]
This is replaced by `HighResTimeStamp::now()`, which is available in a dedicated smal `react/timing` module.
Reviewed By: lenaic
Differential Revision: D75006354
fbshipit-source-id: d41bf73238e9c6bf5c5a9509d60713ce11e6ea4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50585
# Changelog: [Internal]
Replaces `DOMHighResTimeStamp` alias completely in `ReactCommon` with `HighResTimeStamp`.
`DOMHighResTimeStamp` as a type is now expected to be used only in JavaScript.
I didn't update places where we explcitly use `std::chrono::high_resolution_clock`, since it is platform-specific and there is no guarantee that `std::chrono::high_resolution_clock` == `std::chrono::steady_clock`.
Also, places that are isolated and not part of the Web Performance APIs, such as Telemetry for Fabric, are not updates as part of this diff. Although these subsystems are also using `std::chrono::steady_clock` as a low-level representation, they are not sharing it with other parts of the React Native core.
Reviewed By: rubennorte
Differential Revision: D72649815
fbshipit-source-id: 96bcfaf909d4a7a5bb2ecfdd76f9939f1645fb69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51454
# Changelog: [Internal]
There are multiple changes:
1. `PerformanceTracer` class, `TraceEvent` struct are moved to `tracing` namespace. These are parts of the Tracing subsystems of the jsinspector, this should bring more clarity and make things more explicit.
2. Added `Timing.h` class which defines conversion logic from `HighResTimeStamp` to absolute units that are expected by CDP.
3. `PerformanceTracer` will receive timestamps for Performance Web API entries in `HighResTimeStamp`.
Also, we will explicilty define a Tracking Clock time origin that will be epoch of the `steady_clock`. This aligns with the approach in Chromium and saves us from aligning custom DOMHighResTimeStamps that can be specified in performance.mark / performance.measure calls: these should not extend the timeline window. I've confirmed that this is the current behavior in Chromium.
Reviewed By: rubennorte
Differential Revision: D74892330
fbshipit-source-id: 514ca23dde8e23fbe07faf673e765674f328f60e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51455
# Changelog: [Internal]
The main idea is that subsystems who might use a different time origin (the starting point of the whole timeline of events), can use `toChronoSteadyClockTimePoint` method to get raw `std::chrono::steady_clock::time_point` and then offset it by some arbitrary epoch: be it unix time origin or `std::chrono::steady_clock::epoch`.
`fromChronoSteadyClockTimePoint` can be used to convert time stamps from external systems, like Hermes.
Reviewed By: rubennorte
Differential Revision: D74892329
fbshipit-source-id: 70f34ce99aead6e0552d87d310c4d6ea4653b8fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51506
ReactRawTextManager is not used in new architecture, this diff marks it as so
changelog: [internal] internal
Reviewed By: mlord93, cortinico
Differential Revision: D75150100
fbshipit-source-id: 868420e87dc80185d5a51299736ce2ed6a855fe9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51488
The Flow team is improving the way Flow infers type for primitive literals.
Announcement: https://fb.workplace.com/groups/flowlang/permalink/1725180268087629/
This diff prepares the codebase for the new behavior by codemoding `as const` annotations.
## Repro steps
1/ Used steps in D73610163 to produce the code changes.
2/ Reverted files where `flow` errored:
```
flow status --show-all-errors > errors.log
node ~/fbsource/fbcode/flow/facebook/error-analyzer.js errors.log |
awk -F':' '{ print $1 }' | sort -u | grep -v 'Total Error Count' |
xargs hg revert --rev .
```
3/ Reverted files that did not improve error count in new Flow mode
```
# Run Flow before change
~/fbsource/fbcode/flow/facebook/flowd status --show-all-errors > errors-0.log
# Run Flow after change
~/fbsource/fbcode/flow/facebook/flowd status --show-all-errors > errors-1.log
# Compute error counts before and after
node ~/fbsource/fbcode/flow/facebook/error-analyzer.js errors-0.log | sort > errors-counts-0.log
node ~/fbsource/fbcode/flow/facebook/error-analyzer.js errors-1.log | sort > errors-counts-1.log
# Revert files with no change in error count
comm -12 errors-counts-0.log errors-counts-1.log | awk -F':' '{ print $1 }' | xargs hg revert --rev .~1
```
## Note to code owners
Due to the large number of errors involved in this rollout, adding `as const` was the most feasible large-scale automated solution. Ideally, a lot of these errors would be fixed by adding other appropriate type annotations. For example instead of annotating
```
type Shape = {type: 'circle', radius: number} | {type: 'square', side: number} | ...;
type ShapeKind = 'circle' | 'square' | 'triangle';
const circle = {
type: "circle" as const, // <-- annotation added here
radius: 42,
};
shape.type as ShapeKind;
takesShape(circle);
```
a more appropriate annotation would be
```
const circle: Circle = { type: "circle"; radius: 42 };
...
```
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D75114154
fbshipit-source-id: 67ee5673816da9625431e2a2466a1e0038386151
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51487
The Flow team is improving the way Flow infers type for primitive literals. This diff prepares the codebase for the new behavior by adding type annotations, or annotations of the form `'abc' as const`.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D75114156
fbshipit-source-id: e3175af85cdd2388c3b45af4beb314f334e3f9b5
Summary:
Running with
```
DEBUG=Metro:InspectorProxy DEV=1 js1 run --no-tty-print
```
When a message larger than 100kb is send over the cdp, log it.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D75000887
fbshipit-source-id: 6f426ed4db7ac1996c4f26461a6e0d13c096e5cd
Summary:
As next step of the JSC deprecation, we are removing the CI testing for the JSC engine
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/51475
Test Plan: GHA
Reviewed By: NickGerleman
Differential Revision: D75089216
Pulled By: cipolleschi
fbshipit-source-id: 3839914cb58e872ddd82089bd7cb1391ddda20c1
Summary:
Migrate com.facebook.react.views.text.TextAttributes to Kotlin.
`TextTransform` is exposed in the `textTransform` var setter, and there doesn't seem to be a clean way to avoid having to make the `TextTransform` class public again. I have limited its companion to keep it internal as much as possible.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.views.text.TextAttributes to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/51448
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: cortinico
Differential Revision: D74978129
Pulled By: rshest
fbshipit-source-id: ea0594f01738b8c8f4696434fe76974bbb9ff661
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51486
Original commit changeset: 5b313a5e8c07
Original Phabricator Diff: D74198568
Fix the issue that dropdown menus in HSR worlds menu are not clickable.
Reviewed By: xieswufe
Differential Revision: D75108344
fbshipit-source-id: d134ff9287929f8e1fc0995acf2b884d6a67131c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51428
Just refactoring the control flow in these functions (in a separate diff). So, that the logic in subsequent diffs is easier to read: D74769326.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74940681
fbshipit-source-id: 7aabc722948666a13993a1feff7eeca8ef1403cf
Summary:
In https://github.com/facebook/react-native/pull/50734, `LayoutAnimationController` was migrated to Kotlin and all of its methods are now marked as final.
However, this class is used and extended by `react-native-reanimated` in order to provide Layout Animations for Android on the Old Architecture. With all its methods being marked as final, the builds are failing.
This PR restores the possibility to extend `LayoutAnimationController`.
## Changelog:
[ANDROID] [FIXED] - Restored the possibility to extend `LayoutAnimationController`
Pull Request resolved: https://github.com/facebook/react-native/pull/51479
Test Plan: I've checked that this PR fixes build errors caused by `LayoutAnimationController` in react-native-reanimated.
Reviewed By: cipolleschi, mdvacca
Differential Revision: D75079557
Pulled By: cortinico
fbshipit-source-id: beeb700cbad87362dda4b60941124562c4753815
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51477
changelog: [internal]
when using C++ Animated, no need to send events to Objective-C Native Animated.
Reviewed By: lenaic
Differential Revision: D75066259
fbshipit-source-id: 224d15ba2f707f2272a4fec56e5b2685694c7809
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51379
Changelog: [General][Fixed] Fix incorrect flattening / non-rendering of views with backgroundColor set to `rgba(255, 255, 255, 127/256)`
Fixes#51378.
## Context
When testing some unrelated things with Fantom is realized that the color for some text that I wasn't explicitly defining was being set to `rgba(255, 255, 255, 127)`, like here:
https://github.com/facebook/react-native/blob/249a24ac756275eadbe3b4df1ff9c974af1671d2/packages/react-native-fantom/src/__tests__/Fantom-itest.js#L540-L542
When digging a bit more about why, I realized that was actually the value for `UndefinedColor`. When looking a bit deeper, I saw that the value for that constant was being set like this:
```
using Color = int32_t;
namespace HostPlatformColor {
static const facebook::react::Color UndefinedColor =
std::numeric_limits<facebook::react::Color>::max();
}
```
I'm not sure what the logic could've been here:
- Defining it as a value out of bounds for all valid colors? In this case, it's a 32 bit value so all the range of values are actually valid RGBA colors.
- Defining it as a fully opaque white? Seems dangerous for a default because you wouldn't be able to distinguish a explicitly set white color from a non-set color, relevant if you're seeing a white background color in a view on top of another view with any other background color.
The result of this existing logic was actually setting `UndefinedColor` to `rgba(255, 255, 255, 127)` because the alpha channel is defined in the first bits of the value, and `Color` being a signed int with 32 bits, the largest value is `01111....1`, so extracting the first 8 bits, you get 127.
## Changes
This changes the value set for the `UndefinedColor` constant (which is used, among other things, to determine if a view sets a background color, or otherwise could potentially be flattened).
The new value, instead of white with a 127/256 opacity, is black with 0% opacity (or simply the number 0 in `int32_t`).
Reviewed By: javache
Differential Revision: D74869311
fbshipit-source-id: 5582b4803b0b5c72cb3c1b33720c4542c5e3f1de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51476
Changelog: [internal]
When we added integration of IntersectionObserver in the event loop by default, we changed the timing of the observer notification:
- Before, it was scheduled synchronously from the `observe` call. That means that, if you schedule another task immediately after the observe call, the order is IO callback then task.
- After, it was scheduled at the end of the current event loop tick. That means that, if you schedule another task immediately after the observe call, the order is task then IO callback.
This change in order wasn't accounted for in the tests for IO (which it's added here) and made a test for `structuredClone` break because it was using incorrect assumptions.
This fixes that test.
Reviewed By: rshest
Differential Revision: D75073118
fbshipit-source-id: 38ad2d03686891daf4caa836e1f597917910ddd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51337
changelog: [internal]
When C++ Native Animated is used, we can't be using TurboModuleAnimated native module. This diff just add the check to make sure that if C++ Native Animated is used, it will be correctly referenced from JS.
Reviewed By: lenaic
Differential Revision: D74490166
fbshipit-source-id: 1b6de3227707168618052ff4ca6a02ca11337607
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51470
changelog: [internal]
To support C++ Native Animated and prevent unnecessary conversion between `folly::dynamic` <-> and `NSDictionary`, a method to apply `folly::dynamic` changes needs to be exposed on RCTMountingManager.
Previously I tried to change existing method `synchronouslyUpdateViewOnUIThread` to take folly::dynamic instead of `NSDictionary`. However this requires a change where we would expose C++ API to Objective-C class only, breaking build system in open source. This approach was backed out in D74881580.
In this diff, I take an alternative approach and expose two methods to apply animation changes:
- Keep the existing API `synchronouslyUpdateViewOnUIThread` as is. This way, Objective-C Native Animated does not need to change.
- Introduce new method for `[RCTSurfacePresenter schedulerDidSynchronouslyUpdateViewOnUIThread]` which accepts `folly::dynamic`. This is used by C++ Native Animated only
Reviewed By: javache
Differential Revision: D74885607
fbshipit-source-id: 124b8800c01deeb6d57af8f4c47bea46cc1bcd66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51472
Changelog: [internal]
This enables the integration of `IntersectionObserver` with the Event Loop by default.
Reviewed By: rshest, javache
Differential Revision: D74991641
fbshipit-source-id: 7f12d7d5413d12a6a7de53e9d6701195d48996dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51452
Changelog: [internal]
This implements a long planned refactor of `IntersectionObserver` to have a proper integration with the Event Loop, which unblocks `FragmentRef` in React Native.
The existing integration doesn't integrate with the Event Loop, so the intersection determination doesn't happen as a step in the event loop but in 2 different moments:
1. When you start observing a new target, we check if there are any pending transactions for that target, and otherwise determine the intersection immediately and queue the notifications.
2. Using mount hooks, when a transaction for a surfaceId is mounted, we check intersections for all the observers in that surface.
This has an important problem:
* If you attach a observer on a target before the target is attached to the tree (something that `FragmentRef` will start doing soon), we don't have a pending transaction so we determine intersections immediately. In that case, it's always "not visible" because it's not attached, and then we immediately trigger a transition when mounted in the same tick.
To fix this, we can implement a step in the Event Loop the same way that `IntersectionObserver` does on Web. We would still wait for pending transactions to be mounted to determine intersection timing (the same way we do now, but now checking at the end of the current Event Loop tick), but the dispatch of initial notifications for target that won't change is done at the end of the tick instead of synchronously.
It also refactors the list of active observers as a list of shared pointers to `IntersectionObserver` objects, instead of as list of `IntersectionObserver` objects directly. This is necessary to build the list of pending observers (with stable references) while making sure the ownership stays in the list of active observers.
Reviewed By: javache
Differential Revision: D74883214
fbshipit-source-id: 24accf1dba48d13b5773950a5cbf9ea38f4a1745
Summary:
This PR improves `RCTScreenSize` to handle horizontal orientations. This was causing a flicker whenever opening a Modal in horizontal orientation. Currently, `RCTScreenSize` is used to supply initial state for `ModalHostViewState`:
https://github.com/facebook/react-native/blob/f1697544cd720df21bd7dc8ca993d95a41321e3f/packages/react-native/ReactCommon/react/renderer/components/modal/ModalHostViewState.h#L31
This works great in portrait mode, but causes onLayout the be called twice in horizontal orientation (first with screen size and then with actual size..)
## Changelog:
[IOS] [FIXED] - make RCTScreenSize take horizontal orientation into account
Pull Request resolved: https://github.com/facebook/react-native/pull/51444
Test Plan: Open modal in horizontal orientation
Reviewed By: cipolleschi
Differential Revision: D74978651
Pulled By: rshest
fbshipit-source-id: f026e727b3529766de38dd31059c51b255f33e78
Summary:
Hermes build-type was hardcoded to 'release' in the previous version of the prebuild scripts.
This commit fixes this so that we can provide a build-type for hermes when downloading prebuilt tarballs.
- Cleaned up parameters in hermes.js
- Updated with buildType parameter when suitable
- Fixed some function names
- Updated version file so that it contains build type
- Removed version file when using a local tarball
## Changelog:
[IOS] [FIXED] - Fixed resolving build type when downloading hermes artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/51283
Test Plan: No test-plan yet
Reviewed By: cortinico
Differential Revision: D74882001
Pulled By: cipolleschi
fbshipit-source-id: cfeed934023712e70f7d04c137e8611164120cec
Summary:
Our Cocoapods config has a list of defines that are used mostly when setting up pods:
- RCT_FABRIC_ENABLED
- USE_HERMES
- RCT_AGGREGATE_PRIVACY_FILES
- RCT_NEW_ARCH_ENABLED
- APP_PATH
- REACT_NATIVE_PATH
- RCT_SKIP_CODEGEN
- SWIFT_ACTIVE_COMPILATION_CONDITIONS
- USE_FRAMEWORKS
- USE_THIRD_PARTY_JSC
- HERMES_ENABLE_DEBUGGER
- REACT_NATIVE_DEBUGGER_ENABLED
- REACT_NATIVE_DEBUGGER_ENABLED_DEVONLY
Out of these, only the following are used in objective-c/c code:
- USE_HERMES
- HERMES_ENABLE_DEBUGGER
- REACT_NATIVE_DEBUGGER_ENABLED
- REACT_NATIVE_DEBUGGER_ENABLED_DEVONLY
This commit adds the required defines to the correct targets.
## Changelog:
Pick one each for the category and type tags:
[IOS] [FIXED] - fixed defines in package.swift
Pull Request resolved: https://github.com/facebook/react-native/pull/51284
Test Plan: No test-plan yet
Reviewed By: cortinico
Differential Revision: D74872272
Pulled By: cipolleschi
fbshipit-source-id: 5d9a68c1d819409bc7400ade622f62bb332d0896
Summary:
When running the prebuild script:
`node scripts/ios-prebuild.js`
The script will now try to resolve and download a prebuilt version of hermes:
1. Hermes artifacts will be extracted to the `./build/artifacts/hermes` folder to ensure that Package.swift can find a version to link against.
2. The script checks the environment variable `HERMES_ENGINE_TARBALL_PATH` and tries do expand the tarball into the artifacts folder from 1
3. If not found, the script reads the hermes version from either the hidden environment-variable `HERMES_VERSION` and tries to download a release-tarball or a nightly tarball for this version. If the version does not exist, the script will fail.
Also added some extra logging features to the script.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Added downloading of hermes artifacts when pre-building for iOS.
Pull Request resolved: https://github.com/facebook/react-native/pull/51216
Test Plan:
1. Delete the `packages/react-native/.build` folder
2. Run the build script (provide a valid HERMES_ENGINE_TARBALL_PATH or a valid Hermes version (or nightly version)
3. Verify that the script successfully exits
4. Build the Package.swift in Xcode and verify that it finds and links the relevant Hermes files, verifying is done by the build succeeding.
Reviewed By: NickGerleman
Differential Revision: D74565936
Pulled By: cipolleschi
fbshipit-source-id: 5bd231999da24cfcce446150ac0fc1b5a4b6a4ae
Summary:
Found an issue with the legacy native module calls in old architecture (https://github.com/facebook/react-native/issues/51443) and got the idea of adding some simple e2e tests for the native modules so regressions like this can be captured moving forward.
This doesn't cover all methods, as not all of them are available for both Android and iOS, and also some of them are currently crashing, so it makes no sense to cover them all yet – but this can be used as a good starting point to increase coverage for essential APIs.
## Changelog:
[INTERNAL] - Legacy Native Module e2e test
Pull Request resolved: https://github.com/facebook/react-native/pull/51449
Test Plan:
```sh
cd packages/rn-tester && maestro test .maestro/legacy-native-module.yml -e APP_ID=com.facebook.react.uiapp
```
<img width="594" alt="image" src="https://github.com/user-attachments/assets/6237613d-f5dc-4d8a-9b12-0980177793eb" />
<img width="740" alt="image" src="https://github.com/user-attachments/assets/8bdef368-13ac-494c-a506-88fff01dc8d6" />
Reviewed By: cortinico
Differential Revision: D74978093
Pulled By: rshest
fbshipit-source-id: f9c7ba3ca5177eb3d3863d2b8252ac17f3d07aa0
Summary:
I noticed the link to networking in new app screen is wrong. So correcting it here
## Changelog:
[GENERAL][FIXED] - Fix Networking URL in New app screen
Pull Request resolved: https://github.com/facebook/react-native/pull/51396
Test Plan: Click on the link to open
Reviewed By: arushikesarwani94
Differential Revision: D74886240
Pulled By: cortinico
fbshipit-source-id: 19ccf63e64f0e40df4a0ab4082299c654926e35d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51465
Prior to D63303709 AttributedString could not represent formatting on an empty string, and so some text content was forcefully added to empty strings during measurement.
This is problematic in combination with Facsimile, where we directly render the layout we used during measurement, since empty text now has a random "I" in it.
Android's TextLayoutManager already knows how to interpret `baseTextAttributes`, and the placeholder is not needed. Other platforms should be updated to do the same, but that may be non-trivial to validate everywhere.
This diff removes logic from ShadowNodes to always inset a placeholder, and instead shims it in platform TextLayoutManagers which have not yet been updated to use `BaseTextAttributes`. That way, we don't force placeholders during measurement, and different platforms can incrementally unjank their code.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74770916
fbshipit-source-id: 7cf19db1a9a5cf68137bbff81b14ce5288235b2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51464
Add a module of shared examples, like `TextInputSharedExamples`, to avoid copy/paste between these.
Modifies the empty test example a bit and adds an E2E test.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74780847
fbshipit-source-id: 30c2830ef0b638680fe75b4bcf9f138f5c01e190
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51389
# Changelog: [Internal]
This is the pre-requisite for the diff on top, which migrates performance-related classes to start using `HighResTimeStamp`.
We should be throwing `SyntaxError` if the specified mark name is not buffered. Like Chromium does:
{F1978032319}
In this diff:
- `PerformanceEntryReporter::getMarkTime` is now public, ca be called by `NativePerformance` and returns `std::optional`.
- `NativePerformance` is responsible for validating that marks are present in the buffer, if their names are specified in `.measure()` call.
- Mark names take precedence over `startTime` and `endTime` values, so if they are specified and not available, then we will throw Error over `jsi` that will be catched on JavaScript side in `Performance.js`.
Reviewed By: rubennorte
Differential Revision: D74837812
fbshipit-source-id: ca2ba198c4c9e6e2d8d37f852affea667f1c174c
Christian Falch
Luna Wei
generatedunixname89002005232357
Panos Vekris
Yannick Loriot
Jiawei Lü
Ruslan Lesiutin
David Vacca
Vitali Zaidman
Riccardo Cipolleschi
Mateo Guzmán
Chang Liu (RL)
Ramanpreet Nara
Tomasz Zawadzki
Samuel Susla
Rubén Norte
Oskar Kwaśniewski
Pieter De Baets
React Native Bot
riteshshukla04
Krystof Woldrich
Nick Gerleman