React-redux-form: Issues with setValidity/setFieldsErrors

[asvetliakov]

1. setFieldsErrors, the code:

                    dispatch(actions.setFieldsErrors(LOGIN_FORM_NAME, { 
                        email: {
                            server: "Test1"
                        },
                        password: {
                            server: "Test2"
                        }
                    }));

gives me this state (the error went into validity):

1. I think setValidity and similar methods should replace errors/validity in state rather than merge it

Use case:

• Client validation pass, send request to backend
• Backend fails and sets custom error
• These errors need to be removed when client changes input. Otherwise there no easy way (dispatch resetValidity()/resetErrors on each change before actual validating? or add stub to validators which returns always true? That doesn't make sense) to remove them.

[davidkpiano]

Hey, you're absolutely right. I'll probably end up adding actions to do the not-as-common merge behavior that's currently being exhibited:

• actions.mergeErrors(model, errors)
• actions.mergeFieldsErrors(model, errors)

And then do what you're describing for setErrors and setFieldsErrors. Sounds like a good game plan?

[asvetliakov]

Yes, sounds good :+1:
Also, you should mention in docs that modelReducer(name) should be mounted exactly in root.name , and you don't support immutable states for all action which returns action thunks (such as validate()) since you're calling get(getState(), modelPath) in them :smile:

[davidkpiano]

Also, you should mention in docs that modelReducer(name) should be mounted exactly in root.name

Good point, I thought I clarified that, but since others are asking questions, I'll add more clarity around that.

and you don't support immutable states for all action which returns action thunks (such as validate()) since you're calling get(getState(), modelPath) in them :smile:

Hmm, mind opening a separate ticket for that? This would be a good enhancement for v1.

[asvetliakov]

Hmm, mind opening a separate ticket for that? This would be a good enhancement for v1.

Sure

Good point, I thought I clarified that, but since others are asking questions, I'll add more clarity around that.

That was surprise for me (however after looking in code itself it became clear why). This breaks Form/Fields components too, so i ended dispatching actions in vanilla onChange/onBlur etc.. and happy now (almost :smile:)

[davidkpiano]

The funny thing is I can remove that enforcement with some sort of middleware, but I don't want to add that extra bit of boilerplate for the developer.

[davidkpiano]

@asvetliakov I did a major refactor that fixed this issue and normalized the behavior between validators and errors, so they can be used in harmony. Published as [email protected]!

[asvetliakov]

Wow, thank you!