Additionally, it's actually fairly easy to make certain guarantees that MobX provides invalid by complete accident, especially when copying string keys from observable objects into another observable. The answer is to leverage computed or autorun or other reaction-based functions, but this library should abstract over those to the point where the user doesn't need to necessarily worry about committing error-prone code in these specialized cases.

There do exist other solutions in the MobX examples and they are perfectly valid, but they require passing around parent contexts and there isn't an out of the box solution for saying "I have all of these models that I know are related to parents, but I just want these without looping through all of the parents". Consider this example store code loosely lifted from the MobX documentation:

``js
class ToDo {
constructor(store) {
this.store = store;
}
}

class Parent {
@observable todos = []

makeTodo() {
this.todos.push(new ToDo(this));
}
}
`

Full and complete sample here: https://mobx.js.org/best/store.html

This requires only a simple flatmap to achieve the desired output of a list of all ToDos, but more complicated relationships would easily become more cumbersome. For example, take the following code snippet:

`js
class Step {}

class ToDo {
@observable steps = [];

makeStep() {
this.steps.push(new Step(this))
}

constructor(store) {
this.store = store;
}
}

class Parent {
@observable todos = []

makeTodo() {
this.todos.push(new ToDo(this));
}
}
`
The overall approach is still the same (flatMap with a greater depth to get all Steps from all ToDos), but it would be nice to simply query for all of the steps that currently exist in isolation, or all ofthe ToDos that currently exist without having to traverse the parent contexts.


With this project, I hope to separate the concerns of managing a centralized store with an accessible syntax for describing model relationships and model structure. Eventually I also hope to integrate nice-to-have features, such as index only lookups, complex primary key structures, and relationship cascade options.


As of now, the form that the __meta__ attribute takes is this:
`js
__meta__: {
key: IObservableValue;

collectionName: string | symbol | number;
relationships: Record<
string | symbol,
{
type: any;
keys: IObservableArray;
options: Record;
}
>;
indicies: IObservableArray;
};
`


const f = new Foo();
f.friends[0].id // This properly gives us type hints because we've typed it as a Bar[]. We could have also typed it as an IObservableArray
`


`js
class Foo {
@primaryKey
id = uuid();

@observable
someProperty = []
}

// returnValue = { status: 200, data: {id: '1234', someProperty: [1, 2, 3, 4] }}
function apiCallResult(returnValue) {
// Validate
...
// Dump the result into a new instance of the model
const f = Object.assign(new Foo(), returnValue.data);
add(f);
return f;
}

`

@relationship(store, () => Foo, { cascade: true })
leaves: Foo[] = [];
}
const foo = new Foo();
const leaves = [new Foo(), new Foo()];
const otherLeaves = [new Foo(), new Foo()];
addOne(store, foo);
foo.leaves.push(...leaves);
leaves[0].leaves.push(...otherLeaves);
findAll(Foo).length === 5;
removeOne(foo);
findAll(Foo).length === 0;
`

However, this does still have the same limitations as POJOs currently do, so you can't directly shove a JSON structure into the store, there has to be a preprocessing step. However, a nice side effect of this is the ability to gather all Foo objects in a single query without walking the entirety of the tree.