Render is a little odd.

We should always expect Parsed to either already have our error messages, or to succeed.

Render can't add additional errors.

A text fragment with some styling.

This function does no validation, it only creates a new Description.

`

With this type, we're not quite sure if we're going to be able to render or not.

Scenarios:

• A field value of a record has multiple errors with it.
• It's caught and the error statue is rendered immediately.
• The document can be rendered, but we still have multiple errors to keep track of.

A `Block data` is just a parser that results in `data`.

You'll be building up your Document in terms of the Blocks.

A block starts with | and has a name(already built into the parser)

A value is just a raw parser.

--- Error Propagation

Failure
    -> The document has had a mismatch
    -> This can only be recovered by `oneOf` or `manyOf`
Almost
    -> An `Error` has been "raised".  It's propogated until it's resolved by `onError`
    ->


Success
    -> Well, this is the easy one.


Ids are only available on the element they apply to.


Recovery is done at the level above the errored block.


So, if there is a record with a string that is constrained


If the constraint fails, the record can say "Here's the reset"

Is the first expectation a subset of the second?

NOTE, this returns items in reversed order!

Subtle destinction between this and find.

This will NOT reconstruct the full hierarchy, but return the exact blocks asked for.

This also won't verify that all ids in the document were found, it'll just return the stuff it finds.

In order for block lookups to work and for the block to be renderable, we need to retrieve a block, but keep the general structure.

So, if we have ManyOf [ One,Two ], and our ID matches Two, we need to return ManyOf [Two], not just Two.

Then our rendering function will still work.

mergeWithAttrs