feat: migrate to react-native-reanimated

[shoma-mano]

Thank you very much for your helpful response. #6 (comment)
I really appreciate it, as it has been very educational for a React Native beginner like myself.

I have removed the renderScrollView and confirmed that the callbacks in useAnimatedStyle and useAnimatedScrollHandler are working correctly within the worklet.

Please don't hesitate to let me know if there are any issues or further improvements needed for this PR.

[rozhkovs]

@shoma-mano I am very glad to see your PR again!

I like your changes! Can you please answer my questions and correct the code, after that we can safely merge!

[shoma-mano]

@rozhkovs
Thank you for the review!
I've addressed the points you mentioned.
If you prefer, I can switch the React Native version that example is using to an older one to avoid using the experimental feature. If so, the assertion in example/src/pickers/customized/Overlay.tsx will no longer be necessary.

[rozhkovs]

@shoma-mano
Good job! I'll check locally later how it works.

If you prefer, I can switch the React Native version that example is using to an older one to avoid using the experimental feature. If so, the assertion in example/src/pickers/customized/Overlay.tsx will no longer be necessary.

Can you send the link about what is it about? I still don't get it.

[shoma-mano]

@rozhkovs
I'm sorry for lack of context, I meant New Architecture (Fabric).Document says only the latest minor release react native is supported when it comes to New Architecture.
https://docs.swmansion.com/react-native-reanimated/docs/guides/troubleshooting/#outdated-version-of-react-native-for-new-architecture

But I was mistaken, only updating react native doesn't seem enough to use new architecture.It requires some expo settings.
So for now, I think it is ok to use 0.71.8 to avoid assertion in example/src/pickers/customized/Overlay.tsx.
If so, I have to down grade reanimated to version that is compatible with 0.71.8.

[rozhkovs]

@shoma-mano
Thanks for the clarification!
But to be honest, I still don't understand about "to avoid assertion in example/src/pickers/customized/Overlay.tsx.". Maybe I need to run the code and it will be clear.

I think it's a good idea to use "0.71.8" because updating expo and others to a newer version is already a bit beyond the scope of the current PR.

[shoma-mano]

@rozhkovs
Yes, It may be a little difficult to understand without confirming error on IDE.
Without assertion, type error like this happens due to react native version difference between example(0.75.3) and library(0.71.8).

I think it's a good idea to use "0.71.8" because updating expo and others to a newer version is already a bit beyond the scope of the current PR.

I think so too! But after trying several versions of React Native Reanimated greater than 3.0.0, I found that the build fails if the React Native version remains at "0.71.8". Updating react native may be inevitable.

[rozhkovs]

@shoma-mano

Without assertion, type error like this happens due to react native version difference between example(0.75.3) and library(0.71.8).

We need to synchronize the devDependencies of the library with the example. Then we will have the types of the same versions. That is, it should be enough to update the package' dependencies.json "react-native": "0.71.6" -> " react-native": "0.75.3" and the problem should disappear.

[shoma-mano]

@rozhkovs
Thanks for response. I will update update the package' dependencies.json "react-native": "0.71.6" -> " react-native": "0.75.3".
I have one more question: The existing android and ios folders in example are preventing the build (expo run:android and expo run:ios) from succeeding. Would it be okay to delete these folders?

[rozhkovs]

@shoma-mano
Why are they in the way?

In theory, on iOS and Android, for the new version of Expo, these folders should be generated using the npx expo prebuild command. At the same time, the example uses native modules that are not included in the standard Expo SDK (@quidone/react-native-wheel-picker-feedback,...). That is, for the example to work correctly, we need to generate the ios and android folders and build the apps natively.

The commands expo run:android and expo run:ios should work. For the sake of experiment, you can delete these folders and re-generate them, perhaps the problem will disappear.

Perhaps we still need to take some steps to solve the problem when switching to the new version of Expo.

I honestly don't know if it's worth keeping track of the android and ios folders in Git in this case. Probably not, because this is the result of code generation, and you shouldn't edit something there yourself.

[Alaa-Ben]

Hey there !
FYI in an expo project, ios & android folders are usually in the gitignore.

[shoma-mano]

@rozhkovs

The commands expo run:android and expo run:ios should work. For the sake of experiment, you can delete these folders and re-generate them, perhaps the problem will disappear.

Yes, I confirmed that once the folder is deleted, the build succeeds with the new android and ios folders afterward. I don't know detail reason, Maybe they are just too old and it is hard to refresh without deleting folders completely. So, As @Alaa-Ben says I think it is ok to include these folders to gitignore.

[rozhkovs]

@Alaa-Ben

Hey there !
FYI in an expo project, ios & android folders are usually in the gitignore.

Thank you for the information!

@shoma-mano
Let's then delete the ios and android folders and add these folders to the example/.gitignore

[shoma-mano]

@rozhkovs
I’m done! If there are any other points of concern or areas that need to be revised, please let me know.

[rozhkovs]

@rozhkovs I’m done! If there are any other points of concern or areas that need to be revised, please let me know.

@shoma-mano I finally got to check this PR! Thanks for waiting!

The changes work correctly, but there is unpleasant news: on iOS (iPhone 11) and especially on Android (Redmi Node 11 Pro), the performance is not satisfactory in my opinion. You can see that the animation occurs in jerks and there is a loss of frames, this is very clearly visible on phones where 120 hz. I believe this is due to the Reanimated library itself, and we are unlikely to be able to speed this up.

I'm sorry for the little data, but this can be checked on a real Android device in debug mode. My device dropped to 30fps, this was not observed with Aniamted from react-native. In the Release version, there is also a drop in frames.

There is a proposal to leave Animated from react-native by default, and make Reanimated as an option for now. For example, we can add the animateEngine={"react-native" | "reaniamted" property}

How do you see it?

[rozhkovs]

I mean, I don't want to just switch to Reanimated and lose the animation performance that we already have.

[shoma-mano]

Thank you for reviewing, @rozhkovs!

How can I check the FPS? I have a Pixel 7, and while there's an option to display the refresh rate, there isn't an option to confirm FPS. I tried using Takoslots, but it doesn’t seem to support Android 14.
Can I confirm fps drop with "Show Perf" option in the emulator instead?

Anyway, if there’s a performance drop, it is not ideal to use Reanimated as the default.
I think it’s best to hold off on the migration for a while.

[rozhkovs]

@shoma-mano
I think the performance issue is related to this issue.

Can I confirm fps drop with "Show Perf" option in the emulator instead?

Probably, yes. But it is better to have a real device that is in the lower or middle price segment. As one of the options, you can add more elements to the WheelPicker until the moment when scrolling performance starts to drop. Next, you should find that with Animated from react-native, this will not happen.

[shoma-mano]

@rozhkovs
I have confirmed now! You are right!
I'm pleasant to hear your suggestion to have options for selecting library, But I think it's best to wait migrating considering code complexity. It's ok to close this PR.

[shoma-mano]

@rozhkovs
I will try this when time allows :)
https://expo.dev/changelog/2024/10-24-sdk-52-beta

[gladiuscode]

Hi @rozhkovs, @shoma-mano!

Are there any updates on this PR?
We've found this golden library because a client needs to display a wheel of dates and time ranges to let the user choose from and we later found out that in a bottom sheet this library just doesn't work due to BottomSheet constraints on using gesture-handler's components and reanimated to handle the animation.

Since the bottom sheet, react-native-gesture-handler and reanimated are all standard libraries that common projects use, it would benefit a lot for this library to be compatible with them.

To speed things up I'm cloning @shoma-mano repository to align everything to the latest versions and to test the changes out.

I'll let you all know.

Thanks!

[rozhkovs]

Sharing a few thoughts.

At this point, I don’t see a strong reason to migrate the library to Reanimated given the current performance issues. Once those are resolved, we can revisit the idea. I also don't see a compelling need to move to gesture-handler yet.

Reanimated might work fine together with FlashList, since FlashList typically deals with relatively small datasets. For a WheelPicker with visibleItemCount={5}, we’d probably have no more than ~20 items anyway.

I don’t have time to run these experiments right now.

If anyone else has input, feel free to share.

[smlarkin]

@rozhkovs if FlatList is the fundamental primitive, have you considered Legend List