React-native: "invalid attempt to spread non-iterable instance" error only for android when trying string spread

[skuzoluk]

Environment

React Native Environment Info:
System:
OS: macOS High Sierra 10.13.6
CPU: x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
Memory: 809.96 MB / 16.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 8.9.2 - /usr/local/bin/node
Yarn: 1.0.2 - /usr/local/bin/yarn
npm: 6.3.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.0, macOS 10.14, tvOS 12.0, watchOS 5.0
Android SDK:
Build Tools: 26.0.1
IDEs:
Android Studio: 3.1 AI-173.4907809
Xcode: 10.0/10A255 - /usr/bin/xcodebuild
npmPackages:
react: ^16.5.0 => 16.5.0
react-native: ^0.57.2 => 0.57.2
npmGlobalPackages:
create-react-native-app: 1.0.0
eslint-plugin-react-native: 3.2.0
react-native-cli: 2.0.1
react-native-gesture-handler: 1.0.0-alpha.29
react-native-git-upgrade: 0.2.7
react-native-rename: 2.2.2
react-native-vector-icons: 4.4.2

Description

In debug mode everything is working as expected. But after bundling, when using spread operation to convert string to array, only Android (platform independent) throws error. But ios works well (both debug and production). The code was working well before updating RN 55.4 to 57. After update I had to change the code to this working example:

Array.from(str).map((p, i) => {return p;})

Reproducible Demo

Error example:

const str = 'error test';
[...str].map((p, i) => {return p;})

The approach is right but what is the problem with babel 7?

[helleroy]

We encountered this as well:

• Works fine in dev-mode on both iOS and Android
• Works fine with release bundle on iOS
• Hard crash with release bundle on Android

After some testing we found that setting loose to true for @babel/plugin-transform-spread solves the problem.
This indicates that the problem either lies with Babel 7 or with how react-native/metro handles the bundling of Android apps using Babel 7.
javascript "plugins": [ ["@babel/plugin-transform-spread", { "loose": true }] ]
Doing this may cause problems in other parts of our code though, so we elected not to use it.

In the end we ended up using Array.from(str) instead of [...str] as mentioned in the description.
However, considering how this breaks what is literally the first example in the MDN docs, it should probably be looked into.

[sibelius]

[...Array(3).keys()] is causing trouble on android as well

[gausam]

Is there a fix coming for this then? Or must we all resort to similar refactors?

[abartolo]

Any update on this? :(

[abartolo]

@all I was able to pin point my issue. For some reason spreading keys() was the issue so I changed up the logic to use lodash/times just to be sure and it turned out that solved it.

I hope this helps anyone having similar weird issues.

Issue

{
...randomPropsAbove
periodOptions: [...Array(props.maxPeriods).keys()].reduce((acc, val, index) => {
        acc.push({ value: index + 1 });
        return acc;
      }, []),
}

Fix

{
...randomStuffAbove
periodOptions: times(props.maxPeriods, val => val).reduce((acc, val, index) => {
        acc.push({ value: index + 1 });
        return acc;
      }, []),
}

[RukaiJohn]

Array.from(str) really worked

[lucasgouvea]

In my case, I was spreading an empty array, which works on development ENV, but won't work on the release apk.

Easy workaround: check if the array isn't empty before spread.

[stale[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

[stale[bot]]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.