feat: embed display fields in secondary cta dropdown #915
Conversation
|
Warning: Component files have been updated but no migrations have been added. See https://github.com/yext/visual-editor/blob/main/packages/visual-editor/src/components/migrations/README.md for more information. |
WalkthroughThis PR splits EmbeddedFieldStringInput into two exports: EmbeddedFieldStringInputFromEntity (derives options from entity fields) and EmbeddedFieldStringInputFromOptions (accepts an options prop). TranslatableStringField gains an optional getOptions parameter and will render FromOptions when provided. CommandItemWithResolvedValue accepts an optional useOptionValue flag. LocatorResultCard.getDisplayFieldOptions now accepts Sequence Diagram(s)sequenceDiagram
participant User
participant TranslatableStringField
participant EmbeddedFieldStringInputFromOptions
participant EmbeddedFieldStringInputFromEntity
participant FieldSelector
rect rgb(240,248,255)
Note left of TranslatableStringField: Runtime branch based on getOptions presence
end
User->>TranslatableStringField: render
alt getOptions provided
TranslatableStringField->>EmbeddedFieldStringInputFromOptions: render with options list
EmbeddedFieldStringInputFromOptions->>FieldSelector: present options (label/value, useOptionValueSublabel)
FieldSelector-->>User: selectable options shown
else no getOptions
TranslatableStringField->>EmbeddedFieldStringInputFromEntity: render with entity-derived fields
EmbeddedFieldStringInputFromEntity->>FieldSelector: present entity fields
FieldSelector-->>User: selectable entity fields shown
end
User->>FieldSelector: select option
FieldSelector-->>EmbeddedFieldStringInputFromOptions: return chosen value
EmbeddedFieldStringInputFromOptions->>TranslatableStringField: onChange (debounced)
Note right of FieldSelector: CommandItemWithResolvedValue may display option.value when useOptionValue is true
Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
packages/visual-editor/src/editor/index.ts (1)
23-26: Public API split into two embedded-field inputs; consider a temporary alias if consumers still use the old nameExporting
EmbeddedFieldStringInputFromEntityandEmbeddedFieldStringInputFromOptionsis clear, but droppingEmbeddedFieldStringInputcan be a breaking change for existing consumers of@yext/visual-editor. If this package is used externally, consider a deprecating alias:export { EmbeddedFieldStringInputFromEntity, EmbeddedFieldStringInputFromOptions, } from "./EmbeddedFieldStringInput.tsx"; +// Optional: temporary backwards-compatible alias for older callers. +export { + EmbeddedFieldStringInputFromEntity as EmbeddedFieldStringInput, +} from "./EmbeddedFieldStringInput.tsx";packages/visual-editor/src/editor/TranslatableStringField.tsx (2)
17-33: Align JSDoc with the newgetOptionsparameter nameThe doc comment still refers to
@param options, but the function now takesgetOptions?: () => DynamicOption<string>[]. Renaming the JSDoc param togetOptionswill avoid confusion for callers reading the signature.
69-105: HandleDynamicOptionentries with undefinedvaluemore explicitlyIn the
getOptionsbranch you map:options={getOptions?.().map((opt) => ({ label: opt.label, value: opt.value ?? "", }))}If a
DynamicOptionever hasvalue === undefined, this will produce an empty string, so:
- The inserted token becomes
[[ ]]when selected.- With
useOptionValueSublabel={true}, the sublabel will be blank.It would be safer to either filter such options out or choose a more meaningful fallback (e.g. use
opt.labelor throw/log in development) so invalid options don’t silently create unusable embedded tokens.packages/visual-editor/src/components/LocatorResultCard.tsx (1)
516-529: Secondary CTA label/link now useTranslatableStringField; consider updating the prop types accordinglySwitching
secondaryCTA.labelandsecondaryCTA.linkto:label: TranslatableStringField<any>(..., undefined, false, true, () => getDisplayFieldOptions("type.string") ), link: TranslatableStringField<any>(..., undefined, false, true, () => getDisplayFieldOptions("type.string") ),achieves the goal of letting users embed display fields into the CTA label and link. At render time you already pass both through
resolveComponentData, which handles embedded tokens and translatable strings.However,
LocatorResultCardPropsstill types these as plainstring:secondaryCTA: { label: string; link: string; ... };For better type safety and self-documentation, consider updating these to reflect the actual shape (e.g.
TranslatableString | string), and importing theTranslatableStringtype from your shared types module.packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx (1)
64-76: Options-based input anduseOptionValuewiring look good; you can skip value resolution when only showingoption.valueThe new
EmbeddedFieldStringInputFromOptions+useOptionValueSublabelflag, and the correspondinguseOptionValueprop inCommandItemWithResolvedValue, cleanly support both:
- Entity-driven options (preview resolved sample values).
- Display-field/options-driven flows (show the option’s key instead).
Since the sublabel now sometimes uses only
option.value:{(resolvedValue || useOptionValue) && ( <div className="ve-text-xs ..."> {useOptionValue ? option.value : resolvedValue} </div> )}you can avoid unnecessary calls to
resolveComponentDatawhenuseOptionValueis true, e.g.:- React.useEffect(() => { - if (isOpen && resolvedValue === undefined) { + React.useEffect(() => { + if (useOptionValue) { + return; + } + if (isOpen && resolvedValue === undefined) { ... } - }, [isOpen, option.value, streamDocument, resolvedValue]); + }, [isOpen, option.value, streamDocument, resolvedValue, useOptionValue]);This keeps previews for entity-backed options while avoiding extra work for display-field-based ones.
Also applies to: 173-180, 241-244
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
packages/visual-editor/src/components/LocatorResultCard.tsx(2 hunks)packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx(6 hunks)packages/visual-editor/src/editor/TranslatableStringField.tsx(2 hunks)packages/visual-editor/src/editor/YextEntityFieldSelector.tsx(2 hunks)packages/visual-editor/src/editor/index.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-06T14:55:12.395Z
Learnt from: benlife5
Repo: yext/visual-editor PR: 862
File: packages/visual-editor/src/utils/schema/resolveSchema.ts:118-135
Timestamp: 2025-11-06T14:55:12.395Z
Learning: In `packages/visual-editor/src/utils/schema/resolveSchema.ts`, the `OpeningHoursSchema` and `PhotoGallerySchema` functions from `yext/pages-components` contain internal type validation and handle invalid inputs gracefully (returning empty objects or undefined) rather than throwing TypeErrors, so no pre-validation guards are needed before calling them.
Applied to files:
packages/visual-editor/src/editor/YextEntityFieldSelector.tsx
🧬 Code graph analysis (4)
packages/visual-editor/src/editor/TranslatableStringField.tsx (1)
packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx (2)
EmbeddedFieldStringInputFromOptions(64-191)EmbeddedFieldStringInputFromEntity(28-62)
packages/visual-editor/src/editor/YextEntityFieldSelector.tsx (2)
packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx (1)
EmbeddedFieldStringInputFromEntity(28-62)packages/visual-editor/src/editor/index.ts (1)
EmbeddedFieldStringInputFromEntity(24-24)
packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx (2)
packages/visual-editor/src/editor/index.ts (2)
EmbeddedFieldStringInputFromEntity(24-24)EmbeddedFieldStringInputFromOptions(25-25)packages/visual-editor/src/editor/YextEntityFieldSelector.tsx (1)
getFieldsForSelector(396-416)
packages/visual-editor/src/components/LocatorResultCard.tsx (2)
packages/visual-editor/src/editor/DynamicOptionsSelector.tsx (1)
DynamicOption(33-36)packages/visual-editor/src/editor/TranslatableStringField.tsx (1)
TranslatableStringField(25-121)
🔇 Additional comments (3)
packages/visual-editor/src/editor/YextEntityFieldSelector.tsx (1)
46-364: Swap toEmbeddedFieldStringInputFromEntitykeeps behavior consistent while centralizing option logicThe new import and usage in
ConstantValueInputcorrectly forwardvalue,onChange, andfilter, and keepshowFieldSelectorsemantics. This reuses the sharedgetFieldsForSelector-based options logic without changing the constant-value flow for single string fields.packages/visual-editor/src/components/LocatorResultCard.tsx (1)
237-248:getDisplayFieldOptionsmulti-type support looks correctAllowing
fieldTypeId: string | string[]and normalizing tofieldTypeIdsbefore filtering keeps existing single-string callers working and cleanly supports future multi-type lookups:const fieldTypeIds = Array.isArray(fieldTypeId) ? fieldTypeId : [fieldTypeId]; .filter((key) => fieldTypeIds.includes(displayFields![key].field_type_id))No functional issues here.
packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx (1)
28-61: Entity wrapper correctly reuses the new options-based input
EmbeddedFieldStringInputFromEntitynow derivesentityFieldOptionsviagetFieldsForSelectorand delegates toEmbeddedFieldStringInputFromOptions. This keeps all cursor/embedding and debounce behavior in one place while preserving the existing entity-field semantics.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
packages/visual-editor/src/components/LocatorResultCard.tsx (2)
238-256: Rules of Hooks violation:getDisplayFieldOptionscannot calluseTemplateMetadatahook.
getDisplayFieldOptionsis a regular function that calls theuseTemplateMetadata()hook on line 241. This violates React's Rules of Hooks, which state that hooks can only be called from React function components or custom hooks (functions starting with "use").Even though
getDisplayFieldOptionsis invoked via thegetOptionscallback during rendering, it's still not a component or hook itself.Solution: Convert
getDisplayFieldOptionsto a custom hook:-const getDisplayFieldOptions = ( +const useDisplayFieldOptions = ( fieldTypeId: string | string[] ): DynamicOption<string>[] => { const templateMetadata = useTemplateMetadata();Then update all call sites to use
useDisplayFieldOptionsand call it at the component level (in the render context of a component that uses these fields), storing the result and passing it togetOptions:// Example usage pattern - this would need to be adapted based on where fields are rendered const stringFieldOptions = useDisplayFieldOptions("type.string"); const hoursFieldOptions = useDisplayFieldOptions("type.hours"); // etc. // Then in field definitions: getOptions: () => stringFieldOptionsAlternatively, if the metadata doesn't change during the component lifecycle, you could retrieve it once at a higher level and pass it down as a parameter to a pure
getDisplayFieldOptionsfunction.
158-168: Type inconsistency:secondaryCTA.labelandsecondaryCTA.linkinterface types don't match implementation.The interface defines these fields as
string(lines 161, 163), but:
- The field definitions use
TranslatableStringField<any>(lines 517-530), which producesTranslatableStringvalues- The render code uses
resolveComponentData()on these fields (lines 783-794), which expectsTranslatableStringtypeUpdate the interface to match the implementation:
secondaryCTA: { /** Label for the secondary CTA */ - label: string; + label: TranslatableString; /** Template for the secondary CTA link, which can contain entity field references */ - link: string; + link: TranslatableString; /** The variant for the secondary CTA */ variant: CTAVariant;Also ensure the import includes
TranslatableString:import { ..., TranslatableString, ... } from "@yext/visual-editor";
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/visual-editor/src/components/LocatorResultCard.tsx(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-29T22:00:03.843Z
Learnt from: mkouzel-yext
Repo: yext/visual-editor PR: 833
File: packages/visual-editor/src/components/Locator.tsx:1050-1057
Timestamp: 2025-10-29T22:00:03.843Z
Learning: In packages/visual-editor/src/components/Locator.tsx, the AppliedFilters component is intentionally rendered in two locations (inside the filter modal and outside it) as per the design requirements. This dual rendering should not be flagged as a duplicate issue.
Applied to files:
packages/visual-editor/src/components/LocatorResultCard.tsx
🧬 Code graph analysis (1)
packages/visual-editor/src/components/LocatorResultCard.tsx (3)
packages/visual-editor/src/editor/DynamicOptionsSelector.tsx (1)
DynamicOption(33-36)packages/visual-editor/src/internal/hooks/useMessageReceivers.ts (1)
useTemplateMetadata(167-167)packages/visual-editor/src/editor/TranslatableStringField.tsx (1)
TranslatableStringField(25-121)
🔇 Additional comments (2)
packages/visual-editor/src/components/LocatorResultCard.tsx (2)
246-248: LGTM: Array normalization and filtering logic is correct.The implementation properly handles both single string and array inputs by normalizing to an array, then filtering display fields whose
field_type_idmatches any of the provided types.
524-530: The review comment is based on incorrect assumptions about available field types.The
locatorDisplayFieldsin templateMetadata only defines fields with types"type.string"and"type.phone". While"type.url"does exist elsewhere in the schema, it is not populated inlocatorDisplayFields. The link field correctly usesgetDisplayFieldOptions("type.string")because that is the only matching type available for field selection. Suggesting to filter on["type.string", "type.url"]would have no effect since no URL-typed fields are defined in the locatorDisplayFields metadata that this component operates against.Likely an incorrect or invalid review comment.
| const fieldTypeIds = Array.isArray(fieldTypeId) ? fieldTypeId : [fieldTypeId]; | ||
| return Object.keys(templateMetadata.locatorDisplayFields) | ||
| .filter((key) => displayFields[key].field_type_id === fieldTypeId) | ||
| .filter((key) => fieldTypeIds.includes(displayFields![key].field_type_id)) |
There was a problem hiding this comment.
Can you remove this !? Ben had commented on it on my PR; it tells the TS compiler to not type check when it should.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/visual-editor/src/components/LocatorResultCard.tsx (1)
239-257: Remove the non-null assertion operator.On Line 249, the non-null assertion operator (
displayFields!) bypasses TypeScript's type checking. The guard on Line 243 already handles the null case, but TypeScript doesn't recognize this pattern. Based on learnings from past reviews, these operators should be avoided.Consider restructuring to eliminate the need for the assertion:
const getDisplayFieldOptions = ( fieldTypeId: string | string[] ): DynamicOption<string>[] => { const templateMetadata = useTemplateMetadata(); - if (!templateMetadata?.locatorDisplayFields) { + const displayFields = templateMetadata?.locatorDisplayFields; + if (!displayFields) { return []; } - const displayFields = templateMetadata.locatorDisplayFields; const fieldTypeIds = Array.isArray(fieldTypeId) ? fieldTypeId : [fieldTypeId]; return Object.keys(templateMetadata.locatorDisplayFields) - .filter((key) => fieldTypeIds.includes(displayFields![key].field_type_id)) + .filter((key) => fieldTypeIds.includes(displayFields[key].field_type_id)) .map((key) => { const fieldData: FieldTypeData = displayFields[key]; return { label: fieldData.field_name, value: key, }; }); };
♻️ Duplicate comments (1)
packages/visual-editor/src/components/LocatorResultCard.tsx (1)
518-531: ReplaceTranslatableStringField<any>with proper typing.The
<any>type parameter bypasses TypeScript's type checking for both thelabelandlinkfields. This issue was previously flagged in past review comments and marked as addressed, but the code still uses<any>.Apply the previously suggested fix:
- label: TranslatableStringField<any>( + label: TranslatableStringField<TranslatableString>( msg("fields.label", "Label"), undefined, false, true, () => getDisplayFieldOptions("type.string") ), - link: TranslatableStringField<any>( + link: TranslatableStringField<TranslatableString>( msg("fields.link", "Link"), undefined, false, true, () => getDisplayFieldOptions("type.string") ),Note:
TranslatableStringis already imported at Line 30.
🧹 Nitpick comments (1)
packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx (1)
101-103: Optional: Simplify memoization.The
fieldOptionsmemoization simply returns theoptionsprop. This memoization doesn't add value sinceoptionsis already a stable reference from the parent.Consider simplifying:
- const fieldOptions = React.useMemo(() => { - return options; - }, [options]); + const fieldOptions = options;Or remove the intermediate variable entirely and use
optionsdirectly on Line 173.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/visual-editor/src/components/LocatorResultCard.tsx(4 hunks)packages/visual-editor/src/docs/components.md(1 hunks)packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx(8 hunks)packages/visual-editor/src/editor/TranslatableStringField.tsx(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/visual-editor/src/editor/TranslatableStringField.tsx
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-29T22:00:03.843Z
Learnt from: mkouzel-yext
Repo: yext/visual-editor PR: 833
File: packages/visual-editor/src/components/Locator.tsx:1050-1057
Timestamp: 2025-10-29T22:00:03.843Z
Learning: In packages/visual-editor/src/components/Locator.tsx, the AppliedFilters component is intentionally rendered in two locations (inside the filter modal and outside it) as per the design requirements. This dual rendering should not be flagged as a duplicate issue.
Applied to files:
packages/visual-editor/src/docs/components.mdpackages/visual-editor/src/components/LocatorResultCard.tsx
📚 Learning: 2025-11-06T14:55:12.395Z
Learnt from: benlife5
Repo: yext/visual-editor PR: 862
File: packages/visual-editor/src/utils/schema/resolveSchema.ts:118-135
Timestamp: 2025-11-06T14:55:12.395Z
Learning: In `packages/visual-editor/src/utils/schema/resolveSchema.ts`, the `OpeningHoursSchema` and `PhotoGallerySchema` functions from `yext/pages-components` contain internal type validation and handle invalid inputs gracefully (returning empty objects or undefined) rather than throwing TypeErrors, so no pre-validation guards are needed before calling them.
Applied to files:
packages/visual-editor/src/components/LocatorResultCard.tsx
🧬 Code graph analysis (2)
packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx (2)
packages/visual-editor/src/editor/index.ts (2)
EmbeddedFieldStringInputFromEntity(24-24)EmbeddedFieldStringInputFromOptions(25-25)packages/visual-editor/src/editor/YextEntityFieldSelector.tsx (1)
getFieldsForSelector(396-416)
packages/visual-editor/src/components/LocatorResultCard.tsx (4)
packages/visual-editor/src/types/types.ts (1)
TranslatableString(205-205)packages/visual-editor/src/editor/DynamicOptionsSelector.tsx (1)
DynamicOption(33-36)packages/visual-editor/src/internal/hooks/useMessageReceivers.ts (1)
useTemplateMetadata(167-167)packages/visual-editor/src/editor/TranslatableStringField.tsx (1)
TranslatableStringField(25-126)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: call_unit_test / unit_tests (18.x)
- GitHub Check: call_unit_test / unit_tests (20.x)
- GitHub Check: semgrep/ci
🔇 Additional comments (5)
packages/visual-editor/src/components/LocatorResultCard.tsx (2)
30-30: LGTM!The
TranslatableStringimport is necessary for the updated type annotations in theLocatorResultCardPropsinterface.
162-164: Breaking change: CTA properties now support localization.The
labelandlinkproperties have been changed fromstringtoTranslatableString, enabling locale-specific values for secondary CTA buttons. This is a breaking change to the public API that consumers will need to handle.packages/visual-editor/src/docs/components.md (1)
444-444: LGTM!The documentation correctly reflects the updated type signatures for
resultCard.secondaryCTA.labelandresultCard.secondaryCTA.link, now usingTranslatableStringinstead ofstring.packages/visual-editor/src/editor/EmbeddedFieldStringInput.tsx (2)
28-62: LGTM! Clean refactor using composition.The refactoring of
EmbeddedFieldStringInputFromEntityto composeEmbeddedFieldStringInputFromOptionsis well-structured. The memoization correctly depends onentityFieldsandfilter, and the separation of concerns improves maintainability.
193-252: LGTM! Correct implementation of conditional value display.The
useOptionValueprop correctly controls whether to display the raw option value or the resolved document value. The early return on Lines 212-214 efficiently skips unnecessary resolution whenuseOptionValueis true.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/visual-editor/src/components/LocatorResultCard.tsx (1)
239-257:getDisplayFieldOptionsarray support looks good; consider tightening the param typeThe normalization to
fieldTypeIdsand theincludesfilter overdisplayFields[key].field_type_idare correct and backward compatible with existing call sites.If you want stronger typing, you could narrow the parameter to the actual field type id domain:
-const getDisplayFieldOptions = ( - fieldTypeId: string | string[] -): DynamicOption<string>[] => { +const getDisplayFieldOptions = ( + fieldTypeId: FieldTypeData["field_type_id"] | FieldTypeData["field_type_id"][] +): DynamicOption<string>[] => {and then reuse
displayFieldsinObject.keys(displayFields)for slightly clearer intent.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/visual-editor/src/components/LocatorResultCard.tsx(4 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-29T22:00:03.843Z
Learnt from: mkouzel-yext
Repo: yext/visual-editor PR: 833
File: packages/visual-editor/src/components/Locator.tsx:1050-1057
Timestamp: 2025-10-29T22:00:03.843Z
Learning: In packages/visual-editor/src/components/Locator.tsx, the AppliedFilters component is intentionally rendered in two locations (inside the filter modal and outside it) as per the design requirements. This dual rendering should not be flagged as a duplicate issue.
Applied to files:
packages/visual-editor/src/components/LocatorResultCard.tsx
📚 Learning: 2025-11-06T14:55:12.395Z
Learnt from: benlife5
Repo: yext/visual-editor PR: 862
File: packages/visual-editor/src/utils/schema/resolveSchema.ts:118-135
Timestamp: 2025-11-06T14:55:12.395Z
Learning: In `packages/visual-editor/src/utils/schema/resolveSchema.ts`, the `OpeningHoursSchema` and `PhotoGallerySchema` functions from `yext/pages-components` contain internal type validation and handle invalid inputs gracefully (returning empty objects or undefined) rather than throwing TypeErrors, so no pre-validation guards are needed before calling them.
Applied to files:
packages/visual-editor/src/components/LocatorResultCard.tsx
🧬 Code graph analysis (1)
packages/visual-editor/src/components/LocatorResultCard.tsx (3)
packages/visual-editor/src/types/types.ts (1)
TranslatableString(205-205)packages/visual-editor/src/editor/DynamicOptionsSelector.tsx (1)
DynamicOption(33-36)packages/visual-editor/src/editor/TranslatableStringField.tsx (1)
TranslatableStringField(25-126)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: call_unit_test / unit_tests (18.x)
- GitHub Check: call_unit_test / unit_tests (20.x)
- GitHub Check: semgrep/ci
🔇 Additional comments (2)
packages/visual-editor/src/components/LocatorResultCard.tsx (2)
159-169: Secondary CTA label/link type change toTranslatableStringis consistent and safeProps now use
TranslatableStringand are resolved viaresolveComponentDataat render time, with a sensible fallback for the label and default string values inDEFAULT_LOCATOR_RESULT_CARD_PROPS, which still satisfy the alias. This looks correct and keeps the runtime behavior coherent with the new translation support.Also applies to: 772-800
514-531: Secondary CTA editor fields correctly wired to translatable + display field optionsUsing
TranslatableStringField<TranslatableString>for bothlabelandlinkwithgetDisplayFieldOptions("type.string")plugs the secondary CTA into the dynamic display field system and keeps the field value typed asTranslatableString. The argument ordering (label,undefinedfilter,falseapply-all,trueshowFieldSelector,getOptions) matches theTranslatableStringFieldsignature.
mkouzel-yext
deleted the
embed-display-fields-in-secondary-cta-dropdown
branch
Adds all the new functionality to support customizable result cards in the locator. This functionality was broken into #905 and #912 (which also included #915), and now all the new features are jointly being merged into main. J=[PB-26919](https://yext.atlassian.net/browse/PB-26919) --------- Co-authored-by: Kyle Gerner <kgerner@yext.com> Co-authored-by: Kyle Gerner <49618240+k-gerner@users.noreply.github.com> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Use display fields for the secondary CTA label/link
J=WAT-5225
locator_result_card_secondary_cta_display_field_demo.mov