cvdl-ts: Add proper structural typing

Currently, a DocumentDataType is a fixed set of choices. Below is the definition from DataSchema.ts

export type Date = { tag: "Date"; format: DateFormat.t };
export type URL = { tag: "Url" };
export type PureString = { tag: "String" };
export type MarkdownString = { tag: "MarkdownString" };
export type PureNumber = { tag: "Number" };
export type Type = { tag: "Type"; value: string };
export type List = { tag: "List"; value: DocumentDataType.t };
export type Types = { tag: "Types"; value: DocumentDataType.t[] };

export type t =
  | Date
  | PureString
  | MarkdownString
  | URL
  | PureNumber
  | Type
  | List
  | Types;

These types are used in conjunction with ItemContent, where each Item will have a datatype specified by its data schema

export type PureString = {
    tag: "String";
    value: string;
};

export type None = {
    tag: "None";
};

export type List = {
    tag: "List";
    value: PureString[];
}

export type Url = {
    tag: "Url";
    value: {
        url: string;
        text: string;
    };
};

export type t = PureString | None | List | Url;

This scheme is obviously very flawed and limited. A better option would be to NOT hardcode these types and design a new system that merges types and their editors, by most possibly using small set of primitives and some mechanisms to define discriminated unions to model sums and products.

There are three main things we need to have for a given type.

An editor to create and edit inhabitants of the type.
A template to render the inhabitants of the type.
A validation function(perhaps regex?) on some representation of the type.

We also need a few base types, so that we can compose the others based on them.

Text[R]: This is some arbitrary string validated with the Regex R. We should probably just make everything markdown by default, the current separation is not very useful.
List<T>: The current version of this only uses PureStrings, but that's an artificial limitation. Assuming that the editor for type T is a component, construction a generic List component should be easy. Of course it's not very easy to make it look nice for complex types, so that's a job for another day.
Rec { t1: T1, t2: T2... tn: Tn }: This allows us to compose larger types without hard coding them. URL is just Rec { text: Text, url: Text[URL] } where URL part might is be validated with a URL regex. Date is just Rec { day: Text[dd], month[dd]: Text, year: Text[dddd] } although we should probably have a special case for dates because of the default HTML date pickers.
Union { V1 T1 | V2 T2... Vn Tn }: A union is what currently Types represent, even though we don't really use it. It's analogous to a tagged union, where Vi is the tag and Ti is the corresponding type. We can use Unions to model a closed set of choices(for example, language fluency might have the type Union { Native Rec{} | Beginner Rec{} | } where we might even delete the empty record and run Union { Native | Beginner } in short.

GIven some type here, it's possible to construct an editor from scratch with a few small rules.

The editor for Text[R] is a textbox with validation and perhaps autocomplete with some limitations.
The editor for Rec { t1: T1, t2: T2...} is exactly the same as the editor for an item.
The editor for List<T> is the next step of today's version. It gives you a set of T editors.
The editor for Union { V1 T1 | V2 T2...} is a selection where the values are V1, V2 and a selection of Vi renders the editor for Ti.

There are lots of nice things about this model. The first is that it kills the concept of a data schema. A data schema is now just a data type in a document. This also means that Layout Schemas are now just visual representations of data types, meaning I might finally use this as a building block to a more general format.

alpaylan / tail

cvdl-ts: Add proper structural typing #22