fix: language picker when url templates are in use

[briantstephan]

This fixes the URL templating issue when switching languages via the picker in the header component. It will require a change to our page set creation flow that requests the upcoming isPrimaryLocale field from the content endpoint.

[pkg-pr-new]

pages-visual-editor-starter

npm i https://pkg.pr.new/yext/visual-editor/@yext/visual-editor@840

commit: c7a532e

[github-actions]

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.

[coderabbitai]

Walkthrough

LanguageDropdown now calls useDocument() to obtain a StreamDocument and passes it into the updated fetchLocalesToPathsForEntity, whose signature now accepts a streamDocument parameter. fetchLocalesToPathsForEntity merges profile.meta with streamDocument via mergeMeta (profile.meta.locale preferred, adds __.isPrimaryLocale) and attempts per-locale URL resolution using resolvePageSetUrlTemplate; if that fails it falls back to resolveUrlTemplateOfChild. Each per-locale resolution is wrapped in try/catch and logs warnings on failures. resolvePageSetUrlTemplate and resolveUrlTemplateOfChild are newly exported utilities. No component props or public props changed.

Sequence Diagram(s)

sequenceDiagram
    participant LangDropdown as Language Dropdown
    participant Fetch as fetchLocalesToPathsForEntity
    participant API as Content API
    participant Merge as mergeMeta
    participant ResolvePage as resolvePageSetUrlTemplate
    participant ResolveChild as resolveUrlTemplateOfChild

    LangDropdown->>Fetch: call(params..., streamDocument)
    Fetch->>API: fetch profiles for entity
    API-->>Fetch: profiles[]

    loop per profile (locale)
        Fetch->>Merge: merge(profile.meta, streamDocument)
        Merge-->>Fetch: mergedDocument (locale, __.isPrimaryLocale)
        alt try page-set template
            Fetch->>ResolvePage: resolvePageSetUrlTemplate(mergedDocument, relativePrefix, alternate?)
            ResolvePage-->>Fetch: resolved URL
        else try child template
            Fetch->>ResolveChild: resolveUrlTemplateOfChild(mergedDocument, relativePrefix, alternate?)
            ResolveChild-->>Fetch: resolved URL or fallback path
        end
        alt resolution throws
            ResolvePage-->>Fetch: exception
            ResolveChild-->>Fetch: exception
            Fetch-->>Fetch: warn and keep locale entry without URL
        end
    end

    Fetch-->>LangDropdown: return Record<locale, pathOrUrl>

Loading

Suggested reviewers

• colton-demetriou
• mkilpatrick
• benlife5

Pre-merge checks and finishing touches

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The PR title "fix: language picker when url templates are in use" is specific, concise, and directly related to the main change in the changeset. The raw summary shows that the PR addresses language/locale switching functionality in the header component by refactoring URL template resolution and introducing locale-aware logic via isPrimaryLocale. The title accurately captures this primary fix and provides sufficient context for a teammate to understand the scope of the change without additional details.
Description Check	✅ Passed	The PR description is directly related to the changeset and accurately describes the fix being implemented. It mentions the specific issue (URL templating when switching languages via the picker in the header component) and identifies a key requirement (requesting the isPrimaryLocale field from the content endpoint), both of which are evident in the changes across languageDropdown.tsx, mergeMeta.ts, and related utility functions. The description is appropriately concise and conveys meaningful information about the changeset without requiring extensive detail.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch url-templates-locale

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[benlife5]

LGTM other than conflict

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 769513c and 8cbb9a3.

⛔ Files ignored due to path filters (2)

• packages/visual-editor/src/components/testing/screenshots/StaticMapSection/[desktop] default props with coordinate - with api key.png is excluded by !**/*.png, !packages/visual-editor/src/components/testing/screenshots/**
• packages/visual-editor/src/components/testing/screenshots/StaticMapSection/[mobile] default props with coordinate - with api key.png is excluded by !**/*.png, !packages/visual-editor/src/components/testing/screenshots/**

📒 Files selected for processing (3)

• packages/visual-editor/src/components/Locator.tsx (2 hunks)
• packages/visual-editor/src/utils/index.ts (1 hunks)
• packages/visual-editor/src/vite-plugin/templates/main.tsx (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

• packages/visual-editor/src/vite-plugin/templates/main.tsx
• packages/visual-editor/src/components/Locator.tsx

[mkilpatrick]

Much better

[mkilpatrick]

Build failed from name change

Build failed

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

packages/visual-editor/src/utils/getSchema.ts (1)

29-37: Consider adding error handling for URL template resolution.

The path resolution calls to resolveUrlTemplateOfChild and resolvePageSetUrlTemplate are not wrapped in error handling. If these functions throw exceptions, they would propagate unhandled since the existing try-catch block (line 45) only covers schema parsing, not path resolution.

Consider wrapping the path resolution in a try-catch block:

   } else {
     // TODO (SUMO-7941): Check that this resolves correctly for the schema drawer preview
-    if (
-      document?.__?.codeTemplate === "directory" ||
-      document?.__?.codeTemplate === "locator"
-    ) {
-      document.path = resolveUrlTemplateOfChild(
-        document,
-        data.relativePrefixToRoot
-      );
-    } else {
-      document.path = resolvePageSetUrlTemplate(
-        document,
-        data.relativePrefixToRoot
-      );
-    }
+    try {
+      if (
+        document?.__?.codeTemplate === "directory" ||
+        document?.__?.codeTemplate === "locator"
+      ) {
+        document.path = resolveUrlTemplateOfChild(
+          document,
+          data.relativePrefixToRoot
+        );
+      } else {
+        document.path = resolvePageSetUrlTemplate(
+          document,
+          data.relativePrefixToRoot
+        );
+      }
+    } catch (e) {
+      console.warn("Error resolving document path:", e);
+      document.path = "";
+    }
   }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8cbb9a3 and 545fe93.

📒 Files selected for processing (1)

• packages/visual-editor/src/utils/getSchema.ts (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

packages/visual-editor/src/utils/getSchema.ts (1)

packages/visual-editor/src/utils/index.ts (2)

• resolveUrlTemplateOfChild (26-26)
• resolvePageSetUrlTemplate (27-27)

⏰ 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). (4)

• GitHub Check: call_unit_test / unit_tests (20.x)
• GitHub Check: call_unit_test / unit_tests (18.x)
• GitHub Check: semgrep/ci
• GitHub Check: create-dev-release

🔇 Additional comments (3)

packages/visual-editor/src/utils/getSchema.ts (3)

2-5: LGTM: Import changes align with the new URL resolution strategy.

The split into two specialized resolvers supports the conditional logic below that selects the appropriate resolution strategy based on document type.

---

24-24: Verify schema drawer preview behavior per TODO comment.

The TODO comment references SUMO-7941 and indicates that path resolution correctness for the schema drawer preview needs verification. Given the changes to use two different resolution strategies, this verification is especially important.

---

25-38: Consider verifying the intended relationship between codeTemplate and entityTypeId.

The search reveals these are separate properties from different object paths:

• codeTemplate is at document?.__?.codeTemplate (used at lines 26-27 for URL resolver selection)
• entityTypeId is at document?.meta?.entityType?.id (used at line 47 for schema template selection)

Both independently check for "locator" semantics (line 27 and line 301), but without visible code correlating them, it's unclear if misalignment is possible or intentional. Confirm whether these should always align or if independent values are expected.