New container ottype

[Blake Thomson]

I’d like to contribute an idea for a container ottype that delegates all of the work on designated keys to other ottypes. Something along the lines of factory for creating a type to house rich-text, text, simple scalar values, or any other data type. I’d appreciate feedback on this idea and details below.

The main export of this new library would be a function that accepts a mapping of keys to type names, and returns an ottype object that delegates the internals of create(), apply(), transform(), and compose() to the specified child types, e.g.

BlogPost = makeType({ title: 'text', body: 'rich-text' })

I’m thinking that a snapshot of this type would be an object with only the keys known to the type, with values corresponding to the child type’s snapshot format, e.g.

{
  title: 'my versioned blog post title', // text
  body: { ops: [{ insert: 'my versioned blog post body' }] } // rich-text
}

And similarly, an op of this type would be an object with only the keys known to the type, with values corresponding to the child type’s op format, e.g.

{
  title: [3, { d: 10 }, 'changed'], // s/versioned/changed/
  body: { ops: [{ retain: 3 }, { retain: 3, { attributes: { bold: true } }] } // bold 'versioned'
}

With these definitions, I think there are straight forward implementations of create(), apply(), transform(), and compose().

As you can see from my examples, my use case if for versioning all the various fields of a blog post in a unified way, storing the composite snapshot values in my database as JSON. (I’m not using ShareJS, but a home-grown solution using ottypes).

Do you think this is a good idea?

There is a rabbit hole to fall down here, where a JSON ottype could be implemented using this scheme. All that would be required is separate types to delegate handling of JSON arrays and scalar values. If you wanted an open-ended data type, you could specify a default sub-type for added keys along with some convention for deleting keys.

I think having separate ottype implementations for  vectors, sets, and maps (JSON arrays and objects) sounds compelling, rather than having all of it wrapped up in the JSON ottype. Is this worth exploring?

I'm just starting to write some of these ideas down in code, but wanted to check with the group to validate some of my ideas before I got too deep.

Thanks for any and all input!

[Devon Govett]

The json0 type actually already supports subtypes, where you can register another OT type as a handler for certain operations, which seems very similar to what you’re proposing. I just merged some documentation about it (sorry it wasn’t there before): see https://github.com/ottypes/json0#subtype-operations.  The string operations (si and sd) are actually already implemented as subtypes internally using the text0 type, and we’ve been using subtypes with a custom richtext type in production at Storify for several months now.

I agree, it could be interesting to separate even more of the JSON type out as standalone types (e.g. an array type, a map type, etc.), but I also know that Joseph has been working on a totally new redesigned JSON type with some improved performance characteristics as well, so I’d wait and see what that brings before jumping too far into the deep end with this.

Devon

--
You received this message because you are subscribed to the Google Groups "ShareJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sharejs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.