Triggering an action from a reaction?

[Psidium]

Hello everyone,

I'm having trouble understanding the anti-pattern of triggering an action inside a reaction (as stated in the issue #1006).
My use case is this: I have a huge form (300+ input fields) that requires some fields to change their value based on the value assumed by other fields.

The code below shows what I think would be a good solution to my use case. In the example, I want to clean the field breed if that breed is not valid for the selected petType.

But apparently using a reaction to change another value in my model is a MobX anti-pattern.
The comments on the linked issue suggest moving my checks and assignment to the action that triggers the reaction, but this level of coupling from data change to reaction hasn't scaled well in our project due to the huge amount of data manipulation happening in every user interaction.

Finally, my question is:
If triggering an action inside a reaction is an anti-pattern, how would I change the fields in my model in response to earlier model changes?

Model

class Form {
  public petType = "";
  public breed = "";
  public availablePetTypes: string[] = [];
  public availableBreeds: Breed[] = [];

  constructor() {
    mobx.makeObservable(this, {
      petType: mobx.observable,
      breed: mobx.observable,
      availableBreeds: mobx.observable,
      availablePetTypes: mobx.observable,
      setPetType: mobx.action,
      setBreed: mobx.action,
      addAvailablePetType: mobx.action,
      addAvailableBreed: mobx.action,
      validBreeds: mobx.computed
    });
  }

  get validBreeds(): Breed[] {
    return this.availableBreeds.filter(
      ({ petType }) => petType === this.petType
    );
  }

  // setters
  public setPetType(petType: string): void {
    this.petType = petType;
  }
  public setBreed(breed: string): void {
    this.breed = breed;
  }
  public addAvailablePetType(petType: string[]): void {
    this.availablePetTypes = petType;
  }
  public addAvailableBreed(breeds: Breed[]): void {
    this.availableBreeds = breeds;
  }
}

interface Breed {
  petType: string;
  breed: string;
}

Data setup

// setup:
const form = new Form();
form.addAvailablePetType(["cat", "dog"]);
form.addAvailableBreed([
  {
    breed: "Brazilian Shorthair",
    petType: "cat"
  },
  {
    breed: "Siamese",
    petType: "cat"
  },
  {
    breed: "Corgi",
    petType: "dog"
  },
  {
    breed: "Bulldog",
    petType: "dog"
  }
]);

Input jquery binding

// binding in the screen
$("#pet-type").keyup(function(this: JQuery, event) {
  const value = $(this).val();
  form.setPetType(value);
});

And this is how I thought I would write my business rules:

mobx.reaction(
  () => form.validBreeds,
  (validBreeds: Breed[]) => {
    if (!currentBreedIsStillValid(validBreeds)) {
      form.setBreed("");
    }
  }
);

function currentBreedIsStillValid(validBreeds: Breed[]) {
  return validBreeds.some(({ breed }) => breed === form.breed);
}

Solution with the validation in the setter

  function setPetType(petType: string): void {
    this.petType = petType;
    if (!currentBreedIsStillValid(this.breed)) {
      this.breed = "";
    }
  }

[urugator]

If the business rule is that the field must be validated every time it's being modified, then setting a value and validating a value is coupled by design - there must be a place that couples these two actions and makes sure that you cannot invoke one without the other.
Reaction is basically globally shared event bus, it doesn't remove coupling, it just allows you to create the coupling ad-hoc - you can connect (and disconnect) anything to anything anytime anywhere. How do you want to reason about something like that?
Consider you want to know how the state changes when form.setPetType(value); is called. Unless someone gives you a list of all reactions you're unable to tell. But even then it's very hard to follow what triggers what and when beside simple examples.
The problems don't end here:

• reaction invocation order is undefined
• reaction doesn't run immediately on change
• it breaks batching, because multiple reactions can't be batched into one
• harder debugging, error handling etc

change the fields in my model in response to earlier model changes?

Avoid the need for doing so by designing things differently, use composition.

[Psidium]

Thank you for your answer, it has really helped me better understand MobX.
Our current UI architecture is super indirect, with an eventbus sending around 15 events per change (we don't have a unidirectional data-binding architechture) and our codebase is very verbose because of it, we will have to change our design instead of just applying it on top of mobx;
The main reason for me is it breaks batching because multiple reactions can't be batched into one, because the reason I'm evaluating MobX is to trigger as few changes from the model as possible, which is defeated when using reactions.

[urugator]

I don't recommend using it (for similar reasons mentioned above), but for completeness, observe(atom, changeListener) can observe only single observable, but listener runs immediately on change (no batching).
EDIT: reaction/autorun vs observe