fix(experiments): Bring back functionallity of variants inside/outside UVE

[KevinDavilaDotCMS]

fix(experiments): enhance DotExperimentsProvider initialization and improve useExperimentVariant logic

2026-07-09.14-54-21.mov

Proposed Changes

• Updated DotExperimentsProvider to handle initialization errors gracefully by logging them in debug mode and ensuring the instance is set regardless of success or failure.
• Modified useExperimentVariant to consider any UVE mode as "inside the editor," aligning its logic with the updated provider check.
• Added a new test case for useExperimentVariant to verify behavior when in PREVIEW mode.

Impact

These changes improve the robustness of the experiments handling and ensure that the application can render correctly even if the DotExperiments instance fails to initialize.

Checklist

• Tests updated for new behavior
• Debug logging added for error handling

This PR fixes: #36484

This PR fixes: #36484

[claude]

Claude finished @KevinDavilaDotCMS's task in 6m 18s —— View job

---

Claude finished @KevinDavilaDotCMS's task in 2m 7s —— View job

---

Code Review

• Read PR diff and full source of changed files
• Verified UVE_MODE enum values and provider/hook consistency
• Checked error paths and test coverage

---

I reviewed all 5 changed files. This is a focused, low-risk fix that correctly restores variant handling behavior. The three logic changes are internally consistent:

1. useExperimentVariant.ts:33 — Changing getUVEState()?.mode === UVE_MODE.EDIT to !!getUVEState()?.mode now correctly matches DotExperimentsProvider.tsx:35, which has always treated any mode as "inside the editor." Verified all UVE_MODE values (EDIT_MODE, PREVIEW_MODE, LIVE, UNKNOWN) are truthy strings, so the coercion is sound. The removed UVE_MODE import is correctly dropped.

2. DotExperimentsProvider.tsx:40-53 — Moving setInstance into .finally() with a .catch() is the right call: consumers no longer hang forever when ready() rejects. Error is gated behind config.debug, consistent with the sibling console.warn.

3. useEditableDotCMSPage.ts:107-111 — Syncing updatedPageResponse to the incoming pageResponse prop outside UVE fixes the frozen-useState bug after client-side navigation. The effect already depends on [pageResponse], so this is correct.

New Issues

No blocking issues found.

Notes (non-blocking)

• 🟡 Medium: DotExperimentsProvider.tsx:50-53 — When ready() fails, the instance is still exposed to consumers. That's the intended "stop waiting and render" behavior, but downstream useExperimentVariant relies on getVariantFromHref() returning a match to set shouldWaitForVariant to false (useExperimentVariant.ts:55-63). If the instance failed to initialize and getVariantFromHref returns undefined, shouldWaitForVariant stays true (its default), so a consumer gating render on it could still hang. This is pre-existing hook logic rather than something this PR introduces, but worth confirming the consuming component has a fallback. What to verify: how withExperiments/consumers treat shouldWaitForVariant === true when the instance exists but is not ready.

Test coverage

• useExperimentVariant.spec.tsx — adds a PREVIEW-mode case proving non-EDIT modes now count as inside the editor. Good.
• useEditableDotCMSPage.test.tsx — adds a rerender-with-new-prop case outside UVE. Good; directly covers the frozen-state fix.

The changes look correct and ship-ready.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request