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.