Abstract relationships.

[cowboyd]

See #357 for full details.

How to contextualize a child microstate has been a constant challenge. In other words, sometimes you want a child to take on a constant value. Sometimes you want it to take on a default value, and sometime you might want it to be completly polymorphic on what value it takes on depending on the parent.

Unfortunately, this is not possible with our current way of expressing relationships with is either with a DSL:

class Counter {
  count = Number;
}

or with an explicitly created microstate:

class Counter {
  count = create(Number, 1);
}

The problem is that there is no way to expand the concept of what gets created if you want to do something fancier, like copy values down the graph without resorting to intializer hacks.

This introduces a very thin concept of a relationship between a parent microstate and a child microstate. The responsibility of the traversal is to take the value at the location of the target microstate and return a specifier for the child microstate.

To do this, we introduce the concept of a "Cell" which is a Type, value pair { Type, value }. This is the minimal about of information required to specify a microstate. This is super light-weight because it does not require the overhead of actually create-ing a microstate.

It is the responsibility of a relationship to resolve a value into a cell.

Note: in future microstates, we will use { Type, path } as a cell
specifier.

The relationship class is organized monadically so that it can be mapped, flatMapped, etc... and any relationship can be extended using map and flatMap

For example, to implement a hypothetical child helper which creates a specifies a substate of a given type and default value, it could look like this.

function child(Type, defaultValue) {
  return relationship()
    .map(({ value }) => value != null ? {Type, value} : {Type, value: defaultValue })
}

This pull request does not introduce any actual changes built on the relationship function, but just exposes it so that we can experiment with it.

[coveralls]

Coverage decreased (-0.1%) to 98.74% when pulling aabfdf3 on cl/abstract-relationships into bd8529c on master.

[cowboyd]

One thing I was thinking was that instead of using (value, parent) => Cell as the arguments, we could use an object so that we can make it rich with metadata.

class Edge {
  get targetValue() {
    return view(At(this.name), this.parentValue);
  }

  get parentValue() {
    return valueOf(this.parent);
  }
   constructor(parent, key) {
     this.parent = parent;
     this.name = name;
   }
}

And then the relationship traversal would receive an Edge object:

type Traversal = (edge: Edge) => Cell

[taras]

We should release this as a beta and test out in all of the use cases that we have.

[cowboyd]

Here is a branch using an edge argument to the traversal function, rather than passing (value, parent) separately. This lets you have ready access to handy things like the location's value as well as its parentValue https://github.com/microstates/microstates.js/blob/cl/abstract-relationships-using-edges/src/relationship.js#L40-L58

[taras]

Edge looks like the way to go because it gives us a richer object to use in the future. Should I create a beta release from edge?

[cowboyd]

@taras This PR now uses the Edge object as the object to resolve relationships, and also exports the relationship() function, and should be good to go w.r.t beta.

[taras]

Here is a TypeScript definition for relationships https://gist.github.com/cowboyd/5fd38eb194fc362457909d9dd762f15e

[github-actions]

This PR is available to use:

npm install [email protected]

You can view the NPM package here.

Generated by 🚫 dangerJS against aabfdf3