[Bug]: NaN cannot be returned on iOS

[robingenz]

Capacitor Version

💊 Capacitor Doctor 💊

Latest Dependencies:

@capacitor/cli: 5.7.0
@capacitor/core: 5.7.0
@capacitor/android: 5.7.0
@capacitor/ios: 5.7.0

Installed Dependencies:

@capacitor/cli: 5.4.2
@capacitor/android: 5.4.2
@capacitor/core: 5.4.2
@capacitor/ios: 5.4.2

[success] iOS looking great! 👌
[success] Android looking great! 👌

Other API Details

No response

Platforms Affected

• iOS
• Android
• Web

Current Behavior

The Capacitor Firebase Firestore must be able to receive and return a NaN value. Under iOS it is already possible to pass a NaN value to a plugin. Unfortunately, there are problems with returning the value, see the following example:

@objc func getDocument(_ call: CAPPluginCall) {
    call.resolve([
        "test": Double.nan
    ])
}

Capacitor returns an empty object. Not only is the NaN value missing, but all other keys would also be missing.

Expected Behavior

It should be possible to return a NaN value from a plugin.

Project Reproduction

https://github.com/robingenz/capacitor-firebase-plugin-demo/blob/main/src/app/modules/firebase-firestore/firebase-firestore.page.ts

Additional Information

No response

[markemer]

This is always going to behave strangely since NaN is not supported in JSON: RFC-4627 Section 6

We use JSON.stringify type functions to pass data back and forth between the bridge and the native platforms and they have a variety of undefined behavior with NaN or Infinite IEEE-754 values.

[robingenz]

@markemer Thank you for your response!

A possible solution would be to replace NaN with a custom JSON object before passing it to the bridge and restore it on the native side.

Example:

{
	"_cap_type": "nan"
}

I have planned the same, for example, to support Cloud Firestore field values (see capawesome-team/capacitor-firebase#443), except that the implementation there is located in the plugin and not in the Capacitor core.
With NaN, however, this implementation must be placed in the Capacitor core, as this value is not plugin-specific and can also be returned.

Could you please discuss this again in the team?

[theproducer]

@robingenz Hello!

Yes, a similiar approach was my initial idea for handling this, but Mark metioned, we use JSON parsing/encoding for communicating back and forth, and we decided just to stick with what is natively supported in JSON, at least for now. There are ideas / opportunities in the future for us to be able to accomidate this however.

[ionitron-bot]

Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Capacitor, please create a new issue and ensure the template is fully filled out.