Updating a Frontend component schema

As you know, a Frontend component schema basically defines what input options are available for a Frontend component in the studio. Once it's created, you can make changes to the existing schema by editing it in the schema editor.

We currently don't have in place a check to make sure an updated schema is Backwards Compatible so for now you'll need to check that yourself.

Keeping backward compatibility

To make sure it's Backwards Compatible, you need to make sure that all the configurations you currently have in place for your Frontend component (the defaults are the same and it basically behaves like before) are kept and that any new ones are optional.

Let's say you have a menu Frontend component. You edit that schema in the studio with the essential things for a menu item: having a title and a link to which page folder they're going to. You now want to add a configuration that can highlight a menu item. So, when you update the schema, it must still contain the title and link but it would now have the highlight as optional, so it would default to false. This will ensure it's Backward Compatible and behaves like it did before but now with the option of adding a highlight to it.

Updating schema by refactoring

If you want to completely rework a Frontend component schema, you can, but the only option would be to copy the current schema (you can use the copy JSON icon in the schema editor) and create a new one but with a different name (add 'version 2', for example). This then gives you the freedom to create an entirely different Frontend component in its place. You'll need to keep in mind that for this Frontend component to be updated on your site, your team will have to go through all pages where the old version of the Frontend component is used and replace it with the new version. To minimize this update, you could reuse the React components that were used to render the old version of the Frontend component to the new one (or the opposite, so the new one to the old one). This means that you're migrating your Frontend component code to a new behavior but you're translating how the old schema looked on a code basis to a new visualization as it's possible to have 2 Frontend component schemas referring to the same code in your project.

Example scenario

Say that you have an existing Frontend component where a single image can be selected in the studio. Now you want to update this and make it so that multiple images can be selected. You can create a new version of that Frontend component, and in the code, you can translate the single image into a list of images. Then you can use the new code for the old version too, and it ensures that the old Frontend component will work if it happens to be used on an old page that still needs to be browsable for SEO. Then you can make it Backwards Compatible on your own code and then you don't need to maintain all this old code anymore.

See the schema article for best practices when creating a schema.