Representing array of models in the state tree

[antitoxic]

So, I looked into this project after zalmoxisus/mobx-remotedev#1 (comment)

Before I can comment there, I'm wondering how should the developer represent array of models with mobx-state-tree?

Currently I have something like store.featuredProducts which is an observable array. How does the resolution (resolve(this, '/users', this._author)) works? Why do I need this and identifier? Does it work only for resolving single objects? Can it batch resolve? Anyway, can you give an example how would that happen, so I visualize this best?

Another negative for me is the '/users' identifier. Using identifiers feels a step back for me. I would prefer if there is a instance of a ModelManager then can retrieve it by class/object like:

import {Author} from `authorfile`;

manager.get(Author, id);

[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?