[RFC] UI Based Config Builder

[jacobsfletch]

Notice

If you don't read anything else in this RFC, please read this:

This does not replace or change the code-first nature of Payload in any way, and never will. This is entirely optional and is not either/or. You need to opt-in to use this feature. If you’d rather stay code-first as-is, there is nothing you have to do.

Background

Payload is code-first by design. This is a core tenet of Payload and something that will never change. Many users, ourselves included, came to Payload specifically because of this fact.

However, we also recognize the need for a more visual approach to generating Payload configs, especially for non-developers, or those who prefer (or even require) an interface.

The UI-based config won't be AS powerful as code, but you can use it to get started quickly, iterate on different admin UX, etc.

How it might work

First of all, this would be entirely optional and behind a feature flag. You can still write your config in code as you always have, and you choose what portions of your config to expose to the UI to be managed visually.

If you use this feature, you are not forfeiting the code-first nature of Payload in any way.

But if you do want to use it, we’re thinking that you’d turn it on in the config like this:

export default buildConfig({
  // ...
  uiBuilder: true,
})

Deduplicating the Config

To support a combination of UI-based config and config-in-code, changes to the config on either end must be merged and reconciled to ensure that they are consistent and valid. Payload will be responsible for doing this in the background, so that both the code and UI-defined config are always in sync.

Within Payload’s init method, if this flag is turned on, we’d look at the database to see if there is a UI-based config defined. If there is, we’ll load it up as JSON from the database and use it as a starting point just like how a plugin modifies the base config.

Then we’ll merge in the code-based config, preferring any definitions in code which will override anything duplicative from the UI-based config definitions. We will likely deep-merge these two sources of config, so things like fields / etc. can be augmented in UI even if they are defined in code.

Access Control

Of course given how powerful the Payload config is, there must be limitations around what you can and cannot do through the UI alone. There are many ways that changing a Payload config could completely break a server, for example.

To prevent these kinds of breaking changes, Payload will provide sensible defaults and guardrails which can be overridden to any degree.

We’ll add an access.uiBuilder property to the config which you can use to lock down the config builder to only work in development mode, be accessible by users with certain roles, or similar. It would function similarly to the access.admin method that already exists within Payload.

What this looks like

What this ultimately looks like is still to be determined. It could be that the config builder is an entirely new "edit-like" view. Or maybe we render a canvas-like interface. Or, last but not least, maybe field schemas are configured inline alongside the existing UI for a more seamless experience.

Regardless, any config definitions defined in UI (collections, globals, etc.) will be able to be exported as TS that you can copy / paste into your project.

You should be able to easily toggle collections or globals on and off in UI, so that if you want to use the schema builder to create your collection, you’d do so, but then once you’re happy with the iteration, you’d export to TS, put it in source control, and then disable the collection in the UI builder.

In this way, it’s more like a “content modeling prototyper” where you can use it to quickly riff on admin UI without having to write out the schema, bounce over to admin UI to see what it looks like, and then bounce back to the schema.

Open questions

• Would you use this? If so, what for? If not, we get it. But still tell us why.
• Would you prefer to build up a collection or global from a pseudo-edit view? Would you want to build it on a “canvas”-like UI? Or, something completely different?
• How smart can we get when it comes to de-duping UI-based config with code-based config?
• Should we build some type of “logic builder” for access control, so that you can express access control rules in UI rather than just in code, or should we just keep access control restricted to code only?

We value your input and take it very seriously. If you have something to add, please be part of the conversation!

[janus-reith]

It would be great if the UI builder could work outside of payload as well to allow for some lightweight playgrounds.
Not just specifically the Visual UI Builder itself, but the field type logic that comes with it.

Loosely related, but I built a backend-less Component Playground recently that allows to define block schemas in the browser and preview rendered blocks with that output. For that I had to rebuild that logic, which however was less effort than expected. Still would be great if an actual core package could be reused for that.

First panel: enter the definition of a block, with Typescript definitions and corresponding suggestions and error correction.
Second panel top right: Fields are then automatically generated with the rendering logic as in the Payload Admin Panel
Third pane the bottom left: Enter the React code for a component that uses this block.
Fourth panel bottom right: a preview of the actual block appears, with the values entered at the top panel

playground.mp4

Not sure how well this could be generalized, as it implies an oppinionated pattern of how blocks should be rendered.

But It could be huge to build something like a public payload block registry that way, where you can preview blocks and 1 click import them into your project. (There's other barrieres to that but it seems most people landed on common things like shadncn/tailwind anyways )

A visual schema builder would blend great with that.

[janus-reith]

Then we’ll merge in the code-based config, preferring any definitions in code which will override anything duplicative from the UI-based config definitions. We will likely deep-merge these two sources of config, so things like fields / etc. can be augmented in UI even if they are defined in code.

Love how much thought is put into these details!

[janus-reith]

preferring any definitions in code which will override anything duplicative from the UI-based config definitions.

Thinking about this outside development mode, wouldn't the expectation be reversed there?

[janus-reith]

We’ll add an access.uiBuilder property to the config which you can use to lock down the config builder to only work in development mode, be accessible by users with certain roles, or similar. It would function similarly to the access.admin method that already exists within Payload.

So there is the idea to make this work outside of development? I wonder how reliable that could work and align with migration logic. It would probably pair well with the blocksJSON mode for blocks, but for other relational data it seems complex to get right.

[sealan]

Would you use this? If so, what for? If not, we get it. But still tell us why.

Yes! Providing low code / no code experiences for customers who want to extend a core data model defined in code. I'd also love if this feature could support UI driven block configs, too.

Would you prefer to build up a collection or global from a pseudo-edit view? Would you want to build it on a “canvas”-like UI? Or, something completely different?

I think both options are nice. We're using pseudo-edit views in our implementation. Feels a lot like Directus.

And we also allow users to upload schema files that mirror the Payload config for a collection / blocks, but then parse it and store it in the DB to drive it.

How smart can we get when it comes to de-duping UI-based config with code-based config?

• We wrapped Sanity-style fallbacks around schema drift: when a field definition disappears or changes type, we render the payload with an “Unknown field/block” wrapper, expose the raw JSON for rescue, and flag it until the user fixes or deletes it.
• In our multi-tenant use case, we would never want UI-based config to make their way back into code (as each tenant is extending the data model in their own way)

Should we build some type of “logic builder” for access control, so that you can express access control rules in UI rather than just in code, or should we just keep access control restricted to code only?

This might be awesome. Especially, if you can get it working in a performant manner (i.e. not hitting the DB like crazy to figure out DB driven access rules). Potential attack vector, ofc.

[philipgher]

Very interesting angle.
I want to circle back to the use case and problem this is solving - having designer (or other non-devs) have control/input over data modelling, correct?
This is really a workflow topic. A potential timesaver for teams. A way to reduce back and forths and misalignments. In my mind - this feature makes sense when working off of designs. A workflow pain point has always been to transform static designs into page building blocks. Taking relatively static designs to a dynamic system. Deciding what flexibility and variations this block and that component has is a big part of the back and forth between design and dev.
With that in mind it'd make sense to couple this config builder to Figma components and its variations/variables. Streamlining this part of the design -> dev handover would be a huge win.

[janus-reith]

Should we build some type of “logic builder” for access control, so that you can express access control rules in UI rather than just in code, or should we just keep access control restricted to code only?

The default permission model seems too flexible to cover this properly. But an (optional) opinionated layer on top of it for RBAC could cover a wide range of use cases in general and work well for a visual builder. RBAC could be a small-scoped and flexible abstraction that can use your custom named collections for roles, and work wether you directly assign roles to users, or assign roles to groups and groups to users, or whatever custom logic, as long as you let it know where and how it needs to check a against b.

Such a plugin-rbac could be just a few LOC with some overridable defaults that’s sets good enough boundaries to make it easily available in a visual builder.

But a fully-featured flexible visual builder for dynamic access patterns seems hard to get right, and if I have demand for such granular permission control I would probably not want to rely on a visual builder for it anyways.

[janus-reith]

In the visual builder, what would probably be enough:

• Can be read/updated by roles x,y
  OR
• Owner (here aswell, would be very flexible to dynamically select a field that should be compared against the current user id, but probably more helpful if that rbac plugin could just set a default createdBy field if not overridden otherwise)

[saskia-compono]

Love the idea of a UI Based Config Builder!! It would allow product / design people to create a prototype, save a lot of back and forth time. The developers can then tweak the configuration further in code to ensure it's optimal from a design perspective

We spent a lot of time evaluating Directus CMS and really liked how they did this, including configuring the CSS to brand the Payload application