Builder best practices
Business needs are unique and call for unique solutions. This article shows you how to think about the best ways to use Builder for your site.
Deciding what goes in Builder
As a general guideline, parts of your site that non-developers manage are well-suited for residing in Builder. Parts that are complex with a lot of code might be ideal for keeping in your codebase.
Using custom components in your Builder content can help you take advantage of both approaches. You can build reusable components to your specifications, keep them in your codebase, but register them with Builder so that your teammates can drag and drop them as they iterate.
Structuring your site
One of the easiest ways to get started is to add landing page building to your site. Once you have that, you can start adding editable sections across your site, and use targeting to choose the right content for the right users.
Here are some examples we recommend for how to structure various pages on your site:
In addition to being able to define Builder-editable areas of your site, you can also use components from your code in Builder controlled content areas (pages and sections). This is great for extending Builder with advanced functionality, keeping intricate areas controlled in your codebase, etc., while still leaving flexibility for your editors.
Additionally, you can use symbols to create design systems and separate concerns between designers making pre styled blocks used by editors. Symbols can also keep the same content in sync across multiple pages, managed and edited in one place, with no coding required.
You can use roles and permissions to decide who in your organization is able to edit designs, content, code, etc.
To offer even more flexibility for testing, targeting, and optimizing content, you can also put full pages in Builder with "smart" components in them - e.g. components that are aware of the page they are on (e.g. via context, URL, etc) and render the current product info, images, form, buy button, etc.
This can allow even more rich testing and optimizing without requiring custom development for every layout change, while still encapsulating complex components (like product forms, etc) in code.
Below are two example on how you can do this, for instance, on a product detail page.