Representing array of models in the state tree about mobx-state-tree

[mweststrate]

This should give a rough idea:

https://github.com/mweststrate/mobx-state-tree/blob/0d0c5e1c70ff0dcea7fce53d1f10d97e661f33de/examples/boxes/src/stores/domain-state.js#L44

The referenceTo is interesting; it creates a normal string property in which the identifier is stored, and a setter and computed getter to resolve the identifier with the provided path.

Note that you don't have to resolve via strings, you can also introduce a computed property yourself, and write something like:

selectionId: '123'
get selection() {
   if (hasParent(this))
     return getParent(this).boxes.get(this.selectionId)
   return null
}

Resolving a list of identifiers is still on the todo list, but will be part of the first version :)

Sorry for not having docs yet, they will be added, but ATM this is quite alpha :)

[antitoxic]

I'm kind of lost :)

I understand it's alpha, no worries. With the risk of sounding silly, what's the benefit of using mobx-state-tree?

Or more specifically isn't there a away to do the same thing without mobx-state-tree? Looking at the example you linked above to me hasParent() and getParent() look evil. Why isn't parent just a property instead of magically inferred from outside? Also selection looks like it's better if it's a @computed property based on any box that has isSelected property equal true.

Moreover referenceTo or resolve use some sort of string-based identifier. This all looks very odd to me. It's kind of query language like xpath. Is it an official thing? Otherwise why introduce a new one?

As you mentioned - using getters and setters is enough to do resolving logic. It is also as custom as a person like. Why not stop there?

Wouldn't it be better if mobx-state-tree just takes care of getSnapshot and applySnapshot by requiring the developer to create stores that implement a specific interface?