From d0439106ec362ff4520e7fd918099cab00c01365 Mon Sep 17 00:00:00 2001 From: Raymond Johnson Date: Fri, 8 Feb 2019 06:43:02 -0500 Subject: [PATCH] Update Gutenberg lifecycle clarity and grammar (#13574) * 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 --- 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 3252337ba2b33..e42f5aa044ba1 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 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 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.