Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ReadableArray and ReadableMap do not support Long (int64) #12506

Closed
MattFoley opened this issue Feb 22, 2017 · 7 comments
Closed

ReadableArray and ReadableMap do not support Long (int64) #12506

MattFoley opened this issue Feb 22, 2017 · 7 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@MattFoley
Copy link

MattFoley commented Feb 22, 2017

Description

Attempting to consume an API that serves long values in some cases via JSON. When passing from JS to Native Java code on Android, there is no getLong functionality on ReadableArray and ReadableMap.

Reproduction

Simply pass a value greater than MAX_INT to Java from JS via a ReadableArray or ReadableMap.

Attempt to use getInt and see exception:

com.facebook.react.bridge.UnexpectedNativeTypeException: Value '4205344624' doesn't fit into a 32 bit signed int
   at com.facebook.react.bridge.ReadableNativeArray.getInt(Native Method)

Attempt to use getString and see exception:

com.facebook.react.bridge.UnexpectedNativeTypeException: TypeError: expected dynamic type `string', but had type `int64'
  at com.facebook.react.bridge.ReadableNativeArray.getString(Native Method)

Solution

This feels magical and bad, but this works for the moment.

Current workaround:

long value = (long)array.getDouble(index);

Better solution would be to add getLong, or some other function able to fetch long values.

Additional Information

  • React Native version: 0.40
  • Platform: Android
  • Operating System: OSX
@ide
Copy link
Contributor

ide commented Feb 22, 2017

I'm not certain but believe this could be because JS doesn't have longs yet (64-bit types are coming) and it would be deceiving to provide set/getLong methods that don't work reliably. It's more correct to write (long)array.getDouble(index) and make the programmer think about the consequences of double -> long conversion.

@MattFoley
Copy link
Author

Interesting. I still don't quite understand the additions of the ReadableMap and ReadableArray, since Objective C just uses built in types. Is this just due to JavaScriptCore functionality, no comparable functionality in native Java?

@ide
Copy link
Contributor

ide commented Feb 22, 2017

I'm not really sure, I imagine the fact that the authors were different people at different times has something to do with the discrepancy. The unified C++ bridge is coming which should clear away these differences in C++ if you prefer to program at that level.

@hey99xx
Copy link

hey99xx commented Feb 22, 2017

There was previously conversation in #9685

It's more correct to write (long)array.getDouble(index) and make the programmer think about the consequences of double -> long conversion.

If a programmer knows it's sending a large integer value, there's no choice other than using this forced casting code, which in my opinion leads to confusion rather than thinking about consequences of double -> long. The timestamps in Android/Java for example are mostly represented as longs since they're passed as milliseconds, using set/getLong would be the most natural for these.

it would be deceiving to provide set/getLong methods that don't work reliably

I think this is the real reason. Before exposing the method, we should make sure the types work correctly without potentially losing precision or overflowing while crossing Java/JS bridges.

Objective C just uses built in types

That's interesting. I'm also curious what Java lacks then.

The unified C++ bridge is coming

Unrelated to this issue, but is there any doc about this?

@ide
Copy link
Contributor

ide commented Feb 22, 2017

Unrelated to this issue, but is there any doc about this?

I think the source code is the best place to look, it's already in master.

@hramos
Copy link
Contributor

hramos commented Jul 25, 2017

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

  • Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
  • If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
  • Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

@hramos hramos added the Icebox label Jul 25, 2017
@hramos hramos closed this as completed Jul 25, 2017
@sound2gd
Copy link

@MattFoley maybe a solution for this.

                    double value = readableMap.getDouble(key);
                    try {
                        // long support && float check
                        if (value > Integer.MAX_VALUE && value % 1 == 0) {
                            long cv = (long) value;
                            // use the long value
                        }
                    } catch (Exception e) {
                        // use raw value
                    }

@facebook facebook locked as resolved and limited conversation to collaborators Jul 25, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

6 participants