Decorating Not Bounded Functions

[BrianHung]

I have a set of utility functions which take in the root state and modifies it using actions on the state model itself (and or its children models). I'm noticing that decorate(atomic, utility) doesn't work since the utility functions don't have an action context / aren't bounded to the model's actions.

Is there a MST method to wrap utility functions in an action context, like in mobx there is runInAction, action, or transaction?

[coolsoftwaretyler]

Hey @BrianHung - I think runInAction will just work here. I'm not exactly sure what you're trying to do, but here's a CodeSandbox with a quick demo: https://codesandbox.io/s/twilight-currying-wjv9ff?file=/src/index.ts:400-420

If that doesn't solve your problem, can you share some code to show me more specifics and I can try to help out?

[BrianHung]

https://codesandbox.io/s/affectionate-lucy-fn484d?file=/src/index.ts

import { types, decorate } from "mobx-state-tree";
import { runInAction } from "mobx";

const Todo = types
  .model("Todo", {
    id: types.identifier,
    title: types.string,
    completed: false
  })
  .actions((self) => ({
    toggleCompleted() {
      self.completed = !self.completed;
    }
  }));

const TodoStore = types
  .model("TodoStore", {
    todos: types.array(Todo)
  })
  .actions((self) => ({
    addTodo(todo) {
      self.todos.push(todo);
    }
  }));

const store = TodoStore.create({
  todos: [
    {
      id: "1",
      title: "First",
      completed: false
    }
  ]
});

// Utility function that calls the MST action
function toggleTodoCompletion(todo) {
  runInAction(() => {
    todo.toggleCompleted();
  });
}

function middleware(call, next, abort) {
  console.log("This is never called.", call, next);
  next(call);
}

const decorated = decorate(middleware, toggleTodoCompletion);

console.log(store.todos[0].completed);
decorated(store.todos[0]);
console.log(store.todos[0].completed);

[BrianHung]

An example of a function that's similar is applyPatches: https://github.com/mobxjs/mobx-state-tree/blob/7aec7bff78fbcfda7c896358ffb4ed0744578de8/packages/mobx-state-tree/src/core/node/object-node.ts#L498C20-L512

See how it uses createActionInvoker to create an action context binded to the tree node.

I think to implement this, we would need to export createActionInvoker.

const toggleTodoCompletion = createActionInvoker(
  store,
  "toggleTodo",
  (todo) => {
    todo.toggleCompleted()
  }
)

[coolsoftwaretyler]

Thanks @BrianHung! I see what you mean, now, and I think I understand why the standard decorate use doesn't work for you, based on where you're setting up the utility function (outside the bounds of the model itself).

I'm not opposed to making createActionInvoker public, but if we can avoid adding to the API, I think it's worth it to avoid expanding an already large API surface.

Does addMiddleware help? If you were to do something like this:

import { addMiddleware, types } from "mobx-state-tree";
import { runInAction } from "mobx";

const Todo = types
  .model("Todo", {
    id: types.identifier,
    title: types.string,
    completed: false
  })
  .actions((self) => ({
    toggleCompleted() {
      self.completed = !self.completed;
    }
  }));

const TodoStore = types
  .model("TodoStore", {
    todos: types.array(Todo)
  })
  .actions((self) => ({
    addTodo(todo) {
      self.todos.push(todo);
    }
  }));

const store = TodoStore.create({
  todos: [
    {
      id: "1",
      title: "First",
      completed: false
    }
  ]
});

function middleware(call, next, abort) {
  console.log("This is called now.", call, next);
  next(call);
}
// Utility function that calls the MST action
function toggleTodoCompletion(todo) {
  const disposeMiddleware = addMiddleware(store, middleware);
  runInAction(() => {
    todo.toggleCompleted();
  });
  disposeMiddleware();
}

console.log(store.todos[0].completed);
toggleTodoCompletion(store.todos[0]);
console.log(store.todos[0].completed);

Sandbox: https://codesandbox.io/s/compassionate-herschel-h6z7zm?file=/src/index.ts

I know it's not exactly the same ergonomics as decorating your function with a middleware. But I'm assuming you want to do that so that you get middleware on one particular function call, and don't add it to the whole tree.

In this scenario, you could add a middleware to your target store, get the Disposer function, and call the disposer at the end of your utility function to clear out the middleware.

What do you think? does that solve your use case? Or should we start exploring a way to expose createActionInoker?

Perhaps there's some way for us to consider exposing lots of internals to power users. You have a lot of advanced use cases, and I imagine there are a few others out there with the same. I've read lots of stories of people forking or exposing MST internals for these kind of in-depth use cases. Maybe there's a desire out there to just get something like advancedMSTInternals that exposes a bunch of utilities.

[BrianHung]

What do you think? does that solve your use case? Or should we start exploring a way to expose createActionInoker?

No, I need an explicit action context for the function, since I'm using middlewares binded to the root store for undo / redo and for analytics. And in both cases, I need things like call.name and call.args.

Essentially, I have some external actions that I don't want explicitly to be binded to root store, since they're more UI only / synced third-party React state management libraries. But I want middlewares to still track these external actions.

createActionInvoker would be the perfect export here the more I think about it.

I've read lots of stories of people forking or exposing MST internals for these kind of in-depth use cases.

Yep, I have a lot of duplicated code copied and pasted from MST 😂 Maybe they can be exported with an @advanced tag.

[coolsoftwaretyler]

Hey @BrianHung - I'm just going through the backlog of discussions. I've softened my stance on adding to the API if you really need it exposed. If that's something you're still looking for, go ahead and submit a PR with some updated tests/docs for us and we can get that added to a minor release sometime soon.