You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had to do a quick refresher before starting #23, and thought it would be productive to quickly summarize my current understanding of the elements in the spec.
Types
The portable text spec indicates that there are only 2 primary types: block and span.
We have inferred a list type (because it's there), but it's not a recognized type as far as I can tell. There is also no listItem type, just a block with listItem specified (which is just one variation of block, right) - we definitely need extra serializers both of these here though.
From the upstream tests we have test 26 which uses the button type and several tests (e.g., 12) which uses the image type. As I understand it these are both custom types. This is extra confusing since the image type especially is so frequently used and is clearly built into sanity's own packages.
Mark definitions
A mark definition is something (anything?) referenced in a span's marks list. IIRC, the npm-package separates between decorator and annotation mark definitions, which I'm not 100% clear on what the difference is, but we've mirrored the structure and now have the following lists
decorator marker definitions
em
strong
code
underline
strike-through
annotation marker definitions
link
comment
Styles
In addition to mark definitions we have styles, which define the outer tags of the block - this makes more sense if you remember that blocks are meant to represent chunks of text, and that the Portable Text spec sort of assumes that this is how you break down your content.
We do not support any custom styles at the moment.
I propose that we change the implementation to talk about type and mark serialization rather than
MarkerDefinition
and "custom serializer".Perhaps we could find a common structure for these, as they all serialize/render into HTML.
That would match the upstream rendering pipelines somewhat more, although in a more OO-manner.
The text was updated successfully, but these errors were encountered: