Feb 13, 2024
The introduction of Edge Delivery Services into AEMaaCS has brought the ability to create document-based websites that can leverage "blocks" to customize such websites. However, problems arise when we quickly assume that blocks are equal to components of AEM sites and try to use blocks as if they are AEM components. While there are similarities, we’ll highlight some of the key principles of blocks and explain how they differ from components before building our own.
What are Blocks?
A "block" is a chunk of styles and functionality (CSS and JS) applied to a specific portion of the DOM. Authors create blocks in their documents, and developers then write the corresponding code that styles the blocks with CSS and/or decorates the DOM to transform the markup of a block into the structure that is needed or convenient for the desired styling and functionality.
Blocks vs Components
Here are some of the differences between these 2 concepts:
| Blocks | AEM Components |
|---|---|
| Cannot be nested. | Allow nested components. |
| Blocks are loaded as JS Modules. | JS and CSS are loaded through clientlibs. |
| "Block options" help to add extra information and are set within brackets. These options will then become a class that can be used as an identifier to differentiate behavior. | Components utilize dialogs to set configurations and additional information that the component can utilize. |
| The Auto-Blocking mechanism helps reduce the author's burden. | Components define all their behavior explicitly as part of their functionality. |
| Metadata and section data can be accessed and shared across various blocks. | Page properties can be accessed and shared across various components. |
Best Practices for Writing Your Blocks
-
Author First: Create content structures that are intuitive and easy for authors to work with.
-
Work with Sections and Default Content: Utilize sections and default content to enhance organization.
-
Rely on the Auto-Block Mechanism: Emphasize content creation over structural concerns by leveraging the Auto-Block mechanism.
-
Introduce Blocks Selectively: Only introduce blocks when there is a specific semantic and meaningful purpose for the website.
Provide Abstract Functionality: Ensure blocks offer enough abstract functionality and are general enough for reuse without changing the underlying content model.
-
Ensure Responsiveness: Make blocks responsive to work seamlessly across all breakpoints.
-
Context-Aware Design: Inherit CSS contexts, such as text and background colors.
-
Performance Considerations: Ensure new blocks introduced do not negatively impact performance.
-
SEO-Friendly: Optimize blocks for search engine visibility.
-
Accessibility Compatibility: Make blocks compatible with accessibility standards.
-
Proximity to Desired Result: Design blocks to be close to the desired visual outcome.
-
Utilize Metadata and Fragments: Simplify block configurations and data information by leveraging metadata and fragments.
Wrapping Up
Distinguishing blocks from AEM components is crucial, and avoiding the misconception that they are interchangeable is essential. Although similarities exist, blocks function as distinct entities, representing chunks of styles and functionality applied to specific DOM sections. This necessitates collaborative efforts between authors and developers for a successful implementation. By adhering to these best practices, developers can fully unlock the potential of blocks within Edge Delivery Services.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.