fix(uve): Support see draft pages insive UVE

[KevinDavilaDotCMS]

• Updated to accept as a valid input, allowing it to function correctly while waiting for the UVE editor to resolve draft pages.
• Added a test case to ensure returns false when data is undefined.
• Modified to handle cases where the page response can be undefined or only contain GraphQL data, improving its robustness in draft scenarios.
• Updated related components and contexts to reflect the new handling of undefined page assets, ensuring consistent behavior across the application.

This change improves the handling of draft pages and enhances the user experience during content editing.

2026-08-05.14-51-04.mov

This PR fixes: #35887

[claude]

Claude finished @KevinDavilaDotCMS's task in 4m 28s —— View job

---

SDK Compatibility Check

• Read SDK breaking-change categories reference (docs/core/SDK_BREAKING_CHANGE_CATEGORIES.md)
• Get full PR diff (git diff origin/main..HEAD)
• Analyze diff against every category (G-1/G-2/G-3, R-1, U-1/U-2, H-1)
• Post findings / apply label (not needed — see below)

Result: No SDK breaking change detected.

Analysis:

• No Java/backend files changed at all in this PR — confirmed via git diff origin/main..HEAD -- '*.java' (empty). So there's no GraphQL schema change (G-1/G-2/G-3) and no REST response shape change (R-1) — nothing in /api/v1/page/*, /api/v1/nav, /api/v1/content, or the page-api GraphQL query builder was touched.
• UVE/editor postMessage protocol (U-1/U-2): the PR only loosens the SDK-side TypeScript signature of initUVE() in core-web/libs/sdk/uve/src/lib/editor/public.ts from config: DotCMSPageResponse = {} as DotCMSPageResponse to config: Partial<DotCMSPageResponse> = {}, and the same for setClientIsReady() in core-web/libs/sdk/uve/src/script/utils.ts. Both still just forward config as-is as the CLIENT_READY payload — this is a compile-time type change only, not a wire-format change. No DotCMSUVEAction enum values were renamed/removed (core-web/libs/sdk/types/src/lib/editor/public.ts isn't touched), and the editor's CLIENT_READY handler in dot-uve-actions-handler.service.ts (also untouched by this PR) already destructures devConfig || {} / graphql || {} defensively, so a partial { graphql }-only payload (the new draft-page scenario) is handled without error by the existing editor code — and this isn't a change an old SDK could trigger anyway, since old SDKs always sent the full object.
• SDK compatibility headers (H-1): sdk-compatibility.ts / SdkVersionWebInterceptor are not part of this diff.
• The rest of the changes (useEditableDotCMSPage, useExperimentVariant, DotCMSPageContext, Container, isRequestFromUVE, and the examples/nextjs app) are SDK-internal/client-library and example-app changes — they widen accepted input types (undefined/partial page responses) and add a new additive helper (isRequestFromUVE). These affect how the SDK behaves for its own consumers, not the wire contract between an already-published SDK and the server, so they fall under "internal refactor / additive change" (non-breaking) per the reference doc.

No gh pr comment was posted and no SDK Breaking Change label was applied, per the check's instructions for non-breaking changes.

[mergify]

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

• Queue this pull request