React-native-picker-select: (FIX) onValueChange being called twice

Created on 28 Sep 2020  路  2Comments  路  Source: lawnstarter/react-native-picker-select

Hello! 馃檪

As some other users have noted, it seems that there is often an issue with this library where the "onValueChange" function is called twice. (For example, see issues #311 , #265 , #242 , #180 , #112 ).

In my case, I had this issue while using the component with reduxForm, which made the component either: 1) bounce back to the previous value every time I tried to select something on iOS, or 2) simply not change anything when selecting a value on Android. (Probably the same thing was happening under the hood, the Android picker just wasn't animated).

I have solved the issue in my local app by replacing getDerivedStateFromProps with compononentDidUpdate in the index.js file of the react-native-picker-select component. I have opened a pull request ( #368 ) with the hope that it may solve others' problems as well.

Describe the bug

The picker doesn't work because the onValueChange call back is called twice, making the selected value reset itself each time. (See GIF).

To Reproduce

Create a custom Field component with the Redux Form library (such as the one I added below). Try to select a value on iOS or Android.

Expected behavior

New value is selected with no problems.

Actual behavior

Value is selected, but the onValueChange callback is immediately called again, forcing the value to go back to its previous state.

Screenshots

ezgif-2-1997a59fb427

Additional details

  • Device: iPhone11 simulator (or Android through AVD)
  • OS: iOS14 (or Android)
  • react-native-picker-select version: latest
  • react-native version: 0.63
  • expo sdk version: n/a

Reproduction and/or code sample

export class PickerField extends PureComponent<BaseFieldProps & PickerSelectProps> {
  getStyle = (params: { active?: boolean, dirty: boolean, invalid: boolean, style: any }) => {
    const { active, dirty, invalid, style } = params;

    let styleObj = { ...styles.inputContainerStyle, ...{ color: Colors.black } };

    if (active) {
      styleObj = { ...styleObj, ...styles.inputBoxActive }
    }
    if (dirty) {
      styleObj = { ...styleObj, ...styles.inputBoxDirty }
    }
    if (invalid) {
      styleObj = { ...styleObj, ...styles.invalidBox }
    }
    if (style) {
      styleObj = { ...styleObj, ...style, }
    }

    return styleObj;
  }

  renderPicker = ({ input, meta }: WrappedFieldProps) => {
    const { items, style, ...rest } = this.props;

    const { onChange, value } = input;
    const { invalid, active, dirty, } = meta;

    const combinedStyle = this.getStyle({ active, dirty, invalid, style });

    return (
      <RNPickerSelect
        value={value}
        items={items}
        onValueChange={onChange}
        style={{
          chevron: { display: 'none' },
          inputIOS: combinedStyle,
          inputAndroid: combinedStyle,
          iconContainer: {
            top: '50%',
            right: '2%',
            transform: [{ translateY: -(1 / 2) * this.iconHeight }],
          },
        }}
        // placeholder={{ label: I18n.t("SelectAnItem") }}
        useNativeAndroidPickerStyle={false}
        {...rest}
      />
    )
  }

  render() {

    const { name, validate } = this.props;
    return (
      <Field name={name} component={this.renderPicker} validate={validate} />
    )
  }
}

Most helpful comment

This is still an issue.
The way in which onValueChange is structured opens to a possible race condition between the internal state update and value prop coming from the parent component. To be more precise, when a controlled component triggers the onValueChange function, the onValueChange prop is called before the asynchronous internal state update. If the updated value prop is updated before the internal state is updated, then componentDidUpdate will detect a discrepancy between the previous selected value and the actual value prop, causing another invocation of onValueChange.

Here is a link showing the problem: https://snack.expo.io/L0LhveQem

A possible solution could be transforming the onValueChange function so that the onValueChange prop is invoked after the internal state update has been performed.

onValueChange(value, index) {
  const { onValueChange } = this.props;
  this.setState((prevState) => {
    return { selectedItem: prevState.items[index] }    
  }, () => onValueChange(value, index));
}

In addition, I cannot understand what this line of code is for: https://github.com/lawnstarter/react-native-picker-select/blob/ca6488c2eef5c776a8071400c8b7987712d43397/src/index.js#L161
I think everything will work fine even without this line. Am I wrong?

If you are ok with these observation I can provide a small PR to fix.

All 2 comments

This issue is present on Android in the new version of the package. It works fine on iOS.

This is still an issue.
The way in which onValueChange is structured opens to a possible race condition between the internal state update and value prop coming from the parent component. To be more precise, when a controlled component triggers the onValueChange function, the onValueChange prop is called before the asynchronous internal state update. If the updated value prop is updated before the internal state is updated, then componentDidUpdate will detect a discrepancy between the previous selected value and the actual value prop, causing another invocation of onValueChange.

Here is a link showing the problem: https://snack.expo.io/L0LhveQem

A possible solution could be transforming the onValueChange function so that the onValueChange prop is invoked after the internal state update has been performed.

onValueChange(value, index) {
  const { onValueChange } = this.props;
  this.setState((prevState) => {
    return { selectedItem: prevState.items[index] }    
  }, () => onValueChange(value, index));
}

In addition, I cannot understand what this line of code is for: https://github.com/lawnstarter/react-native-picker-select/blob/ca6488c2eef5c776a8071400c8b7987712d43397/src/index.js#L161
I think everything will work fine even without this line. Am I wrong?

If you are ok with these observation I can provide a small PR to fix.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dakairus picture dakairus  路  3Comments

dkniffin picture dkniffin  路  3Comments

Friendly-Robot picture Friendly-Robot  路  5Comments

ltsharma picture ltsharma  路  3Comments

Hristijan95 picture Hristijan95  路  4Comments