Adds value and onValue props to WidgetMixin so we can store state in Redux store

[danielweinmann]

class Form extends Component {
  render() {
    return (
      <GiftedForm formName="yourForm">
        <GiftedForm.TextInputWidget
          name='fullName'
          value={this.props.yourReduxReducer.fullName}
          onValue={yourReduxActionThatWillReceiveValue}
        />
      </GiftedForm>
    )
  }  
}

export default connect(state => ({
  yourReduxReducer: state.yourReduxReducer,
}))(Form)

What do you think, @FaridSafi? I believe it is 100% compatible with old usage and ads capability to use it with Redux/Flux.

[danielweinmann]

The way it is implemented, we will have to have 1 redux action per input widget. I did this because it is what I need in my project.

But it would be easy to implement 1 redux action for the whole form using onValidation prop on GiftedForm instead of onValue ;)

[FaridSafi]

Hi, I don't have so much experience with Redux/Flux so I trust you with that. We may have a conflict for the "value" prop, as it's also used in OptionWidget and HiddenWidget (and maybe another?)

What about a different name?

[danielweinmann]

Let me take a closer look ;)

[danielweinmann]

@FaridSafi, from what I could test and understand:

1. HiddenWidget is functional and now it can receive new value prop over time. Before my changes it would get stuck with initial value prop.
2. OptionWidget too, but I couldn't think of a scenario where an OptionWidget would change its value over time. Thus, there should be no changes in behaviour in this case.
3. CellWidget will not work as of now if we pass value prop.
4. DayPickerWidget, SelectWidget, ModalWidget will not change their behaviour but will not use value prop properly for now. In my project I don't have any need for them so far, so I suggest we leave it for the future. I think it wont break anything.

I removed onValue prop from WidgetMixin and added onValueChange to ContainerMixin, so we can manage all changes in the same place.

I added instructions and example to the README and asked for PR's :) what do you say?

[FaridSafi]

Hello, amazing work @danielweinmann ! I have few questions before publishing

• Regarding https://github.com/danielweinmann/react-native-gifted-form/commit/75a91fb720e476ba8cad892c3fd2f64e656bdf09 I think GroupWidget should also pass onValidation and onValueChange isn't it?
• According to you, what should be done to make external storing compatible with all widgets ?

Also I think I will remove soon DayPickerWidget from the library since a crossplatform datepicker is coming in react-native core

[danielweinmann]

Thanks, @FaridSafi!

• I believe GroupWidget should pass onValidation and onValueChange, indeed. Can you do it? I wont be able to to it for some time now.
• I tried to implement it with SelectWidget and it was a little tricky, specially because it is usually used together with ModalWidget and I would have to receive value prop in one of them and translate into true/false values in OptionWidget. I believe it would depend on the implementation of each widget (I don't use them yet, so I don't know much).

But for the last few days I've been thinking that everything would be simpler if we didn't try to manage state at all, and GiftedForm was a presentational-only set of widgets. They would receive their values, error messages, etc, from props, inform changes in the values through form's onValueChange and that's it.

The whole state management, validation, etc, logic would be outside of the presentational layer. And then we could choose between using react's default state management, together with validator.js or not, or Redux Form (http://erikras.github.io/redux-form/#/?_k=mznz7a), or anything else.

It would be a big departure from what we currently have, and I cannot invest the time to do it now, but from an architecture point of view it seems like the way to do it.

What do you think of this line of thinking?

[FaridSafi]

I added support for GroupWidget and published 0.0.5

The whole state management, validation, etc, logic would be outside of the presentational layer. And then we could choose between using react's default state management, together with validator.js or not, or Redux Form (http://erikras.github.io/redux-form/#/?_k=mznz7a), or anything else.

I agree with you, for the next big version I want also to make this component compatible with React for Web

Thank you for your time!

[danielweinmann]

That's great! Thank you for the package and for maintaining it :)

I'll keep contributing whenever I can!