Since our public beta launch in January 2021, we've been hard at work building new features and fixing bugs. It's been quite the beta process and our community is becoming more engaged than ever. Just this past month, our GitHub stars have shot up more than 7x to over 4.3K and are showing no signs of slowing down.

Here are just a few of the significant new features we've released over the last year:

Versions, Drafts, and Autosave
The new ui field
The new point field
Custom admin UI views
Enhanced validation functions
A way to automatically generate TypeScript types based on your data
An ability to programmatically return default values for fields
Plugin infrastructure
Persistent admin user preferences
Rich Text Editor upload and relationship elements
Field descriptions
A way to set the max population depth allowed on a field-by-field basis

We've also fixed hundreds of bugs and have kept our GitHub issues list impressively small given the large amount of features and power that Payload represents. But even in spite of all this growth and new features, we still have a few items left that we want to tackle before releasing 1.0.

A look at what's to come

Effective now, the Payload team's full focus is going to be targeted toward releasing 1.0. As such, here's a little snapshot of what you can expect from the Payload team over the next few months.

UI improvements

One of the items we're working on actively is making refinements to the overall UI of the Payload admin panel. Our vision for the future of Payload's admin UI is multi-faceted:

Payload's strengths revolve around how easy and understandable it is to build on top of as a developer. If you want to customize a field, it should be a straightforward process. If you want to inject a new view into the admin UI, you should be able to do so without getting a Ph. D. in Payload's internal conventions. It's already extremely simple, but we want to keep it that way.

To stick to this vision, we need to make sure that our components are as deliberately designed as possible, and that we're set up for as few breaking changes in the future as we can be. And that means we're working on some simplifications and improvements to the composition of the React admin UI, including how fields "nest" within one another, and how the responsive design of the UI works. Payload's API and field configs will not change, but the aesthetics and the internal React components that compose these "nested" field types will improve significantly.

In addition to the developer experience of actually building on top of Payload's UI, we are going to be focusing on the admin editor experience itself, ensuring that Payload is best-in-class when it comes to usability. We want to ensure that load times are as fast as possible—minimizing transitions and keeping everything snappy. We also want to make sure that the potentially complex hierarchies within nested fields are as clear as possible.

Given the above two facets of our vision for Payload's UI, all of the "nested" field types in Payload are going to be getting some love before 1.0.

With these design improvements, we're aiming for a few goals:

Reduce the horizontal space used by array-based controls
Allow for more controls to be added to array and block fields, like duplication and the ability to collapse array rows
Visually distinguish between group fields and array-based fields
Set ourselves up for a reusable collapsible component, which will be used for a new collapsible field type
Remove the horizontal overflow that occurs currently when fields become too wide for the available space
Prepare to build a pattern for being able to completely replace the UI of a given block, to be able to build a beautiful, seamless, and completely customizable layout building experience
Improve the UX of the rich text editor

Dark mode is slated as an upcoming feature, and may make the cut as well. If dark mode is important to you, upvote it on our roadmap.

Significantly expanded testing

Outside of UX improvements, we're going to completely refactor the way our tests are written and spread through the codebase. We want to significantly expand our E2E test coverage, including expanding on the amount of Cypress tests that we have for the UI and making it easier to write future tests.

We also plan to re-architect the way that our current /demo folder is used. Instead of maintaining a single, massive config for local development, we want to create a system where we can truly follow a test-driven development approach and isolate our dev environment(s) to focus on one task at a time. Each task should have a Payload config, a suite of integration tests, and a suite of Cypress UI tests where applicable.

Testing will be critical to 1.0. Even though our issues list is quite low as it is, we take the claim of being "stable" very seriously. And to do that, we need tests. Lots of them.

You can expect to see progress and a PoC from our team here shortly.

Tabs field

Since our public beta launch, a hotly requested feature has been a "tabs" field type similar to what Advanced Custom Fields offers within WordPress. A tabs field would allow you to deliver your editors with a highly usable and concise admin experience, and would boost the ability for an admin to focus on one task at a time, rather than overload them with a long scrolling list of fields.

Collapsible field

Building off the work that we'll be doing to the array and block fields, we'll be creating a reusable collapsible field that will give you even more control over how to deliver your editors a beautiful admin experience. Collapsible panels will be "smart" in that they will use our User Preferences feature to store the collapsed state of the panels as your users interact with them. So, for example, if an admin logs in and doesn't care to see the fields within a Hero group, they can simply close the collapsible. Then, next time they revisit that document, the collapsed state will be remembered.

More fixes and features

Just yesterday, we released 0.18.0 which delivered a suite of new features and fixes. We've got more on the way and outside of the above, we'll be consistently publishing minor and patch versions to deliver new features and fixes as we progress through the goals identified in this post.

Join our community on Discord

We've recently started a Discord community for the Payload community to interact in realtime. Often, Discord will be the first to hear about announcements like this move to open-source, and it can prove to be a great resource if you need help building with Payload. Click here to join!

Let us know what you think

Stop by GitHub Discussions to request a feature, ask a question, or just join in on the conversation. We'd love to know what you think!