From d5c49b940ab084ff619e7a292e97d8ae180f5a09 Mon Sep 17 00:00:00 2001 From: Raymond Johnson Date: Tue, 29 Jan 2019 15:25:51 -0500 Subject: [PATCH 1/2] 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. --- docs/designers-developers/key-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/designers-developers/key-concepts.md b/docs/designers-developers/key-concepts.md index 3252337ba2b339..aa407304e8d9ac 100644 --- a/docs/designers-developers/key-concepts.md +++ b/docs/designers-developers/key-concepts.md @@ -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. From 6f8ebbe86275ba981759da1750bc06b5ce3d19ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Grzegorz=20=28Greg=29=20Zi=C3=B3=C5=82kowski?= Date: Tue, 5 Feb 2019 17:11:01 +0100 Subject: [PATCH 2/2] Update key-concepts.md --- docs/designers-developers/key-concepts.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/designers-developers/key-concepts.md b/docs/designers-developers/key-concepts.md index aa407304e8d9ac..e42f5aa044ba1a 100644 --- a/docs/designers-developers/key-concepts.md +++ b/docs/designers-developers/key-concepts.md @@ -143,4 +143,6 @@ 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 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. +In summary, the Gutenberg workflow parses the saved document to an in-memory tree of blocks, using token delimiters to help. During editing, all manipulations happen within the block tree. The process ends by serializing the blocks back to the `post_content`. + +The workflow process relies on a serialization/parser pair to persist posts. Hypothetically, the post data structure could be stored using a plugin or retrieved from a remote JSON file to be converted to the block tree.