As you know, a Tastic schema basically defines what input options are available for a Tastic in the Frontastic Editor. 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 Tastic 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 Tastic (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 Tastic. You upload that schema to the Frontastic Editor with the essential things for a menu item: having a title and a link to which node they're going to. You now want to add a configuration that allows a Frontend Manager to 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 uploading it to the Frontastic Editor, this article shows you how.
If you want to completely rework a Tastic schema, you can but the only option would be to copy the current schema and rename it (by adding 'version 2', for example). This then gives you the freedom to create an entirely different Tastic in its place. You'll need to keep in mind that for this Tastic to be updated on your site, your Frontend Manager will have to go through all pages where the old version of the Tastic 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 Tastic to the new one (or the opposite, so the new one to the old one). This means that you're migrating your Tastic 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 two Tastic Schemas referring to the same code in Catwalk.
Let's look at an example:
Say that you have an existing Tastic where a Frontend Manager can select a single image. Now you want to update this and make it so that multiple images can be selected. You can upload a new version of that Tastic 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 Tastic 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 Tastic schema below:
When you first create a Tastic schema only make configurable what really needs to be configured by the frontend manager. In some cases, it means that nothing will be configurable. For example, the checkout Tastic is only placed on the page and the code takes care of the rest. It's only when your Frontend Manager needs something to be configurable should you add it into your Schema.
If you ever add any new configurations to an existing Tastic, 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 Tastic or a similar Tastic 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 Tastic itself and put that into the patterns or explicit logic components. Use the Tastic 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 Tastic, 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 two (or more) smaller Tastics, then make it like that. But if you're not sure how to split it up, make one 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 Tastic, which will then make it easier when refactoring and will make it all look the same even if you're using 1 big Tastic versus 4 small Tastics.
In general, take each Tastic on a case by case basis. In some cases, some of these best practices won't work for the individual Tastic you're creating as it's unique and how you handle it is unique.
Updated 2 months ago