-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Gutenberg lifecycle clarity and grammar #13574
Conversation
Simplified sentence structure, semantics of the closing paragraph. Also made redundant content relevant to the overall aims of the passage.
@@ -143,4 +143,4 @@ A purely dynamic block that is to be server rendered before display could look l | |||
|
|||
## The Gutenberg Lifecycle | |||
|
|||
In summary, the workflow for editing a Gutenberg post starts with taking the persisted version of the document and generating the in-memory tree, aided by the presence of token delimiters. It ends with the reverse: serialization of blocks into `post_content`. During editing, all manipulations happen within the block tree. In summary, a Gutenberg post is built upon an in-memory data structure which gets persisted somehow in an fully-isomorphic way. Right now that persistence is via a serialization/parser pair but could just as easily be replaced through a plugin to store the data structure as a JSON blob somewhere else. | |||
In summary, the workflow for editing a Gutenberg post starts with using token delimeters to generate an in-memory tree from the persisted version of the document. The process ends by reversing the serialization of blocks into the `post_content`. During editing, all manipulations happen within the block tree. Alternatively, a Gutenberg post is built and manipulated using an isomorphically persistied, in-memory data structure. Although Gutenberg post persistence is currently achieved using a serialization/parser pair, in hypothetical scenarios the post data structure could also be stored using a plugin or retreived from a remote JSON file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The process ends by reversing the serialization of blocks
The phrasing here seems to imply that a serialization is reversed, which doesn't really make sense. The previous phrasing was more to emphasize the inverse of the initial parse, i.e. completing the cycle of "Markup -> (Parse) -> Blocks -> (Serialize) -> Markup".
My two cents both versions are fairly dense and difficult to read, here is a potential rewrite for simplicity
|
I applied changes proposed by @mkaz - is it good to go now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me ;-)
* Update Gutenberg lifecycle clarity and grammar Simplified sentence structure, semantics of the closing paragraph. Also made redundant content relevant to the overall aims of the passage. * Update key-concepts.md
* Update Gutenberg lifecycle clarity and grammar Simplified sentence structure, semantics of the closing paragraph. Also made redundant content relevant to the overall aims of the passage. * Update key-concepts.md
Description
Simplified sentence structure, semantics of the closing paragraph. Also made redundant content relevant to the overall aims of the passage.