chore(version): updated the @aemforms/af packages#176
Conversation
| import sanitizeHTML from 'sanitize-html'; | ||
| import { FieldViewState } from './type'; | ||
|
|
||
| /** Legacy rich-text enum option shape; af-core 0.22.175+ types enumNames as string[] only. */ |
There was a problem hiding this comment.
The changes in this file are not required, as the EnumName was already missing in the af-core bundle and is not related to the latest version of it.
There was a problem hiding this comment.
EnumName was a real export from af-core, not a typo — it was defined in types/Json.d.ts at 0.22.65 (the version resolved when this import was originally added in #125):
export declare type EnumName = {
value: string;
richText?: boolean;
};re-exported via types/index.d.ts → lib/index.d.ts. It was dropped from af-core's exports between 0.22.76 and 0.22.77 — well before this PR's bump to 0.22.176 — so the break was latent in the ^0.22.76 range regardless of this version bump. I've removed the comment that implied 0.22.175+ caused it and kept a local EnumNameItem type with the same shape as the original export.
There was a problem hiding this comment.
Please move all these enum changes into PR: 175, and keep this PR limited to a version bump.
There was a problem hiding this comment.
This is the PR that removed the enum name from the af-core: https://github.com/adobe-aem-forms/af2-web-runtime/pull/509
Approving the PR as this change was merged long ago.
…ted EnumName workaround af-formatters was never imported in the example app; it's already pulled in transitively via af-core/af-react-renderer. The EnumName type comment incorrectly attributed a pre-existing af-core typing gap to this version bump. Co-Authored-By: Claude Sonnet 5 <[email protected]>
| const displayName = typeof item === 'object' ? item.value : item; | ||
| const localizeEnumId = getOrElse(state, ['properties', 'afs:translationIds', 'enumNames']); | ||
| const localizeEnumName = localizeEnumId ? i18n.formatMessage({ id: `localizeEnumId##${index}`, defaultMessage: EnumName }) : EnumName; | ||
| const localizeEnumName = localizeEnumId ? i18n.formatMessage({ id: `localizeEnumId##${index}`, defaultMessage: displayName }) : displayName; |
There was a problem hiding this comment.
here how is escaped string being localized? Run this once manually and test.
af-core 0.22.176+ always emits enumNames as plain strings (HTML included
inline, e.g. "<b>Item 1</b>"), dropping the old {value, richText} object
shape. getLocalizeEnumNames now returns the localized string as-is instead
of forcing it through richTextString, since that helper returns JSX and
some consumers (DropDown's <option>, Switch's aria-label) can only accept
plain strings. CheckBoxGroup and RadioButtonGroup render their option
labels via richTextString so HTML enum names still display as rich text
where the markup allows it.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Fixtures previously used the retired {value, richText} object shape for
enumNames, which no longer matches what af-core produces. Converted
DropDown/CheckBoxGroup/RadioButtonGroup fixtures to plain strings, dropped
the now-redundant duplicate string-fixture tests and the rich-text-object
tests that asserted a shape that can no longer occur, and added a test per
component confirming HTML in enumNames still renders as rich text.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
rendering of checkbox group having rich text options in react vanilla components |
Covers rendering CheckBoxGroup under a non-default locale (fr-FR) to confirm enumNames display correctly regardless of the active IntlProvider locale, alongside the existing rich-text and translation-id coverage. Co-Authored-By: Claude Sonnet 5 <[email protected]>
3 participants
Description
Updated the npm packages version as handling for datetime component is missing in older version of @aemforms/af-core
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: