Skip to content
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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Feb 8, 2019
Merged

Update Gutenberg lifecycle clarity and grammar #13574

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d5c49b9
Update Gutenberg lifecycle clarity and grammar
Jan 29, 2019
6f8ebbe
Update key-concepts.md
gziolo Feb 5, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion docs/designers-developers/key-concepts.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.