API errors handling

[Bloomca]

Hi! Thanks for publishing your library.

So, what I can see, you have independence from state management, which is nice, also for standard inputs it is pretty declarative.

But I haven't found anything about how to fill errors from API (or just outside the form). We have such hooks inside child function, but it seems quite hacky to save such hooks to some closure and invoke later. Or maybe I just missed something?

[tannerlinsley]

1st question: what would be the use case for manually setting errors in a form. Shouldn't this be the responsibility of the validate lifecycle method? 2nd, technically you can use a component ref and use the instance of the form as you would internally. See here https://facebook.github.io/react/docs/refs-and-the-dom.html

…

On Fri, Dec 9, 2016 at 2:58 AM Seva Zaikov ***@***.***> wrote: Hi! Thanks for publishing your library. So, what I can see, you have independence from state management, which is nice, also for standard inputs it is pretty declarative. But I haven't found anything about how to fill errors from API (or just outside the form). We have such hooks inside child function, but it seems quite hacky to save such hooks to some closure and invoke later. Or maybe I just missed something? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCUvZQ6aM5NCh_2MhItjCjY9xdqhlks5rGSZFgaJpZM4LIwxD> .

[Bloomca]

1. Well, validate is a synchronous operation. So errors outside of client-side validation should be added manually. Even with async validation we still can run into this problem – imagine a situation when we have to show message near the input, if time run off.

2. But internally I won't use any refs! The idea is that API errors are the same errors as we have client-side, and sometimes it is not just a notification, but some info relevant to field. So it'd be nice to have this ability to render any errors natively.

[tannerlinsley]

I would love to see some pseudo code on your you might want this to work. Outside of this discussion I plan on adding some async capabilities really soon

…

On Fri, Dec 9, 2016 at 9:53 AM Seva Zaikov ***@***.***> wrote: 1. Well, validate is a synchronous operation. So errors outside of client-side validation should be added manually. Even with async validation we still can run into this problem – imagine a situation when we have to show message near the input, if time run off. 2. But internally I won't use any refs! The idea is that API errors are the same errors as we have client-side, and sometimes it is not just a notification, but some info relevant to field. So it'd be nice to have this ability to render *any* errors natively. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCd8NSfQT2rJ8DbNpWaZuQN7tBOPGks5rGYelgaJpZM4LIwxD> .

[dcolucci]

I notice validate passes state and props in addition to form values. Maybe this can help us. Modifying your Address example slightly (purposefully verbose & pedantic),

const AddressForm = Form({
  // here we pass state and props as well
  validate: (values, state, props) => {
    let streetError
    if (props.apiStreetError) {
      streetError = `we didn't find ${values.street} in our API!`
    }

    return {
      street: streetError,
      city: !values.city ? 'A city is required' : undefined,
      state: !values.state ? 'A state is required' : undefined
    }
  }
})(() => {
  return (
    <div>
      <Text
        field='street'
        placeholder='Street'
      />
      <Text
        field='city'
        placeholder='City'
      />
      <Text
        field='state'
        placeholder='State'
      />
    </div>
  )
})

And then somewhere else we could have something like

<AddressForm apiStreetError={true} />

Then potentially-async outside operations (talking to API, etc) could force a re-render of the form with relevant validation messages.

[tannerlinsley]

That's a good point. Its proving to be very flexible and that's a cool use of props

…

On Fri, Dec 9, 2016 at 12:13 PM David Colucci ***@***.***> wrote: I notice validate passes state and props in addition to form values. Maybe this can help us. Modifying your Address example slightly (purposefully verbose & pedantic), const AddressForm = Form({ // here we pass state and props as well validate: (values, state, props) => { let streetError if (props.apiStreetError) { streetError = "we didn't find that street in our API!" } return { street: streetError, city: !values.city ? 'A city is required' : undefined, state: !values.state ? 'A state is required' : undefined } } })(() => { return ( <div> <Text field='street' placeholder='Street' /> <Text field='city' placeholder='City' /> <Text field='state' placeholder='State' /> </div> ) }) And then somewhere else we could have something like <AddressForm apiStreetError={true} /> Then potentially-async outside operations (talking to API, etc) could force a re-render of the form with relevant validation messages. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCR9aMRsA2nPolYxpWwKXJyy8nsSqks5rGahugaJpZM4LIwxD> .

[tannerlinsley]

Have you tried overriding errors on the form using the errors prop? On Fri, Dec 9, 2016 at 12:17 PM Tanner Linsley <tannerlinsley@gmail.com> wrote:

…

That's a good point. Its proving to be very flexible and that's a cool use of props On Fri, Dec 9, 2016 at 12:13 PM David Colucci ***@***.***> wrote: I notice validate passes state and props in addition to form values. Maybe this can help us. Modifying your Address example slightly (purposefully verbose & pedantic), const AddressForm = Form({ // here we pass state and props as well validate: (values, state, props) => { let streetError if (props.apiStreetError) { streetError = "we didn't find that street in our API!" } return { street: streetError, city: !values.city ? 'A city is required' : undefined, state: !values.state ? 'A state is required' : undefined } } })(() => { return ( <div> <Text field='street' placeholder='Street' /> <Text field='city' placeholder='City' /> <Text field='state' placeholder='State' /> </div> ) }) And then somewhere else we could have something like <AddressForm apiStreetError={true} /> Then potentially-async outside operations (talking to API, etc) could force a re-render of the form with relevant validation messages. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCR9aMRsA2nPolYxpWwKXJyy8nsSqks5rGahugaJpZM4LIwxD> .

[dcolucci]

I haven't tried that nor any of the above, more just thinking out loud in response to original question. The above idea also relies on validate being called when the component receives new props, which it seems like it should since componentWillReceiveProps calls setFormState which calls validate.

[tannerlinsley]

Yep. Theoretically it would

…

On Fri, Dec 9, 2016 at 12:24 PM David Colucci ***@***.***> wrote: I haven't tried that nor any of the above, more just thinking out loud in response to original question. The above idea also relies on validate being called when the component receives new props, which it seems like it *should* since componentWillReceiveProps calls setFormState which calls validate. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCYQJEOU6eOiWkl5CcfzXH2Na6xWeks5rGarXgaJpZM4LIwxD> .

[tannerlinsley]

Honestly at this point, whatever needs to happen (as long as it aligns well with the api in the long run) I can build in fairly quickly. Just let me know what the most painless path to your goal is and I'll make your wildest dreams come true haha

[Bloomca]

Well, the most common use-case for API errors is after invoking submit method. I personally would expect explicit errors merge, but as @dcolucci pointed out, it is basically possible in validations using props. Sorry, missed this functionality (and I definitely think it should be reflected in documentation).

Thank you!

[thg303]

I tried that idea, and here is what happens:

1. Validate runs and passes initially.
2. Submit sends data to the API.
3. The form takes new props, but nothing changes the view, because validate does not run on componentWillReceiveProps and that's reasonable.

I think we need to add "errors" to the Form API, and make it gets merged by the form's errors. so using ref seems the only possible way.