Frontastic components are the most important interaction point between developers and business users. Their schema defines how business users will be able to use your components. In the best case, you'll discuss the components upfront with a Product Manager based on the expected usage during later project stages. But as this often isn't the case and the business users are only involved in later project stages, we want to provide you with some ideas and guidance on how to slice a commerce site into components.
There are 3 important questions to answer to understand the trade-offs:
- What do business users want to change on a commerce site?
- How flexible should the components be for business users?
- How can you build resilient components?
All are quite hard to answer and should be a team decision (or at least feedback from a Product Manager). This article will give you some tips as to how you could go about finding the answers.
So, let's look at an example. Below is a Figma file for the design of a simple commerce site homepage:
By looking at the design, we can already see where things could be broken up. There's the header, a hero image with copy and a button, 3 tiles with buttons, a product slider with a heading, a newsletter sign-up, some additional information, and the footer. Like this:
So now we know what we can break it into, what should be configurable within the Frontastic studio? Well, that's totally up to your team. Let's look at some options.
The Header (also known as top-level navigation) is often one of the most complex components you'll develop in your commerce site (see the Navigation and menus article for more information). The user interaction patterns are usually complex and the required configuration options are as well. On top of this, the behavior across different devices can also be really complex, so a developer should probably have control over this and limit the configuration options.
For the Call To Action banner (also known as CTA banner), the slicing is kind of obvious by looking at the design. We can see it's full-page width on all devices, there's clear spacing around it, and the configuration options should include an image, heading text, subheading text, and button text. You could even add some additional options to the configuration, like color theme or alignment. But remember, you can always add additional options later to a component like this.
You can have a look at our Tile starter component to give you some ideas.
For Teasers, there's a couple of options.
Firstly, you could have a single component that could allow for any number of teasers to be added, each consisting of an image and a button. Frontastic components allow for groups within it so this is a good option.
The other option is to have a single teaser but instead of it being full-width, you can use layout elements to split the page into 3 and put a teaser into each, and then configure it as needed. The grid will behave properly across different devices by itself, so you don't have to take care of the responsive layout of this component. This will also allow business users to combine those teaser elements, for example, with a newsletter subscription in 1 layout element. This will give business users more flexibility, but it might be a lot harder to make the components resilient enough to look good even when used in very different grids.
For the Product slider, there's also a couple of options.
You could have 1 Frontastic component that has the configuration options for a title and a subtitle, along with products. But you could also have 1 Frontastic component with just the product slider that contains the actual products (and so no configuration options) and then use a separate generic Markdown component to allow for the title and subtitle. This gives the business user a lot more flexibility when it comes to text placement, but this can also mess up the layout. Spacings are often a problem here, because unifying spacing gets more complex the smaller your components are. We've seen some customers introducing extra spacing components so that business users can work on these issues. But the trade-offs really depend on the flexibility your business users want to have so that there is no clear answer for this Frontastic component.
You can have a look at our Product slider starter component to give you some ideas.
The Newsletter could have no configuration options, and it can all be set in code. But if you'd rather not have to change your code for copy updates, then you could have 5 configurable options, the heading, subheading, placeholder email copy, button copy, and GDPR copy.
You can have a look at our Newsletter starter component to give you some ideas.
With the Additional information blocks, similarly to the teasers, you could split them into 3 separate components, each as full-width, and then have the options for copy and icon. But again, this could cause spacing and layout issues. So it would probably be easier to use a configuration group for this, with an icon and text.
You can have a look at our Feature service starter component to give you some ideas.
The Footer can contain many different parts, some configurable and some not. Plus, you may show different parts of your footer on mobile and desktop. Here, there's a copyright, and 3 different policies. It may be best to put the policies in as markdown fields so they can be updated as needed.
When it comes to flexibility in general, you can create a native HTML component that allows a business user to enter any blob of HTML and render this. As a developer, you'll know that your site will probably break as soon as you do this if business users aren't used to writing HTML.
Regarding configuration options, the trade-offs mightn't always be as obvious. For example, should you allow business users to specify exact color values or could this mean that it doesn't follow brand guidelines or the corporate identity of your commerce site. A selection between "primary" and "secondary" might make more sense, while the exact color values are read from your theme configuration.
Many developers are tempted to create too many configuration options "because they can" and to save themselves work in the future. But are they really necessary? Try to create configuration options for things that have been requested to be configured. If you find in the future that another configuration option is needed, it's easier to add it in than remove ones that are an issue. Plus, testing frontend components with hundreds of potential variants can be quite challenging. Start with the minimum (maybe even no) configuration options, and see how it's being used before making it available.
When it comes to splitting a commerce site into components, it can seem like a daunting task, especially when trying to account for all the different options for business users. Try to think about what a business user would need or want to configure. But always put resilience over too many configurations or what should be adapted.
Updated over 1 year ago