Plone Frontend experimental packages

The Plone community is working in a set of new "experimental" packages in the context of the headless CMS narrative.

Their main goal is to extract some key features from Volto into their own standalone packages, so integrators can use these features also in other frameworks, builds or environments. This is a longstanding feature request, as the ability to consume and edit Plone content within a modern JavaScript framework has been limited to the use of Volto.

Some of these features are being rethinked and redesigned, since the extraction process often require to make them agnostic so they can work outside the Volto shell, so we will take the chance, if possible, to modernize and improve them as we generalize these features.

These packages will also provide features that Volto does not have right now, like having a generic and agnostic API to access the data layer or having an unified definition of TypeScript typings.

These are the packages that are currently under development:

• @plone/registry
• @plone/client
• @plone/components
• @plone/types
• @plone/contents

I will cover them more in depth in upcoming posts, but for now, let's introduce them a bit.

@plone/registry

The Plone Volto registry is probably the most key, underated, and unnoticed piece of code that lives in Volto. From Volto 18 first alpha, its code was refactored to TypeScript and moved to its own package. Volto 18 already uses it as standalone library.

It provides the ability to store a singleton of centralized configuration settings which can be accessed throughout the application code. It also features the add-on and component registry, and the code that allows the component shadowing feature.

Now, you can use it not only in other React frameworks, but in any JavaScript application. It even opens the door to enable add-on support to these frameworks, using the exact same approach as Volto does.

You can know more about it in NPM or in the Volto repository.

@plone/client

Volto relies heavily in a reliable, predictable, but thick and complex data fetching layer, based on Redux middleware and heavily tied to it. Because of that, the components are tighly coupled to these piece of software and they cannot be used outside Volto without porting this piece as well along with them. This makes reusability very hard, we need to do better.

The React ecosystem has evolved a lot in the data fetching story. React itself has been almost reinvented because of providing a nice developer experience story around and React Server Components were born because of it. We not only needed to evolve, but deliver a better and modern frontend data fetching story into Plone.

@plone/client is built on the top of Tanstack Query. A modern, powerful asynchronous state management for TypeScript/JavaScript, React, Solid, Vue, Svelte and Angular. Since it's agnostic, it's not tied even to any specific platform nor framework.

The package was developed during last year's GSOC and it is already released and ready to use, feedback is welcomed!

@plone/components

If we want to be able to build Plone sites outside Volto, we need a set of basic and structural components that are not tied to Volto's Redux middleware data fetching layer. Along with them, we need the usual CMS bits and pieces: headers, footers, breadcrumbs, login form, etc.

The current Volto components also are built on the top of SemanticUI, an unmantained and deprecated library that it's showing its age already.

Learning from the lessons of the past, they need to be agnostic, not tied to any CSS framework, nor any design system. We decided to move in favor of not only build this package using a headless UI component library, but to adopt also their philosophy.

react-aria-components

@plone/components is based on Adobe's React Aria Components library. It is a library of unstyled components built on top of the React Aria library.

It provides a simpler way to build accessible components with custom styles, while offering the flexibility to drop down to hooks for even more customizability where needed.

This package is under heavy development, and recently in alpha stage of the next major version. Take a look at the StoryBook.

@plone/types

This package is the unified placeholder of the types definitions used across Volto. Having them centralized and have an up to date version of them is very important to achieve consistency and type safety on all the packages that we are working on at the same time. It will also provide a unvaluable reference to all developers while developing the core, or add-ons.

This project is an ongoing effort, but it's already released and in alpha stage.

@plone/contents

What about having the most important and central piece of the CMSUI also in its own package?

Well, this is happening as we speak. Not soon enough, we will have our beloved "folder_contents" or "contents" view in its own package, ready to be used outside Volto.

It will use the other experimental packages to build upon. Potentially, even Plone ClassicUI can benefit from it. We could even have it inside an Electron or Ionic app, and build dedicated desktop and mobile Plone Contents app.

Could you imagine? I can't wait to see what we build with these new breed of packages.