Editor: How Little Blocks Work

The editor focus is progressing at a steady pace, with some of the major elements taking shape, so it’s a good time to provide an update. This is a complicated flow so a diagram helps explain things a bit better: The logic flow for the editor is the following:
? inferring a block representation of the post content (parsing);
? describing the post as an ordered list of blocks (state tree);
? representing the post in the DOM (rendering);
? attaching controls to manipulate the content a.k.a blocks (editing UI).
Generally speaking, in a declarative paradigm, the state of the application is structured in an easy machine readable format so that what is rendered is a reflection of the state of the application, and where manipulations are represented as a unidirectional flow. However, the reality is we don’t start in WordPress with a representation of the state of the post that has such structure—there’s no knowledge of “blocks” because content is stored serialized in a single flat field.
So our first step is to infer the structure we need from implicit cues. This is a crucial step that makes the double loop in the above diagram work. It is handled by the