feat: allow static primary CTA url templates in locator result cards#1072
Open
mkouzel-yext wants to merge 29 commits intomainfrom
Open
feat: allow static primary CTA url templates in locator result cards#1072mkouzel-yext wants to merge 29 commits intomainfrom
mkouzel-yext wants to merge 29 commits intomainfrom
Conversation
When resolving the URL for the primary CTA in Locator result cards, the URL template is now read from whichever source entity page set in __.locatorSourcePageSets includes the result entity in the Locator config rather than the __.pathInfo.sourceEntityPageSetTemplate field or the legacy __.entityPageSetUrlTemplates field. The __.locatorSourcePageSets field on the stream document contains the entity type API name, internal saved search ID, and a pathInfo object for each source entity page set of the locator. The pathInfo object contains the necessary data to resolve the CTA url for a search result: URL template, primary locale, and whether to include a locale prefix for the primary locale. Makes use of the existing resolveUrlFromPathInfo to handle actual URL resolution. Also updates Puck options for facet fields to include all options that apply to either entity type. J=WAT-5361 TEST=manual Confirmed that CTA urls used the template of the correct page set and that expected facet options were shown without duplicates.
Gets passed in this way from Cog
Updates the LocatorResultCard component to support custom links on the primary CTA. Previously, these were always resolved from the source entity page set, but now the result entities may not be associated with any page set. Two propertys were added to the primaryCTA: * Destination: whether to derive the URL from the source page set or from the static template in the link field * Link: the template to use if the destination field is "custom" The following display logic is implemented: * If the locator has no source page set, do not render the Destination select - it will always be "custom" * If the locator has a source page set, render the Destination select (either "entity page" or "custom") * If Destination is "entity page", do not render the Link field input because it is not used * If Destination is "custom", render the Link field input J=WAT-5361
Contributor
|
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. |
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: Repository UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughAdds a selectable destination for the Locator result card's primary CTA ( Sequence Diagram(s)sequenceDiagram
participant Editor as Visual Editor
participant ResultCard as LocatorResultCard
participant PrimaryCTA as PrimaryCTA
participant LocatorConfig as useLocatorConfig
participant Document as Pageset Document
Editor->>ResultCard: provide resultCard.primaryCTA props
ResultCard->>PrimaryCTA: render with primaryCTA props
PrimaryCTA->>PrimaryCTA: inspect destination
alt destination == "custom"
PrimaryCTA->>PrimaryCTA: use primaryCTA.link as URL
else destination == "entityPage"
PrimaryCTA->>LocatorConfig: request locator routing info
LocatorConfig->>Document: read pageset locator config
Document-->>LocatorConfig: return config
LocatorConfig-->>PrimaryCTA: provide routing info
PrimaryCTA->>PrimaryCTA: resolve URL via resolveLocatorResultUrl
end
PrimaryCTA-->>ResultCard: return resolved URL
ResultCard-->>Editor: render CTA
Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/visual-editor/src/components/LocatorResultCard.tsx`:
- Around line 314-323: Rename the function getLocatorConfig to useLocatorConfig
(it calls the React hook useDocument), update its definition accordingly, and
update all call sites that reference getLocatorConfig (e.g., the place where it
is invoked to obtain locatorConfig) to call useLocatorConfig instead; ensure the
renamed function remains a top-level function (not used inside non-hook
callbacks) so it obeys the Rules of Hooks and returns the same value
(pageSet?.typeConfig?.locatorConfig ?? {}) after parsing streamDocument._pageset
with the same try/catch behavior.
In
`@packages/visual-editor/src/components/migrations/0065_add_locator_primary_cta_destination.ts`:
- Around line 5-25: Import the new migration symbol
addLocatorPrimaryCtaDestination into the migrations registry module and append
it to the migrationRegistry array so it will run; specifically, in
migrationRegistry.ts add an import for addLocatorPrimaryCtaDestination from its
module and include addLocatorPrimaryCtaDestination in the exported
migrationRegistry array alongside the other migrations.
ℹ️ Review info
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
packages/visual-editor/src/components/Locator.tsxpackages/visual-editor/src/components/LocatorResultCard.tsxpackages/visual-editor/src/components/migrations/0065_add_locator_primary_cta_destination.tspackages/visual-editor/src/docs/components.mdpackages/visual-editor/src/vite-plugin/defaultLayoutData.ts
packages/visual-editor/src/components/migrations/0065_add_locator_primary_cta_destination.ts
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Actionable comments posted: 12
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/visual-editor/locales/platform/cs/visual-editor.json`:
- Line 288: The "custom" translation value in the locales file is
incorrect—replace the value for the "custom" key in
packages/visual-editor/locales/platform/cs/visual-editor.json (the entry
currently reading "Zvyk") with "Vlastní" so it matches existing UI terminology
and the intended meaning for CTA destination behavior.
In `@packages/visual-editor/locales/platform/da/visual-editor.json`:
- Line 288: The translation for the JSON key "custom" currently uses the Danish
word "Skik" (value "Skik"); replace it with a UI-appropriate Danish term such as
"Tilpasset" or "Brugerdefineret" so it matches the surrounding settings labels
and conveys "user-defined/customized" rather than "tradition". Update the value
for the "custom" key accordingly in the visual-editor.json locale entry.
In `@packages/visual-editor/locales/platform/de/visual-editor.json`:
- Line 288: The translation for the JSON key "custom" is the UI-inappropriate
noun "Brauch"; update the value for the "custom" key in visual-editor.json to a
proper UI label such as "Benutzerdefiniert" (or "Eigenes"/"Eigene") so it
clearly conveys "custom/user-defined" in the destination selector.
In `@packages/visual-editor/locales/platform/es/visual-editor.json`:
- Line 288: Replace the incorrect Spanish translation for the "custom" key
(currently "Costumbre") with the UI-config option wording; update the value for
the "custom" entry to "Personalizado" (or "Personalizada" per product glossary)
so the option reads as a configurable/customized choice rather than a cultural
“habit” meaning.
In `@packages/visual-editor/locales/platform/hr/visual-editor.json`:
- Line 288: Update the Croatian translation for the JSON key "custom" in the
visual-editor locale so the UI conveys "customized" style instead of the noun
"tradition"; replace the current value "Običaj" with a configurable-style term
such as "Prilagođeno" for the "custom" entry.
In `@packages/visual-editor/locales/platform/hu/visual-editor.json`:
- Line 288: The translation for the JSON key "custom" is incorrect—replace the
value "Szokás" with a software-appropriate Hungarian term such as "Egyéni" or
"Egyedi" for the "custom" key in the visual-editor locale (look for the "custom"
property in packages/visual-editor/locales/platform/hu/visual-editor.json and
update its value to "Egyéni" or "Egyedi").
In `@packages/visual-editor/locales/platform/nb/visual-editor.json`:
- Line 288: The JSON translation key "custom" currently has the value "Skikk"
which is misleading; change the value for the "custom" key in the Norwegian
locale (visual-editor.json) to "Tilpasset" so the UI shows the more accurate
label. Locate the "custom" entry and replace "Skikk" with "Tilpasset",
preserving JSON formatting and quotes.
In `@packages/visual-editor/locales/platform/pl/visual-editor.json`:
- Line 288: The locale key "custom" in visual-editor.json currently maps to the
noun "Zwyczaj" which is not appropriate for a UI selection; update the
translation for the "custom" key to a UI-appropriate label such as
"Niestandardowe" (or your product-approved equivalent) so the selectable option
reads correctly in Polish; locate the "custom" entry in
packages/visual-editor/locales/platform/pl/visual-editor.json and replace the
value "Zwyczaj" with the approved label.
In `@packages/visual-editor/locales/platform/tr/visual-editor.json`:
- Line 288: The translation for the "custom" UI key is incorrect ("Gelenek");
update the value for the JSON key "custom" in visual-editor.json to the accurate
UI term "Özel" (or the approved Turkish glossary term) so the selector displays
the correct meaning in the product UI; locate the entry with the key "custom"
and replace its string value accordingly.
In `@packages/visual-editor/locales/platform/zh-TW/visual-editor.json`:
- Line 288: The "custom" label in the localization JSON is mistranslated: the
key "custom" currently maps to "風俗" (which means customs/traditions) — replace
it with the correct Traditional Chinese term for user-defined/custom, e.g.,
change the value for the "custom" key to "自訂" (or "自定義") in the
visual-editor.json so the destination selector reads as expected.
In `@packages/visual-editor/locales/platform/zh/visual-editor.json`:
- Line 288: The translation for the JSON key "custom" is incorrect — replace the
value "风俗" with the context-appropriate string "自定义" so the CTA destination
option reads as “custom/configurable” (update the value for the "custom" key in
the visual-editor.json entry).
ℹ️ Review info
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (26)
packages/visual-editor/locales/platform/cs/visual-editor.jsonpackages/visual-editor/locales/platform/da/visual-editor.jsonpackages/visual-editor/locales/platform/de/visual-editor.jsonpackages/visual-editor/locales/platform/en-GB/visual-editor.jsonpackages/visual-editor/locales/platform/en/visual-editor.jsonpackages/visual-editor/locales/platform/es/visual-editor.jsonpackages/visual-editor/locales/platform/et/visual-editor.jsonpackages/visual-editor/locales/platform/fi/visual-editor.jsonpackages/visual-editor/locales/platform/fr/visual-editor.jsonpackages/visual-editor/locales/platform/hr/visual-editor.jsonpackages/visual-editor/locales/platform/hu/visual-editor.jsonpackages/visual-editor/locales/platform/it/visual-editor.jsonpackages/visual-editor/locales/platform/ja/visual-editor.jsonpackages/visual-editor/locales/platform/lt/visual-editor.jsonpackages/visual-editor/locales/platform/lv/visual-editor.jsonpackages/visual-editor/locales/platform/nb/visual-editor.jsonpackages/visual-editor/locales/platform/nl/visual-editor.jsonpackages/visual-editor/locales/platform/pl/visual-editor.jsonpackages/visual-editor/locales/platform/pt/visual-editor.jsonpackages/visual-editor/locales/platform/ro/visual-editor.jsonpackages/visual-editor/locales/platform/sk/visual-editor.jsonpackages/visual-editor/locales/platform/sv/visual-editor.jsonpackages/visual-editor/locales/platform/tr/visual-editor.jsonpackages/visual-editor/locales/platform/zh-TW/visual-editor.jsonpackages/visual-editor/locales/platform/zh/visual-editor.jsonpackages/visual-editor/src/components/Locator.tsx
✅ Files skipped from review due to trivial changes (1)
- packages/visual-editor/locales/platform/fr/visual-editor.json
packages/visual-editor/locales/platform/zh-TW/visual-editor.json
Outdated
Show resolved
Hide resolved
Also renames function
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/visual-editor/src/components/migrations/migrationRegistry.ts (1)
66-66: Import missing.tsextension for consistency.All other imports in this file include the
.tsextension. This import should follow the same pattern for consistency.🧹 Proposed fix
-import { addLocatorPrimaryCtaDestination } from "./0065_add_locator_primary_cta_destination"; +import { addLocatorPrimaryCtaDestination } from "./0065_add_locator_primary_cta_destination.ts";🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/visual-editor/src/components/migrations/migrationRegistry.ts` at line 66, The import of addLocatorPrimaryCtaDestination is missing the .ts extension; update the import statement for addLocatorPrimaryCtaDestination (the symbol named addLocatorPrimaryCtaDestination) to include the ".ts" suffix so it matches the other imports in migrationRegistry and maintains consistent module resolution.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/visual-editor/src/components/LocatorResultCard.tsx`:
- Around line 702-709: The Link field (TranslatableStringField) is always
visible; change it to only render when the sibling destination equals "custom"
by wrapping it in the same conditional field pattern used by
PrimaryCtaDestinationField/PrimaryCtaDestinationField()—i.e. create a small
wrapper/custom field inside LocatorResultCard (or the same field definitions
block) that reads the sibling value for destination (using the same
locatorConfig access pattern) and returns the TranslatableStringField only when
destination === "custom", otherwise returns null or an empty field.
---
Nitpick comments:
In `@packages/visual-editor/src/components/migrations/migrationRegistry.ts`:
- Line 66: The import of addLocatorPrimaryCtaDestination is missing the .ts
extension; update the import statement for addLocatorPrimaryCtaDestination (the
symbol named addLocatorPrimaryCtaDestination) to include the ".ts" suffix so it
matches the other imports in migrationRegistry and maintains consistent module
resolution.
ℹ️ Review info
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/visual-editor/src/components/LocatorResultCard.tsxpackages/visual-editor/src/components/migrations/migrationRegistry.ts
Comment on lines
+702
to
+709
| destination: PrimaryCtaDestinationField(), | ||
| link: TranslatableStringField<TranslatableString | undefined>( | ||
| msg("fields.link", "Link"), | ||
| undefined, | ||
| false, | ||
| true, | ||
| () => getDisplayFieldOptions("type.string") | ||
| ), |
Contributor
There was a problem hiding this comment.
Link field visibility not conditional on destination.
Per PR objectives, the Link field should only render when Destination is "custom". Currently, the link field is always visible regardless of the destination value. While this doesn't cause functional issues (the link is only used when destination === "custom"), it may confuse users.
Consider wrapping TranslatableStringField in a custom field that checks the sibling destination value, similar to how PrimaryCtaDestinationField conditionally renders based on locatorConfig.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/visual-editor/src/components/LocatorResultCard.tsx` around lines 702
- 709, The Link field (TranslatableStringField) is always visible; change it to
only render when the sibling destination equals "custom" by wrapping it in the
same conditional field pattern used by
PrimaryCtaDestinationField/PrimaryCtaDestinationField()—i.e. create a small
wrapper/custom field inside LocatorResultCard (or the same field definitions
block) that reads the sibling value for destination (using the same
locatorConfig access pattern) and returns the TranslatableStringField only when
destination === "custom", otherwise returns null or an empty field.
Based on Code Rabbit suggestions
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updates the LocatorResultCard component to support custom links on the primary CTA. Previously, these were always resolved from the source entity page set, but now the result entities may not be associated with any page set. Two propertys were added to the primaryCTA:
The following display logic is implemented:
J=WAT-5361