Bind autorun's creation/delete to the lifecycle of Arrays/Maps/Object

[jtwigg]

I have a React app that utilizes WebGL and AudioContext very heavily, and as such, my React app has lots of sideffects.

I understand sideeffects are discouraged but Web GL and AudioContext are not stateless environments like React App; they're much more traditional stateful OOP environments (BabylonJS and Tone)

Accepting this requirement; its common that I need mutations in my Mobx state to be reflected in my 3d/audio state.

A simplified example might be a Song with many Track's with many Notes:

class Song {
    constructor() {
        makeAutoObservable(this)
    }
    @serializable(list(object(Track)))
    track: Track[]

}

class Track {
    constructor() {
        makeAutoObservable(this)
    }

    @serializable(list(object(Note)))
    notes: Note[]
}

class Note {
    constructor() {
        makeAutoObservable(this)
    }

    velocity: number
    beat: number
    semitone: string

}

When I add a new track, I want to start binding to the notes array of the track and bridge any new notes to the AudioEngine (not react). And when I modify an existing note's velocity, I want to immediately update the audio playback.

function registerSideEffectsNotes(track: Track, audioEngine: AudioEngine) {
    observe(track.notes, (changes) => {
        switch (changes.kind) {
            case "add":
                audioEngine.queueNote(track, changes.newValue)
                registerSideEffectsNote(track, changes.newValue, audioEngine)
            case "remove"
               // Somehow forget the dispose of the  old registerSideEffectsNote 
               //??
        }
    })
}

function registerSideEffectsNote(track: Track, note: Note, audioEngine: AudioEngine) {
    autorun(() => {
        audioEngine.updateVelocity(track, note.beat, note.velocity)
    })
}

In the above, I end up having tons of lifecycle changes to keep track of (add/remove/update) and also lots of cleanup to do.

Alternatives I've considered are

1. Just writing nested .forEach calls but this creates tons of extra refreshes
2. Follow through on the above code, but handling onAdded, onRemoved onUpdated styles of callbacks and cleanup
3. combine all mutations of mobx state with their side effects into actions. Challenges: injecting all the required state may become burdensome and break weak coupling.

Thoughts? Familiar pattern?

[mweststrate]

Note that it is correct these things are side effects, but you don't have to necessary run side effects as autorun/ observe, you might also run them as part of the action that triggers them directly, e.g. when the user changes the pitch, you could both update the state and trigger the effect.

Also not that both autorun and observe return a function that can be used to stop them.

[jtwigg]

Thanks for the feedback. I had forgotten to add that approach and have updated my list.

This very well may become my final approach, but I would say that the "con" is that my action's will have a rather heavy API because I have to inject all the side effect handlers along with the action (few/no globals allowed!)

Ex

action((track:Track, noteIndex:number, note: Partial<Note>. audioEngine: AudioEngine)=> {
  track.note[noteIndex] = {...  track.note[noteIndex], ... note}
  audioEngine.updateNote(track, noteIndex)
}

[kubk]

I'd also vote for action and effect collocation here. An advantage of collocation is that the code is easy to reason about, it does what it says and there are no hidden side effects. I'd encapsulate all the internals of WebGL / Audio API in dedicated classes and inject them wherever it's needed:

class Store {
  constructor(private webGl: WebGl, private audioEngine: AudioEngine)
}

It would be enough to do it once per class instead of doing it for every action.

[jtwigg]

Okay, one more digging in session:
Choices are
a) Creating an "ActionFactory" that is pre-populated with side-effect classes. Possibly use Provider and useContext

class ActionFactory {
   constructor(private audioEngine: AudioEngine) {}

    const updateNote = action((track:Track, noteIndex:number, note: Partial<Note>)=> {
        track.note[noteIndex] = {...  track.note[noteIndex], ... note}
        this.audioEngine.updateNote(track, noteIndex)
    }
}

export const ActionContext = React.createContext(new ActionFactory(new AudioEngine())

export const useActionContext = () => useContext(ActionContext)

// React class tsx

const actionFactory.= useActionContext()
actionFactory.updateNote(track, nodeIndex, { enabled: true} )

b) Inject the side-effect classes into the MobX classes directly (I've seen documentation on Dependency Injection, but can't find it now)

class Track {
     constructor(private audioEngine: AudioEngine) {
        makeAutoObservable(this)
    }

    @serializable(list(object(Note)))
    notes: Note[]

     updateNote(noteIndex: number, note: Partial<Node>) {
        this.notes[noteIndex] = {...  this.notes[noteIndex], ... note}
        this.audioEngine.updateNote(track, noteIndex)
     }     
}

I'm leaning towards A) since B is fraught with challenges, especially when
i) constructing new models: I have the same problem, where to get the Side effect classes.
ii) deserializing models from JSON: I have to handle empty constructors with serializr