Replies: 4 comments 1 reply
-
I'm also interested in If more advanced nodes (e.g., checkboxes, radio buttons, complex groups) and node capabilities (e.g., references to own/other nodes) are developed, I think the case for not storing in markdown becomes stronger. |
Beta Was this translation helpful? Give feedback.
-
@osaxma I'm currently beginning to implement a json serializer in my project, and I'm curious if you have your implementation in a public repo I could reference. |
Beta Was this translation helpful? Give feedback.
-
I don't have anything in a public repo but I'll extract some code from a proof of concept that I had before. I believe it should still work -- maybe with some modification. I also believe some parts can be improved because I haven't changed much of it once I got it to work. The following are 5 steps that I took to make a
I hope you and others find this helpful. p.s. sorry if something does not make sense above since I extracted this code and edited manually here. |
Beta Was this translation helpful? Give feedback.
-
I have developed a JSON conversion library called 'super_editor_json' on my own. After seeing everyone's discussion, I feel that my program design is somewhat primitive. Where can I find publicly available source code for JSON conversion? I would like to learn from it. |
Beta Was this translation helpful? Give feedback.
-
This is a general idea that I'd like to discuss and hopefully get some feedback on it. I'm currently experimenting with it in an app.
Motivation
I find Markdown limiting as a mean of storage. For instance, if an app needs to store a BlurHash of an image or metadata about a URL, they cannot be easily embedded in markdown without some clever tricks or using HTML (even then, there could be limitations and it would introduce extra complexity to the parsing process).
Idea
Using pure JSON as a format to store SuperEditor's Document(s). The closest example to such approach would be Contentful's Rich Text:
Example
The following is an experimental JSON format that I've been using to store the document. As one can observe, the JSON structure resembles the structure of SuperEditor's Document. For nodes with AttributedText, each attribution is stored as a key where the value is a list of ranges indicating where that attribution is applied.
Discussion
So far, I haven't seen any drawback of using pure JSON to represent the document instead of Markdown. The only thing is that the document size could be larger, but I found that to be insignificant.
The main advantage is being able to easily store additional information specific to each node or the document as a whole. I also assume such format would facilitate the implementation of a collaborative editing feature (I haven't looked much into this tbh).
Note: I don't have the implementation in a public repo yet, but I simply created extension methods for json-serialization/deserialization for all the nodes, attributed text and up to the document itself (i.e.,
Document.fromJson
andDocument.toJson
).Please let know what do you think about the idea. Any suggestions would help.
WIP -- I wrote this a bit quickly, I'll polish the idea later.
Beta Was this translation helpful? Give feedback.
All reactions