mobx-decorated-models

Decorators for creating model type structures with mobx

mobx-decorated-models is a collection of es7 decorators to make a class observable and serializable.

Introduction

Mobx makes state management super simple, but it doesn't offer an opinion on how to get data in and out of the observed data structures.

Serializr takes care of that nicely.

Combining the two libraries isn’t difficult, but then you end up specifing each attribute twice; once so Mobx will observe it, and once to create a schema for Serializr.

This library is a collection of decorators that co-ordinates making fields both observable and serializable.

While it’s at it, it also handles model lookups so different models can refer to one another regardless of import order. When one model refers to another, a reference of the requirement is stored and then later resolved when the class becomes known.

Example

import { model, field, session, belongsTo, hasMany, identifier } from 'mobx-decorated-models';

@identifiedBy('box')
export class Box {
    @identifier id;
    @field width  = 0;
    @field height = 0;
    @field depth  = 0;

    @computed get volume() {
        return this.width * this.height * this.depth;
    }

    @hasMany items;
    @belongsTo container;
    @belongsTo({ model: 'address' }) warehouse;
}

additional examples used for testing are located in specs/test-models.js

boxes = @observable.array([])
fetch('/my/api/endpoints/boxes/1.json').then(function(response) {
  boxes.concat(Box.deserialize(response.json()));
});

const box = Box.deserialize({ id: 1, width: 2, height: 3, depth: 8 }); // returns an instance of Box
console.log(box.volume);      // => 48
console.log(box.serialize()); // => { id: 1, width: 2, height: 3, depth: 8, items: [] }

Controlling model lookups

The class @identifiedBy accepts a unique string that should be used as a lookup key so that hasMany and belongsTo relationships can be established.

This allows things like the below mappings to still work even though the two files can't easily include each other:

// chair.js

import { identifiedBy, belongsTo } from 'mobx-decorated-models';

@identifiedBy('chair')
class Chair {
    belongsTo 'table'
}


// table.js
import { identifiedBy, hasMany } from 'mobx-decorated-models';

@identifiedBy('table')
class Table {
    hasMany({ model: 'chair' }) 'seats'
}

Collections

The same logic that is used for belongsTo can also build a stand-alone collection. Collections built this way are instances of mobx observable.array with an interceptor that converts assigment into model creation.

A collecton can be created like so:

import { createCollection } from 'mobx-decorated-models';

class Foo {
    constructor(attrs) { Object.assign(this, attrs); }
    myName() { return this.name; }
}

const collection = createCollection({ model: Foo });
collection.push({ name: 'bar' });
collection[0].myName(); // will return "bar", since it's coerced into an instance of Foo

Note that the "model" objects a collection is set to do not have to be decorated by the @identifiedBy decorator if they're given directly as shown in the exmple above. However if they were, then the identifier could be given to 'model' instead of the class.

Decorators

identifiedBy('identifier')

Marks a class as serializable.

It adds a few convenience methods to classes:

• static deserialize method. Used to turn JSON structure into a model (or collection of models)
• a read-only static identifiedBy value that matches the string provided to the decorator
• an update method. Updates a model's attributes and child associations.
• serialize. Converts the model's attributes and it's associations to JSON.

It’s primary purpose is to remember classes for hasMany/belongsTo lookups. This allows the associations to refer to models without having to load them. Often models will refer to one another, making it difficult for each of them obtain a direct reference.

identifier

The primary key for the model

field

marks a class property as observable and serializable.

The type of field can be set to array or object, or date by specifying options. For other types, a model option can also be given

example: @identifiedBy('bar') class Bar { static serialize(bar) { return bar ? 'BAR' : null; } }

@identifiedBy('foo')
class Foo {
  @field({ type: 'object' }) options; // will default to an observable map
  @field({ type: 'array'  }) tags;    // defaults to []
  @field({ type: 'date'   }) occured; // no default value is set
  @field({ model: 'bar'   }) bar;
}

const foo = new Foo();
foo.update({ occured: '2013-10-21T13:28:06.419Z', bar: '123' }); // bar doesn't actually store anything
console.log(foo.occured); // Mon Oct 21 2013 08:28:06 GMT-0500 (CDT), provided you're in CDT :)
foo.tags.push('one');
foo.options.set('one', 1);
foo.serialize(); // => { tags: ['one'], options: { one: 1 }, occured: '2013-10-21T13:28:06.419Z', bar: 'BAR' }

session

Session fields are useful for storing data that should not be persisted.

They're write-only, meaning they're updated by the deserialize static method and update() instance method, but are not included in the JSON generated by serialize()

example:

@identifiedBy('user')
class User {
    @field id;
    @session isLoggedIn;
}

const user = new User();
user.update({ id: 1234, isLoggedIn: true });
user.serialize(); // => { id: 1234 }; // note the "isLoggedIn" property is ommited

belongsTo

Makes a property as referring to another model. Will map to the referenced class based on it's identifiedBy and the property name, i.e. a property named box will look for a class identified by box.

Optionally can be given an option object with a model property to control the mapping.

model can be either a string which matches a value given to the identifiedBy decorator, or a reference to the model itself.

example:

@identifiedBy('person')
class Person({
    @identifier id;
    @field name;
    // finds a model that was set to use the id `pants` by it's decorator
    @belongsTo({ model: 'pants', inverseOf: 'owner' }) outfit;
    speak(msg) {
        console.log(`${this.name} says: ${msg}`);
    }
})

@identifiedBy('pants')
class Pants {
  @session color;
  @belongsTo({ model: Person }) owner; // no lookup, will just use the class `Person`
}

Can be given a inverseOf which will set auto set this property to it's parent when it's deserialized.

For instance the Pants model above will have it's owner property set to the "Ralph" Person model:

Person.deserialize({
    id: 1, name: 'Ralph', outfit: { color: 'RED' }
})

An interceptor is installed that will convert bare objects to a model. In the example below, the owner will be set to an instance of Person

const pants = new Pants();
pants.owner = { id: 1, name: 'Jimmy' };

pants.owner.speak("Hello World!"); // Jimmy says: Hello World

Note: When using inverseOf, the auto-set property is not serialized in order to prevent circular references.

hasMany

Marks a property as belonging to an mobx observable array of models.

Sets the default value to an empty observable array

As in belongsTo, can be optionally given an option object with a model property to control the mapping.

hasMany also accepts inverseOf and defaults properties. If an inverseOf is provided, when a model is added to the array, it will have the property named by inverseOf to the parent model

If defaults are provided the new model's attributes will be defaulted to them. defaults may also be a function, which will be called and it's return values used.

Like belongsTo, hasMany also converts object assignment to a model

@identifiedBy('tire')
class Tire {
    @session numberInSet;
    @belongsTo vehicle; // will be autoset by the `inverseOf: auto` on Car
}

@identifiedBy('car')
class Car {
    @belongsTo home;
    @session color;
    @hasMany({ model: 'Tire', inverseOf: 'vehicle', defaults: {numberInSet: 4} }) tires;
}

@identifiedBy('garage')
class Garage {
    @session owner;
    @hasMany({
        model: 'Car',
        inverseOf: 'home',
        defaults(collection, parent) {
            return { color: this.owner.favoriteColor };
        }
    }) cars;
}

Custom serialization

Custom serialize/deserialize behaviour can be implemented by setting the serialize option on a decorator. serialize should be an array of two functions. The first is used to convert from the property to JSON, the second will be used to convert from JSON to the object's property.

const shipCargoSerializer = [
    a => a - 1,
    b => b + 3,
];

@identifiedBy('boat')
export class Ship {
    @identifier name;

    @field({ serializer: shipCargoSerializer }) cargoCount;
}

const boat = Ship.deserialize({ id: 1, cargoCount: 3 });
boat.cargoCount // 6
boat.serialize().cargoCount // 5

Note: The above example does not deal with null/undefined or perform any validation. Real serization methods must deal with unexpected values.

unresolvedAssociations

mobx-decorated-models attempts to do lazy lookups for the model that hasMany and belongsTo should use. In order to do so, it keeps track of associations that are not immediatly resolved in the hope that the model for them will be decorated with @identifiedBy later.

However if the model is never decorated the association will continue to be set to a plain observable.object.

Properties that are not resolved can be listed using the unresolvedAssociations method, which will return an array of object with model and property keys.

Example:

import { model, field, session, belongsTo, hasMany, identifier } from 'mobx-decorated-models';

@identifiedBy('shape')
class Parallelogram {

}

@identifiedBy('box')
class Box {
    hasMany sides;
}

unresolvedAssociations().forEach(({ model, property }) => {
    console.log(`The model for ${model.identifiedBy}(${property}) cannot be found`);
});

// outputs: The model for box(sides) cannot be found