Why use listeners and not just onChange?

[bennettdams]

Hey!

I would like to know about the intended use case of the "listeners" API.
The docs talk about "Side effects for event triggers", where you can execute something of the field changes, e.g.

"Country" input changes, "Province" field is resetted

The example has a listener on the "Country" field:

      <form.Field
        name="country"
        listeners={{
          onChange: ({ value }) => {
            console.log(`Country changed to: ${value}, resetting province`);
            form.setFieldValue("province", "");
          },
        }}
      >
        {(field) => (
          <label>
            <div>Country</div>
            <input
              value={field.state.value}
              onChange={(e) => field.handleChange(e.target.value)}
            />
          </label>
        )}
      </form.Field>

But why not just execute this update in the onChange function (at the <input /> element) of the "Country" field? Something like:

      <input
        value={field.state.value}
        onChange={e => {
          field.handleChange(e.target.value)
          form.setFieldValue("province", "")
        }}
      />

Is it just to have a cleaner separation of concerns or are the other benefits in using the "listener"?
Maybe the "listener" is executed after a succesful validation?
If so, I think it might be worth to add the difference between the two in the docs.

[sohamnandi77]

I feel listeners API is more useful in cases where we want to trigger event handlers of field based on other field's value change.

[juanvilladev]

I think it separates the concerns from the basic onChange updating the form with the new value and any side effects that should occur. On our project that contains complex validations it's a lifesaver.

[harry-whorlow]

It's really cool seeing people discuss the api 🤟

Well as you mentioned the separation of concerns, but also because onChange isn't the only event you can subscribe to.

• onChange
• onBlur
• onMount
• onSubmit

All those events can be subscribed to in the listeners api, could you imagine what your component would look like trying to subscribe to these events... And as everyone else has mentioned, handleChange should handle the change of the field value, its nice to be able to separate out the logic when you have dependent fields.

It also allows you to abstract away your components from the form field logic, so your NumberInput component doesn’t need to account for how it relates to other form fields, thats now the job of Field.

this

<Field
  name="age"
  children={(handleChange, state, ...// rest of props ) => (
    <NumberInput 
      state={state} 
      handleChange={(e) => {
        field.handleChange(e.target.value)
        form.setFieldValue("permissions", [])
      }}
      // rest of props
    />
  )}
/>

can become

<Field
  name="age"
  listeners={{
    onChange: ({ value }) => {
      setFieldValue('permissions', []);
    },
  }}
  children={(props) => (
    <NumberInput props={props} />
  )}
/>

But, that's more subjective, personally I prefer it.

Hope this helps explain the reasoning!

[bennettdams]

That makes a lot of sense, thank you! Maybe its worth adding such intentions and use cases to the docs?

[harry-whorlow]

No worries, happy to help!

Yeah it could be improved, however I think the maintainers have a lot on their plate ATM. Perhaps, at a future date a PR could be opened, I just don't want to bother them too much right now.