Possible to add standard fields / blocks inline in editor?

[ssyberg]

Similar to the Statamic bard? https://statamic.dev/fieldtypes/bard?ref=docs.statamic.com

[jmikrut]

Hey @ssyberg — we actually have a few different ways that you can do this!

Statamic's approach is basically a glorified "rich text". This can be good in certain simple scenarios and Payload's Rich Text Editor can do the exact same thing. However, Statamic's is built with ProseMirror and outputs HTML, while Payload's is built with SlateJS and outputs structured data as JSON.

Payload's richText field type allows for you to create any custom SlateJS element or leaf you can dream up. See the Building Custom Elements and Leaves section of the docs for more info.

We plan on releasing guides that detail specifically how to build your own elements and leaves, but for now, you can look at our demo folder for a few examples.

SlateJS also has a little set of examples which range from simple to complex. Specifically, the Editable Voids example might be relevant to you.

What's great is that any work you put into building your own Payload rich text elements and leaves is really just learning SlateJS - Payload's abstractions are very minimal... meaning you won't have to waste any time learning how to do things the Payload way.

If you have any questions, bring them on!

[ssyberg]

Totally get this, and the SlateJS extensibility is pretty sweet as is the json output! I think one of the main goals of bard/this idea would be to not have to replicate the work of defining a block / "fieldset" in one place in Payload and then also create a custom element/component for SlateJS that represents the same structure (and all the normal pitfalls of not being DRY would apply). Perhaps there's an easy way to import a block/fieldset in to a react component for use in Slate with minimal additional code that keeps the implementation relatively DRY, but I'm pretty new to react so don't have my head wrapped around that yet.

[jmikrut]

@ssyberg 100%.

This topic is intensely interesting to me and it's a super important one to get right.

What you're describing is so hugely useful and it's basically at the core of where we want Payload to go in 2022.

There are a few important distinctions I want to make and they all revolve around when to use a rich text editor, and when to use Payload's blocks field type.

I think what you're saying aligns with making Payload's blocks field type more powerful and designed more aligned with how WP's Gutenberg editor works. It's what our Roadmap item Extensible / Reusable Blocks UI refers to.

Imagine this:

What if the design of "blocks" were simplified, and one block to pick from was simply a rich text field, which had UI similar to Medium or to WP's Gutenberg. Then from there, you could build your own blocks, which within, you'd rely on Payload fields similarly to how Payload blocks work now. But, you could provide custom UI for each block. So you could easily reuse Payload fields, being super DRY, but still be able to craft your own UI (and even reuse newly purpose-built UI widgets like drag to reorder, remove, add, etc.) Then you'd be using Payload's "fieldsets" while maintaining a totally open-ended and consistent UI.

Now.... this all means that we actually envision the blocks field type to be more inline with how to do this the right way, while the rich text field type is more of a "text editor".

Does this make sense? What do you think?

[ssyberg]

I think so! I just need to mull this over a bit more. FWIW I'm not a huge fan of the edit in place / Gutenberg style editors and we're specifically looking for solutions where we're very prescriptive / explicit about blocks or content sections that the content editor has lots of control over (and we want to keep this to a minimum). The edit-in-place/Gutenbergs out there tend to be too flexible in our opinion and tend to lead to a breakdown of the designs. It's a fine balance and very few CMS solutions have pulled this off. But I digress...

One of the nicest features of the Statamic Bard - and really the impetus around suggesting this be a rich text editor feature and not just blocks is the ability to easily move these "inline blocks" around within the surrounding text (and other in line blocks). Currently if I have a text block followed by an image block followed by a text block and I want to move the image up one paragraph, I have to copy the paragraph from one text block to the other (and this is the paradigm in all the block sections of every CMS that supports blocks with the exception of the Statamic Bard). This is a trivial example, but hopefully the implication is a little more clear / how powerful this would make the RTE.

[jmikrut]

I totally know what you mean about the "overly-flexible" factor.

Regarding the "inline-blocks" note, I see the point there too. That would certainly be a compelling case for building this functionality into the RTE. It's actually possible right now to reuse some of the base Payload fields, even within custom RTE elements and leaves, and we're actively working toward exposing more fields. Take a look at this discussion for more info there. Even right now, you can build your own rich text elements while keeping DRY and reusing internal Payload fields.

That said, I still think that the better solution here would be to build with blocks, and design the UX of the blocks according to your application. Consider if hitting return would close you out of a "paragraph" block, and open you up into another "paragraph" block immediately. In that way, you'd still be able to move images around between paragraphs and have it still function as a block-based editor. Would that solve the issue?

I think Payload will ultimately be flexible enough to support both.

Another reason why blocks may be the more powerful approach in the longer term is because blocks allow you to use true relationship fields and auto-populate related documents, with control over population "depth". For example, you might want to reference a Location doc and have that location auto-populate a map on your frontend. Data-structure wise, you don't want to "copy" that location's data into your RTE but you might want to have it auto-populate inline when you retrieve the data via REST or GraphQL.

Payload's RTE already supports dynamic relationships to other documents, but the difference is that the rich text relationship and upload element types are built in vs. specified by the developer and unknown by Payload. Allowing developers to specify their own dynamic sub-fields in rich text elements could be possible but at that point the DX might get a bit hairy.

Auto-populating relationships is a factor to consider, but there's also all the other stuff Payload does like localization, access control, etc etc.

Anyway, I'm rambling but this is a great discussion. I'm going to mention it on our open Blocks roadmap item. Please do keep this feedback and this type of thinking coming. We are going to do our best to shape Payload's trajectory to be as useful and relevant to our users as possible and no doubt this thread is going to be helping in that.