onChange called when fields are being focused/blurred

[cmtt]

Hi, thanks for all the effort and quick updates.

I noticed an issue related to change detection: when a user focuses a field and blurs it, onChange is called. The change detection can be found in src/components/Form.js:

  componentWillReceiveProps (nextProps) {
    const didUpdate = !Utils.isDeepEqual(nextProps.formState, this.props.formState)
    if (this.props.onChange && didUpdate) {
      this.props.onChange(newState(nextProps.formState), this.getFormApi())
    }
}

As the entire formState is compared, onChange would be also called when solely internal meta data is changing.

In my use case, react-form renders forms of data sets whose updates should be persisted on a remote server.

This implementation results in unnecessary PUT requests without actual changes to the data.
In my view, the majority of users would expect onChange callbacks to fire when values are changing.

Suggestions (which obviously highly depend on the desired API):

• Use solely formState.value for change detection and/or
• Allow to provide additional callbacks which distinguish better between changed attributes, f.e. onValueChange, onTouchChange, onErrorChange etc.
• Allow to provide an optional custom change detector which receives the previous/next state.
• ...

[joepuzzo]

Hmm maybe we can add another function.. The onChange for the form is designed to work the way it does.. if you blur a field that is a change on the form. You can tie into the native on change at the input level and it will only fire when value changes but i can see how that also would not fit your need. For now you can just check yourself if values changed but i can look into adding this next commit.

[cmtt]

Thank you for the effort. 👍

[joepuzzo]

Been really busy lately but this is still on radar.

[jacargentina]

Also having this issue; this is a REAL problem when for example, by simply playing with moving through the fields without any change going on (same values) and then in my case the asyncValidate i've attached on the Form is firing on each move!

In my case i was expecting that the validation where called when there is real changes to data to be validated, and not always as it is now happening.

@joepuzzo I can make the PR, (have some time) if you bless the solution to this thing; may be an idea @cmtt posted there?

[joepuzzo]

Stand by for the release of my new lib.. informed. Lots of simplifications.. better docs, high test coverage and support for new context api and i got rid of redux dependency. I can add an onValueChange to that

[joepuzzo]

Oh and iterface is very similar. Should be very easy to hop over

[joepuzzo]

Sneak peak here https://joepuzzo.github.io/informed Just created an issue here https://github.com/joepuzzo/informed/issues/2

[nicoburns]

@joepuzzo What is the relation of Informed to React Form? Why create a new library rather than a new version of this one?

[joepuzzo]

Wanted to create a clean rewrite and im getting rid of some of the more complex features that 90% of people dont need. Im not the only owner of this lib also, so after talking to others we decided it would be best to create a new one.

[cmtt]

@joepuzzo: This is a bit discouraging, as it requires rewriting existing solutions.

A new framework doesn't resolve this specific issue and also react-form underwent already too many API changes in my view.

[jacargentina]

@joepuzzo: While waiting for the new lib, can we add the same thing you've implemented on informed here, and release?

[joepuzzo]

Informed is now live http://joepuzzo.github.io/informed

[cmtt]

Looks like a WONTFIX. Closing issue.

[joepuzzo]

I added this in informed

[cmtt]

@joepuzzo: This does not resolve this issue, as informed is a different project.

[joepuzzo]

Yup. I agree. But im no longer supporting this lib and if my understanding is correct niether is tanner. Therefore the best solution to this issue is to switch. I originally had a seperate form lib that was similar enough to react form that tanner and i decided to merge. Then react form became to large and hard to mantain for the both of us. We agreed that it would be best if i rewrote a more streamlined version as a seperate project.