Skip to content

Fix targeted-block docs: row labels and stale code example#946

Open
sirugh wants to merge 2 commits into
releasefrom
fix/targeted-block-row-labels
Open

Fix targeted-block docs: row labels and stale code example#946
sirugh wants to merge 2 commits into
releasefrom
fix/targeted-block-row-labels

Conversation

@sirugh

@sirugh sirugh commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Summary

  • The Personalization setup doc's targeted-block example tables and reference list used segments, groups, and cartRules as row labels. readBlockConfig() normalizes row labels via toClassName(), which lowercases and replaces non-alphanumeric characters with -. A single camelCase word like cartRules has no non-alphanumeric character to replace, so it normalizes to cartrules, not cart-rules. blocks/targeted-block/targeted-block.js destructures customer-segments, customer-groups, and cart-rules from the config — none of which matched the documented labels, so following the doc as written means the block's targeting conditions are silently never read. Updated row labels to Customer Segments, Customer Groups, and Cart Rules, which normalize correctly.
  • The TargetedBlock container docs' decorate() code example had the same root cause: it destructured segments/groups/cartRules straight off blockConfig and passed them directly into personalizationData, skipping the prepareIds() step the real block uses to split each comma-separated value and base64-encode (btoa) every ID. Updated the example to match aem-boilerplate-commerce/blocks/targeted-block/targeted-block.js.

Test plan

  • Confirm Customer Segments / Customer Groups / Cart Rules normalize to customer-segments / customer-groups / cart-rules via toClassName() in aem-boilerplate-commerce/scripts/aem.js
  • Spot check the updated tables/list render correctly in a local Starlight preview
  • Confirm the updated decorate() example matches current aem-boilerplate-commerce/blocks/targeted-block/targeted-block.js

sirugh added 2 commits July 7, 2026 15:22
The example tables and reference list used `segments`, `groups`, and
`cartRules` as row labels. readBlockConfig() normalizes row labels via
toClassName(), which only replaces non-alphanumeric characters, so single
camelCase words don't get a dash inserted: `cartRules` becomes `cartrules`,
not `cart-rules`. The block's decorate() function destructures
`customer-segments`, `customer-groups`, and `cart-rules`, so none of the
documented labels matched — following the doc as written meant the block
silently never activated.

Row labels are now `Customer Segments`, `Customer Groups`, and `Cart Rules`
(space-separated, consistent with how other multi-word settings are
documented elsewhere in this repo, e.g. section-metadata's `Column Width`),
which normalize to the keys the code actually reads.
Same root cause as the previous commit: this code example destructured
segments/groups/cartRules straight off blockConfig and passed them directly
into personalizationData. The actual block in aem-boilerplate-commerce reads
'customer-segments'/'customer-groups'/'cart-rules' (matching the row labels
authors type in da.live) and runs each value through prepareIds(), which
splits the comma-separated list and base64-encodes each ID with btoa()
before handing it to the TargetedBlock container. The example was missing
that step entirely, so copying it verbatim would pass raw, un-encoded IDs
into personalizationData.
@sirugh sirugh changed the title Fix targeted-block row labels to match block code Fix targeted-block docs: row labels and stale code example Jul 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant