Building and Managing Components
Component building is the heart of the exam. A component is a reusable UI unit made of a tree of elements. Each element maps to an HTML tag (div, section, heading, image, link) and can hold child elements. On top of elements you attach styles - CSS declarations exposed to the builder as controls. Styles can be static (fixed values) or dynamic (editable fields the content author fills in).
Expect questions on component forms and fields. When you make a style dynamic, you define a field (text, select, color, image, link, etc.) that appears in the component's edit form. Slots let a component accept dropped child components, enabling nesting. Component variants let one component offer multiple visual versions. Props/attributes pass data into components.
Traps to watch:
- Confusing a dynamic style (author-editable) with a static style (locked by the builder).
- Forgetting that editing a component's structure can break existing pages that use it.
- Assuming nested components automatically inherit parent styles - they do not unless styles cascade or are explicitly applied.
- Mixing up component duplication (safe copy) with editing in place (affects all instances).
Worked example
A card component needs a heading, body text, and a background color the author picks. Build elements: a container div, an h3, and a paragraph. Add a static style for padding, then a dynamic background color style bound to a color field. The author now sees a color picker; the padding stays fixed. Rule of thumb: anything the content author should control → dynamic field; anything that enforces the design system → static style.