Refactor API Surface

[blakeembrey]

Three types of methods:

• formatter (for serialising data)
• parser (for deserialising data)
• validate (for validating native representations)

Serialising and deserialising can be completely synchronous, they would be based on structural type checking (none of the validation logic needs to occur). The tricky part here is picking which branch to use during serialisation/deserialisation (E.g. for union types). Maybe the structural checks can throw errors and pick the first branch that doesn't error? Also, sort union types by assignability (E.g. "a is a subset of b, but b is not a subset of a").

It'd be nice to remove the classes, but I think they'll just get more prominent as I add complexity (E.g. sort union types, proper intersection types). Could make it so the classes don't hold anything and move logic outside. E.g.

import { types, compile } from 'jaywalk'

const schema = {
  type: 'string',
  properties: {
    username: {
      type: 'string'
    }
  }
}

const validate = compile(types, schema)

Vs

import { Types, compile } from 'jaywalk'

const schema = new Types.Object({
  properties: {
    username: new Types.String()
  }
})

const validate = compile(schema)

[blakeembrey]

Classes need to extend and implement:

_isType (value: any): boolean // Synchronous type checking.
_compile (): Function // Compile an asynchronous function from the current type.
_intersect (type: Any): Any // Intersect one type with another, returning the intersected type.
_visit (fn: Function): void // Walk a type according to the schema.

[blakeembrey]

Closing in favour of granular issues.