Hero - refactor for static front end

[jkcox]

Current Architecture

• save.js — outputs a <div> with data-* attributes (no visible HTML)
• frontend.js — parses those data-* attributes and renders the <Hero> This means the hero is invisible until JavaScript loads and executes.

How to Refactor for Static HTML

You'd render the Hero component's HTML directly in save.js instead of serializing data attributes.

1. Import the Hero component HTML into save.js
2. Remove frontend.js (or make it optional)
   Since the HTML is now static, you no longer need client-side hydration. Remove the "viewScript" entry from block.json
3. Add a deprecation entry in index.js
   Since existing saved content uses the old data-* format, you need a deprecated array so WordPress can still parse old posts

Key Considerations

Concern | Solution

• Styled-components — the Hero uses HeroImage (a styled ) Replace with a plain tag and add CSS to your block's stylesheet (style.css or editor.css)
• Existing posts break The deprecated array migrates old markup automatically on re-save
• No interactivity needed Static HTML is ideal here since the Hero is purely presentational
• CSS classes Ensure the UDS theme's CSS uds-hero highlight classes is enqueued on the frontend
• Can't import the Hero component directly in save.js WordPress save functions must produce deterministic HTML — you can't use components that rely on runtime logic, styled-components, or side effects. You must inline the markup as shown above

Why you can't just import { Hero } in save.js

WordPress's save function runs at serialization time (not render time). It must produce pure, deterministic HTML with no side effects. The Hero component uses styled-components which generates dynamic class names at runtime — this would cause block validation failures. You need to replicate the HTML structure directly.

AB#44610