Add useAutorun and useReaction hooks

[LandonSchropp]

In my current project, I've built useAutorun and useReaction hooks. These have turned out to be very useful for my project, and I thought they'd be helpful for other people as well. I think they'd make sense as part of the mobx-react-lite package.

import { autorun } from "mobx";
import { useEffect } from "react";

/**
 * This hook is just like the standard MobX autorun function, but it hooks into the React component
 * lifecycle. This means the set up for the autorun only happens once, and it's automatically
 * disposed of when the component unmounts.
 *
 * @param effectFunction The function that's called when the store's properties are changed. This
 * function is called initially when the autorun is initialized.
 * @param dependencies The non-MobX dependencies that should retrigger the callback.
 */
export function useAutorun(effectFunction, dependencies = []) {
  useEffect(() => autorun(effectFunction), dependencies);
}

import { reaction } from "mobx";
import { useEffect } from "react";

/**
 * This hook is just like the standard MobX reaction function, but it hooks into the React component
 * lifecycle. This means the set up for the reaction only happens once, and it's automatically
 * disposed of when the component unmounts.
 *
 * @param dataFunction This function determines what data will trigger the effect function to rerun.
 * Only the *accessed* data is important in this function—not the return value.
 * @param effectFunction The function that's called when the store's properties are changed. This
 * function is called initially when the autorun is initialized.
 * @param dependencies The non-MobX dependencies that should retrigger the callback.
 */
export function useReaction(dataFunction, effectFunction, dependencies = []) {
  // eslint-disable-next-line react-hooks/exhaustive-deps
  useEffect(() => reaction(dataFunction, effectFunction), dependencies);
}

I know these functions aren't many lines of code, but I still think it's worth including them because getting them right was a little tricky and took me a few tries.

Please let me know if you'd like some examples of how I'm using these hooks and why they were helpful. Thanks!

[kubk]

In my opinion it shouldn't be included in the core. People use Mobx in different ways because it doesn't enforce any architectural patterns. In our team we try to not mix mobx specifics (like autorun/reaction) with components. Moreover we try to avoid autorun/reaction as much as possible: #1006 (comment)

Screenshot:

[LandonSchropp]

I agree autorun and reaction should be avoided when possible, and often can be replaced by a better approach. In my app (a chess app), I'm using them in a couple of specific circumstances.

When the chessboard store's position updates, I play a sound using the use-sound library.

export const ChessboardAudio = observer(({ chessboard }) => {
  let playMoveSound = useAudio(moveSound);
  useReaction(() => chessboard.position, playMoveSound, [ chessboard ]);

  return null;
});

I also use them when interacting with the cm-chessboard JavaScript library that renders my chessboard into the DOM.

export const Chessboard = observer(({ chessboard }) => {
  let chessboardRef = useRef(null);
  let cmChessboardRef = useRef(null);

  // cm-chessboard initialization omitted

  useAutorun(() => {
    cmChessboardRef.current.setPosition(chessboard.position)
  });

  return <div ref={ chessboardRef } />;
});

I think both of these examples are good use cases for autorun and reaction, and I think there are times when these functions are helpful. I would imagine others would find these hooks helpful as well if they were available.

[kubk]

@LandonSchropp Thank you for the examples, I understand your usecases. I only want to say that people use Mobx in different ways and for example try to avoid autorun / reaction at all. I'd implement it like this:

class ChessboardStore {
  ...
  
  setPosition(position) {
    this.position = position;
    this.soundPlayer.playMoveSound();
    this.chessboard.setPosition(this.position);
  }
}

Because "It's immediately visible which action leads to which effects and how the data flows."
Also you can easily write a unit test for it:

it('plays sound when position updates', () => {
  const soundPlayer = { playMoveSound:  jest.fn() };
  const chessboardStore = new ChessboardStore(soundPlayer);
  chessboardStore.move('e2-e4');
  expect(soundPlayer.playMoveSound).toHaveBeenCalled();
})

You don't have to render react components to test such logic. Better separation between logic and view.
Feel free to use the way you like. But I am trying to say that introducing this new API might be unneeded for lots of people because they won't use it.

[LandonSchropp]

I totally appreciate your perspective, and thanks for taking the time to write out some alternatives to my approach.

In my case, I really wanted to keep sounds in my components because it feels like they're part of the presentation of the application, not part of the core state. For example, I use my chessboard store extensively when determining if a set of moves are valid, and I don't necessarily want sounds to play. I could configure the store, but it seems more natural to just include the audio component when I want sounds to play in my UI.

Of course, all of this is just application design, and I don't really think there' a right answer. Your approach is perfectly viable as well. 🙂

[urugator]

little tricky and took me a few tries.

Actually very tricky, check mobxjs/mobx-react#772

Eg. in your impl, when dependency changes, one would expect the reaction's effect being re-triggered, but that's not what happens - it will only recreate the reaction (without firing the effect and also loosing the cached result). Another problem is state/props and observables possibly being out of sync as mentioned in the issue.

[LandonSchropp]

Ouch, that is tricky. In my particular use cases, I wasn't concerned about that, because I really only wanted my effect function to fire when the observable properties change, but I could definitely see that being an issue in other use cases.

I do think there are solid use cases for using useReaction and useAutorun, although I agree with the consensus that there's usually an easier or better way when using any reaction or autorun functions. I'm not trying to ruffle any feathers here, but the hooks solved a thorny problem in a simple and elegant way in my app. As a bonus, useEffect handles cleanup of autorun and reaction, which is where I personally have usually run into the most problems.

[pdfowler]

I've implemented an almost identical useAutorun function, but haven't yet started using it widely in our app. Currently our app is littered with ad hoc useEffect hooks returning an autorun to better handle the general discord between state and observables. I've found that it is far too easy to put an observable into the dependency array of useEffect, only to have nothing happen. This is especially true for our newer team members who haven't been exposed to mobx before.

I would go as far as calling useEffect a footgun in a Mobx project and would happily give a +1 to any proposal to have a de facto version of useAutorun either in the library, or as a separate module.

@LandonSchropp have you, or anyone else, run into problems, or see any problems with the useAutorun hook as written?

[LandonSchropp]

It's been working great in my app so far! I haven't run into any unexpected problems or bugs. However, my application avoids the issue @urugator mentions, so I didn't bother to try and handle that in the hooks I built.

[urugator]

put an observable into the dependency array of useEffect

I think you could have a check for that:

function useEffect(effect, deps) {
  if (__DEV__ && Array.isArray(deps) && deps.some(dep => isObservable(dep))) {
    throw new Error(`useEffect dependencies must not contain observables, ...`)
  }
  React.useEffect(effect, deps);
}

It's not bulletproof (because it's not about observability, but mutability) and you would have to pass individual actions rather than whole store to the effect (which is in principle correct, but likely a chore).

useEffect a footgun in a Mobx project

Generally a footgun is mixing observable and non-observable state and I do admin it's not completely avoidable.
I think useEffect(() => autorun(effect), deps); will do what you would expect most of the time. Just keep in mind, that if the autorun is invalidated due to an observable, it won't wait for the component to update - therefore the autorun may see outdated props/state/DOM(#3058).