The usual WordPress site is highly brittle. With themes, plugins and other frameworks all working in the same environment, styling and/or functionality clashes are almost inevitable.
Luckily, Shadow DOM solves that problem almost entirely:
An important aspect of web components is encapsulation — being able to keep the markup structure, style, and behavior hidden and separate from other code on the page so that different parts do not clash, and the code can be kept nice and clean. The Shadow DOM API is a key part of this, providing a way to attach a hidden separated DOM to an element. This article covers the basics of using the Shadow DOM.
Since 4.0, all components (besides Notation) are built using Shadow DOM, paving a secure, safe and headache-free way for all future integrations.
When thinking about page builders, one characteristic immediately comes to mind: visuality. Adjusting a setting will trigger a direct response, creating a comprehensive editing experience for the user.
All spx components are 100% reactive to new property values. If a data attribute changes while the element is already rendered on the page, it will automatically adjust to the new settings.
Let's illustrate this with the Slider component. Try changing any of the values and watch how the component adjusts in real time.
The inputs are simply changing the slides-per-view and gap attributes of the Slider component. You could even change the properties on the element itself (via devtools) and it'll update accordingly.
Single source of truth
Spx can be integrated into any workflow using it's JSON files. Inside each of those, you'll find valuable information about the component that comes directly from the development files. This data can be used as a reference to implement the components into page builders or other custom solutions.
Internally, the files are being used in the following areas:
- Generating parts of this documentation
- The component editor
- Oxygen integration