Updating a Frontastic component schema

As you know, a Frontastic component schema basically defines what input options are available for a Frontastic component in the Frontastic studio. Once it's uploaded, you can make changes to the existing schema by uploading a new version of the schema but it has to have the same Frontastic component name.

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.

To make sure it's Backwards Compatible, you need to make sure that all the configurations you currently have in place for your Frontastic 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 Frontastic component. You upload that schema to the Frontastic 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.

We do have a way that you can test the new version of your schema before adding it to the Frontastic studio, this article shows you how.

If you want to completely rework a Frontastic component schema, you can, but the only option would be to copy the JSON of the current schema and rename it (by adding 'version 2', for example). This then gives you the freedom to create an entirely different Frontastic component in its place. You'll need to keep in mind that for this Frontastic component to be updated on your site, your team will have to go through all pages where the old version of the Frontastic 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 Frontastic component to the new one (or the opposite, so the new one to the old one). This means that you're migrating your Frontastic 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 Frontastic component schemas referring to the same code in your project.

Let's look at an example:
Say that you have an existing Frontastic component where a single image can be selected in the Frontastic studio. Now you want to update this and make it so that multiple images can be selected. You can add a new version of that Frontastic 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 Frontastic 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.

We've also put together some best practices for creating Frontastic component schema below:

When you first create a Frontastic component schema, only make configurable what really needs to be configured in the Frontastic studio. In some cases, it means that nothing will be configurable. For example, the checkout Frontastic component is only placed on the page, and the code takes care of the rest. It's only when your team needs something to be configurable should you add it into your schema.

If you ever add any new configurations to an existing Frontastic component, they must be optional and set to a default that will result in the old behavior (for example, false in the example above).

Copy the schema of your latest and most simple Frontastic component or a similar Frontastic component to what you want to create as a starting point for your new schema. Test it to make sure it works, and then tweak it to how you want it. That way, you don't have to rewrite a lot of code, you keep the same format and conventions, and you know how it'll behave.

Keep as much business logic outside of the Frontastic component itself and put that into the patterns or explicit logic components. Use the Frontastic component as a data layer to feed the components. It might even be a good idea to translate the data structure coming from Frontastic into your own semantic data structure to increase the re-use of your components.

When deciding how to slice up a Frontastic component, it's sometimes best to make one big block in the first instance and then refactor only if you need to make smaller parts configurable. Think about how it will be used and how it makes sense from a user point of view. If it makes sense from the get-go to make 2 (or more) smaller Frontastic component, then make it like that. But if you're not sure how to split it up, make 1 big one. It'll save you set up time, and you won't have to think about so many possibilities to account for in your code. You can always cut it down in the future. You can even use our grid system within a Frontastic component, which will then make it easier when refactoring and will make it all look the same even if you're using 1 big Frontastic component versus 4 small Frontastic component.

In general, take each Frontastic component on a case-by-case basis. In some cases, some of these best practices won't work for the individual Frontastic component you're creating as it's unique and how you handle it is unique.