automatic / computed references between dependent entities

[BrianHung]

Is there a way to keep references up to date between two entities. Here, I have a simple model with Row and Table. Every time that a row is created, it should be added to the rows of the table that matches the new row table id; similarly, for row and table deletion.

const Row = t.model("row", {
  id: t.refinement(t.identifier, id => isUUID(id)),
  order: t.string,
  table: t.reference(t.late((): IAnyModelType => Table)),
})

const Table = t
  .model("table", {
    id: t.refinement(t.identifier, id => isUUID(id)),
    rows: t.map(t.reference(t.late((): IAnyModelType => Row))),
  })
  .actions(self => ({
    addRow: (row) => void (self.rows.set(row.id, Row.create(row))),
  }))

const State = t.model("state", {
  tables: t.map(Tables),
  rows: t.map(Row),
})

My newbie intuition is to use listeners such as onSnapshot and autorun (https://mobx-state-tree.js.org/concepts/listeners) to establish row-to-table and table-to-row listeners, but is there a way to automate these CRUD operations when defining the models?

A simpler problem with one entity is automatic managing parent-children dependencies. If a child node is added or deleted, is there a way to update the children map of its parent? Is there a way to delete all children recursively if a parent is deleted?

const Node = t.model("node", {
  id: t.refinement(t.identifier, id => isUUID(id)),
  children: t.map(t.reference(t.late((): IAnyModelType => Node))),
  parent: t.reference(t.late((): IAnyModelType => Node))
})

(Sorry if the question is too basic; new to mobx and mst, and don't know how to model and update entities compared to Postgres 😅 ).

[BrianHung]

I have found a naive solution using views which access root, and references which delete rows when tables are deleted. Not sure how performant this is. This also abuses unprotect to put addRow under a table entity.

// Equivalent of a cascading deletion when foreign key is deleted.
export const deleteSelf = ({ cause, parent }) => void (cause == "destroy" && remove(getParent(parent), parent.id));

const Row = t
  .model("row", {
    id: t.refinement(t.identifier, id => isUUID(id)),
    order: t.string,
    table: t.reference(t.late((): IAnyModelType => Table), { onInvalidated: deleteSelf }),
  });

const Table = t
  .model("table", {
    id: t.refinement(t.identifier, id => isUUID(id)),
  })
  .views(self => ({
    get rows() {
      return values(getRoot(self).rows).filter(row => row.table.id == self.id);
    }
  }))
  .actions(self => ({
    addRow: (row) => {
      const root = getRoot(self);
      unprotect(root); // mst doesn't like when subtrees modify their parents
      set(root.rows, row.id, {...row, table: self.id});
      protect(root);
    }
  }))

const State = t
  .model("state", {
    tables: t.map(Tables),
    rows: t.map(Row),
  })

[antondomratchev]

This is a clear indication that your action needs to live higher in the tree.

.actions(self => ({
    addRow: (row) => {
      const root = getRoot(self);
      unprotect(root); // mst doesn't like when subtrees modify their parents
      set(root.rows, row.id, {...row, table: self.id});
      protect(root);
    }
  }))

Also, any specific reason to keep your references in a map? A simple list would work better since the snapshot would be just a list of strings.

[BrianHung]

This is a clear indication that your action needs to live higher in the tree.

That is true; I have moved to "global actions" on the root state but before that

// preferred
table.addRow(rowId);
// works but requires tableId which feels redundant if table is already accessed
state.addRow(tableId, rowId);

Also, any specific reason to keep your references in a map?

Easier to put, get, delete individual values using just the id. Re-ordering rows by using a prop on row results in less patches being produced than using an explicit list, which would move any rows after the first one that's re-ordered.

[antondomratchev]

Totally fine to use a map for the actual rows for example in state but on the reference this isnt necessary, anytime you access the reference you are going to get the value. This is revealing that state that lives higher in the tree must be CRUDed at that level. If you prefer to have an API that allows children to manipulate siblings then the child must proxy the action to the parent.

so you can still have table.addRow/1 but it would forward the call to the parent of state.addRow/2

[BrianHung]

but on the reference this isnt necessary, anytime you access the reference you are going to get the value

A bit confused where you see a map of references not at the root level. Are you talking about the computed list

  .views(self => ({
    get rows() {
      return values(getRoot(self).rows).filter(row => row.table.id == self.id);
    }
  }))

I think because its a view, it doesn't get serialized at all during a snapshot (which is fine as long as state.rows gets serialized).

so you can still have table.addRow/1 but it would forward the call to the parent of state.addRow/2

Yeah I found a slightly worse DX but not too annoying 😅 . How would you proxy the action to the parent in MST? I used unprotect as I thought subtrees cannot directly modify its parents by default.

[antondomratchev]

A bit confused where you see a map of references not at the root level. Are you talking about the computed list

My apologies I was looking at the first example of the code you provided. Where Table model was defining rows as a property.

How would you proxy the action to the parent in MST? I used unprotect as I thought subtrees cannot directly modify its parents by default.

You can use something like getRoot(self).addRow(self.id, row) this code assumes that current model is attached to the root node and the root node has a addRowaction. I tend to sprinkle a root

get root() {
  return getRoot(self);
}

view across my child models because i often dive to the root of the tree and traverse back down another path.
See more info about getRoot here: https://mobx-state-tree.js.org/API/#getroot

[BrianHung]

getRoot(self).addRow(self.id, row)

Ah this makes sense; I think forwarding calls will work!

get root() {
  return getRoot(self);
}

Is this more optimized than call getRoot(self) in an action?

[antondomratchev]

Not really, i tend to use it across multiple actions and like the signature of self.root instead of getRoot(self) personal preference is at work here.

[coolsoftwaretyler]

Marking @antondomratchev's answer as correct here based on the discussion. Thanks, y'all!