Replies: 1 comment
-
A small optimization could be using an immutable // Update: no need for an empty insert object, should just be an empty array
// const EMPTY_CONTENTS = [{ insert: '' }];
const EMPTY_CONTENTS = [];
const EMPTY_LINE = { contents: EMPTY_CONTENTS };
// Delta2
[
{ contents: [{ insert: 'My Document' }], attributes: { header: 1 }},
{ contents: [{ insert: 'A paragraph.' }]},
EMPTY_LINE,
{ contents: EMPTY_CONTENTS, attributes: { header: 2 }}
] We could even go further and make each line format and certain boolean markups become immutable constants. // Update: no need for an empty insert object, should just be an empty array
// const EMPTY_CONTENTS = [{ insert: '' }];
const EMPTY_CONTENTS = [];
const EMPTY_LINE = { contents: EMPTY_CONTENTS };
const HEADER1 = { header: 1 };
const HEADER2 = { header: 2 };
const BOLD = { bold: true };
// Delta2
[
{ contents: [{ insert: 'My Document' }], attributes: HEADER1 },
{ contents: [{ insert: 'A paragraph.' }]},
EMPTY_LINE,
{ contents: EMPTY_CONTENTS, attributes: HEADER2 }
{ contents: [{ insert: 'This is bolded text', attributes: BOLD }]}
] |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This ticket is to track ideas around optimizing the Delta format for large documents and mobile performance.
The Delta format optimizes the contents to be as concise as possible. We can keep Delta as an external format but there may be efficiency gained using a modification of Delta.
Delta2 would map each entry to a line. This would allow a changes to replace only lines that are affected and leave the rest to be persisted to the new Delta2. Here is what the difference between Delta and Delta2 internal format would look like:
When text is added to the 3rd paragraph (the 4th line), a new Delta2 would be created to represent the new state, the first 3 lines would be added by reference from the old delta2 and the 4th line would be replaced with the updated data.
While the original Delta format may be able to be optimized to keep entries that haven't changed, it will be more efficient to break each line out as a separate object. This limits the amount of data that gets replaced, especially when there is a change for documents that contain mostly paragraphs. It is also in a format more easily manipulated by the editor which iterates on lines much of the time and ends up splitting up the Delta format by line often for these iterations. In addition, certain operations will be simplified, such as line format operations which can update an object without splitting any text up, and cross-line delete operations which currently must copy the first line's attributes to the last line's position because Delta stores line info at the end instead of the beginning of a line. And finally, the view can be optimized by limiting comparison to lines that have been updated using the equality operator. If lines are computed they will be new objects and never strictly equal.
To sum up the benefits:
The 2 Delta formats will be compatible with one another, allowing for saving one format to the server while using the other during runtime. However, we could remove the original Delta format from Typewriter and create separate module that can transpose between the two to keep the Typewriter smaller.
Beta Was this translation helpful? Give feedback.
All reactions