JSON format

[arvsharm]

We are using Draft JS for our product in production. I wanted to confirm the following

1. Does Draft JS publish a JSON schema as a public spec or is it strictly a private format?
2. What are the chances that schema could change in coming versions and if that happens what will be the migration plan for the JSON already stored in DB.
3. What will be the frequency of change in schema?

Thanks
Arvind

[dimitar-nikovski]

Hi @arvsharm ,

I assume that by JSON schema you refer to the EditorState in 'raw' format? In which case the blocks and entityMap and the entity's mutability, data, type, block styling type and inline style, etc. have been around for a long time and that's essentially the schema.

I am a little confused, because you have mentioned that you are already using it in production? There isn't a private format, the EditorState is as per documentation and @types/draft-js. I haven't come across any talks of changing the above structure. A migration seems out of scope of the project, even if the same data has to be stored in a radically different structure, then migrating would be done by writing a conversion function and then executing against all pre-existing DB stored RawDraftContentState, obviously how is up programming language and kind of DB.

[arvsharm]

Yes EditorState in raw format is what we are storing in database. My question was regarding this only.
It looks like there is no plan to change this format as of now.
If a change happens we have to write our own conversion function and draftjs will not provide the same right?

[claudiopro]

Hi @arvsharm that's a brilliant question, and the docs partially answer it:

Because a text editor doesn't exist in a vacuum and it's important to save contents for storage or transmission, you will want to be able to convert a ContentState into raw JS, and vice versa. To that end, we provide a couple of utility functions that allow you to perform these conversions.

There was an effort underway, currently on hold (see #143 and #388) to represent the data structure as a tree instead of a flat list of content blocks. Keeping backwards compatibility with raw data created with the flat block map would be a design goal, but we'd surely provide conversion utilities if the underlying raw tree data structure weren't backwards compatible.