Passing integer to Alert causes the program to crash

[eirikhanasand]

Description

When passing an integer to Alert.alert the app will stop executing the function its in, and just move on. I think it should be possible to provide integers to alerts, or at least have an error message letting you know that the issue is that you provided the wrong data type. Would also be nice if it automatically typecasted integers/floats to strings in this scenario as its only used to display it on the screen, not to do anything with the data itself.

Example: Alert.alert("This alert will cause things to crash", 5);

Version

0.70.5

Output of npx react-native info

info Fetching system and libraries information...
System:
OS: macOS 13.0.1
CPU: (10) arm64 Apple M1 Max
Memory: 15.01 GB / 64.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 19.3.0 - ~/Desktop/Login/node_modules/.bin/node
Yarn: Not Found
npm: 8.19.2 - /usr/local/bin/npm
Watchman: Not Found
Managers:
CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.1, iOS 16.1, macOS 13.0, tvOS 16.1, watchOS 9.1
Android SDK: Not Found
IDEs:
Android Studio: 2021.3 AI-213.7172.25.2113.9123335
Xcode: 14.1/14B47b - /usr/bin/xcodebuild
Languages:
Java: 17.0.6 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 18.1.0 => 18.1.0
react-native: 0.70.5 => 0.70.5
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
info React Native v0.71.2 is now available (your project is running on v0.70.5).
info Changelog: https://github.com/facebook/react-native/releases/tag/v0.71.2
info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.70.5
info For more info, check out "https://reactnative.dev/docs/upgrading".

Steps to reproduce

Create an alert including a number.

Example: Alert.alert("This alert will cause things to crash", 5);

Snack, code example, screenshot, or link to a repository

Full on snack wont be necessary. Reproduction is done just by making an alert containing any other type than a string.

Examples of alerts that will crash:
Alert.alert("This alert will cause things to crash", 5);
Alert.alert(2.5);

[bigcupcoffee]

I can confirm this issue is present since at least 0.61 up until 0.71.2.
Might make a good first issue, I would take if I knew what way this desired to resolve with (my assumption is invariant/throw from JS?)

[cipolleschi]

Hi there! I don't think that this is an issue but something designed like this. If we look at the official doc the message parameter is of optional String type, thus the platform code expect that type to work.

We can definitely change the current API to support numbers, but I think that it would be better if you can convert the number to an explicative error message, especially for the user experience.

What do you think?

[eirikhanasand]

I agree I had a look as well and its done on purpose. The issue here is that there is no feedback letting the user know whats going on. Regarding support or error message Im kind of neutral, because both cases would improve user experience. Imo the important thing here is to let the user know whats causing the trouble, so they can debug fast, thus improving user experience. fre. 10. feb. 2023 kl. 10:36 skrev Riccardo ***@***.***>:

…

Hi there! I don't think that this is an issue but something designed like this. If we look at the official doc <https://reactnative.dev/docs/alert#alert> the message parameter is of optional String type, thus the platform code expect that type to work. We can definitely change the current API to support numbers, but I think that it would be better if you can convert the number to an explicative error message, especially for the user experience. What do you think? — Reply to this email directly, view it on GitHub <#36085 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOFFPBS4P2WZYTCDSB5IZM3WWYD2NANCNFSM6AAAAAAUUSYYNQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cipolleschi]

The issue here is that there is no feedback letting the user know whats going on.

In this case, you mean that there is no feedback for the developer using the Alert.alert API?

[eirikhanasand]

The issue here is that there is no feedback letting the user know whats going on.

In this case, you mean that there is no feedback for the developer using the Alert.alert API?

Yes. There should be some feedback in the case that the data type is incorrect instead of just a crash.

[eirikhanasand]

The issue here is that there is no feedback letting the user know whats going on.

In this case, you mean that there is no feedback for the developer using the Alert.alert API?

Yes. There should be some feedback in the case that the data type is incorrect instead of just a crash.

Because its very hard to bebug currently in a large application, and not the first thing that would come to mind

[bigcupcoffee]

It does give some developer feedback although it's not as clear. I am currently getting Value for message/title cannot be cast from Double to String.

@cipolleschi does it make sense to just typeof and throw TypeError?

[eirikhanasand]

Then it might be Expo hiding the error message cause Im not getting that. Just tested now. fre. 10. feb. 2023 kl. 11:37 skrev bigcupcoffee ***@***.***>:

…

It does give some developer feedback although it's not as clear. I am currently getting Value for message/title cannot be cast from Double to String. @cipolleschi <https://github.com/cipolleschi> does it make sense to just typeof and throw TypeError? — Reply to this email directly, view it on GitHub <#36085 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOFFPBUC2LDQ6WSBELRIEIDWWYK5XANCNFSM6AAAAAAUUSYYNQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bigcupcoffee]

Yep, but that's expo's caveat mentioned here.

I can put a PR to fix it by type-checking on JS and see if gets merged, but you'd have to wait for expo sdk update anyway.

[eirikhanasand]

Type checking would be nice. Didnt know this was a documented issue in the caveat so I guess there are othrrs who dont either. Waiting is not an issue as Ive already resolved the issue in my own code. fre. 10. feb. 2023 kl. 12:26 skrev bigcupcoffee ***@***.***>:

…

Yep, but that's expo's caveat mentioned here <https://docs.expo.dev/guides/errors/#native-errors>. I can put a PR to fix it by type-checking on JS and see if gets merged, but you'd have to wait for expo sdk update anyway. — Reply to this email directly, view it on GitHub <#36085 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOFFPBVKV4CGFWKVL33P523WWYQXBANCNFSM6AAAAAAUUSYYNQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cipolleschi]

Starting from React Native 71, we support TypeScript as default and out-of-the-box, so the code can be type checked! :D

[bigcupcoffee]

can be. I am myself using tons of .js files after I upgraded. Let's see if maintainers would like the fix merged or leave it as it is.

[motiz88]

I think the ideal solution here (for the cases where static type checking isn't enough) is for the native implementation to throw a proper JS error, including a call stack, when it tries to use that provided value. This should be doable under the new architecture. That way we don't have to add redundant checks on the JS side.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.