To help make development as fast and consistent as possible, we want to focus on creating components that are reusable and that can be combined to make bigger things.
The Design team are using Atomic Design principles to create designs that cater for this usability.
In the front end, we should follow this same pattern. But, in order to simplify naming rather than include the “atom”, “molecule” differentiation in our naming, we will simply call most things “components”.
Can be atoms or molecules from the design system and could be small or large. They are reusable elements which have been made as small as is useful. These means they may have different variations (for example a primary or secondary buttons). They should not include external layout or positioning (like padding or margins) to allow them to be better reused. is not.
Modules are made out of components, and reflect how the view files have been built in Sitecore (although there isn’t a direct one-to-one relationship). Modules should ideally only contain positional code (position, margin, grid, flex and padding). If additional styles are needed we should aim for these be created as mixins in the appropriate component file.
Modules cannot be combined to make larger components - they should be used to create page layouts.
The difference between a component and a module isn’t super important, but the expectation is that modules will represent something that is useful to, or areusable component within Sitecore. Whereas a component will be a small piece of code that is useful to and reusable for the front end team, but unlikely to be available individually within Sitecore.
An example of this, is that in the front end we will want to have a button component, but this is unlikely to be be a Sitecore module that can be moved around to create a page. We can use this component to create things like the “Fixture list item” module that will have a direct reference within Sitecore.
Behaviors are pieces of reusable JavaScript code that add interaction, or other behaviour to components or modules. They shouldn’t have any inherent appearance (only styles necessary to the behaviour), so they are not shown in the components library navigation.