Future Directions for Payload CMS — What’s Next?

[gunwixor]

Overview:

As Payload CMS continues to grow and evolve, it's important to reflect on the future direction of the platform. This issue aims to spark a discussion on potential new features, improvements, and areas for expansion that could benefit both developers and content creators.

Key Areas for Consideration:

Enhanced Customizability:

How can Payload improve its flexibility for developers?
Should we consider introducing more out-of-the-box options for templates, custom fields, or integrations?
Community-driven Features:

How can the community have a more direct role in influencing the roadmap?
Could we explore community-driven plugin ecosystems or allow more extensions?
Performance Optimizations:

As content management grows, so do performance concerns. Are there specific areas where we can improve the speed and scalability of Payload, particularly for large projects?
Future-proofing Integrations:

With headless CMS becoming a central part of modern stacks, how can Payload stay ahead of trends in API-first and headless architectures?
Could we focus more on seamless integrations with emerging frameworks and platforms?
User Experience (UX) Enhancements:

Payload CMS is already developer-centric, but what about the non-technical users? Are there UX improvements that can make it more approachable without losing its power for developers?
Call to Action:

Let’s gather ideas from both the community and core team to shape the roadmap. If you have suggestions, concerns, or ideas, please add your thoughts here.

[RafalFilipek]

Hey,

@gunwixor This is great, thank you for initiating this!

Here's the first batch of thoughts :)

1. DiscriminatedField: I often encounter situations where a UI element needs to perform different actions, for example:

   type Action = { type: "LINK", /* some fields */ } | { type: "MODAL", /* some fields */ }

   Currently, I'm using admin.conditions for this, but it requires additional mapping to match the elegant typings I have in my application. Assuming the discriminator can only be based on static values, I'm thinking of something like this:

   {
     type: 'discriminated',
     name: 'action',
     field: 'type', // name of the field in generated interface
     as: 'radio' | 'select' // how to pick type
     mapping: {
      'LINK': [Field[]],
      'MODAL': [Field[]],
     }
   }

2. I can't understand why optional fields are typed as field?: string | null | undefined. I've tried various things, but it seems that's just how it is. An option to disable the null typing would drastically improve the DX from a typing perspective, where (at least in my case) null is used very rarely and always intentionally. Perhaps a nullable option for fields with a global fallback in payload.config.ts?

3. @/payload-config is a nice convention, and I understand why it's used, but it requires special workarounds when the project is developed in a monorepo and has a global task that checks the correctness of typings. Maybe there's an option to use relative paths.

4. When a collection/block has many levels due to the use of groups/rows, it would be nice to be able to assign them a level. With each nesting, the size of the header could be smaller.

5. breakpoints could accept height: 100% :)

6. From the UI panel perspective, a primitive-array field type would be useful. Currently, when we have a type defined as an array, it's very verbose.

   {
     type: "simple-array",
     name: "bullets",
     element: "string" | "number" | "date"
   }

   Such a field would only have a name and a list of text fields to fill in.

7. With headless CMS becoming a central part of modern stacks, how can Payload stay ahead of trends in API-first and headless architectures?

   I'm 100% sure that @payloadcms/sdk and the built-in option to generate OpenAPI specifications for all endpoints will change a lot.