refactor(style-editor): restructure style editor schema handling and …

[KevinDavilaDotCMS]

…remove unused hooks

• Introduced for normalizing style editor forms.
• Updated and to register style editor schemas.
• Removed hook and associated tests to streamline the codebase.
• Added new types for style editor fields and schemas in .
• Updated various components to utilize the new schema handling, improving maintainability and clarity.

This refactor enhances the style editor's integration and prepares for future feature expansions.

2026-04-16.14-21-37.mov

This PR fixes: #35270

This PR fixes: #35270

[claude]

Claude finished @dario-daza's task in 2m 44s —— View job

---

Frontend Review

• Read key changed frontend files
• Analyze style-editor internal.ts
• Analyze page-api.ts and utils.ts
• Analyze withFlags.ts
• Analyze SDK hook changes (React/Angular)
• Post findings

---

Issues

1. Stale JSDoc not fixed — uve/src/lib/style-editor/internal.ts:107-143, 146, 205-221

Still showing the old multi-dimensional fields: [[...]] structure in both normalizeSection (line 112: "multi-dimensional array structure (fields: StyleEditorFieldSchema[][])" and example at lines 136-144) and normalizeForm (example at lines 205-221). The actual type is StyleEditorFieldSchema[] (flat) and the implementation at line 147 produces a flat array. The dead comment at line 146 ("Determine if fields is multi-column or single column") is also still there. This was flagged in the previous review and is still unaddressed.

2. console.warn not replaced — uve/src/lib/style-editor/internal.ts:258

console.warn(
    `[registerStyleEditorSchemas] Skipping schema with index [${index}] ...`
);

All other SDK code uses consola. Was flagged previously, still present. Fix this →

3. as unknown as double casts — uve/src/lib/style-editor/internal.ts:75-76

config.inputType = field.inputType as unknown as StyleEditorFieldInputType;
config.placeholder = field.placeholder as unknown as string;

After narrowing field.type === 'input', TypeScript narrows the union to StyleEditorInputField, where inputType is already 'text' | 'number' (identical to StyleEditorFieldInputType) and placeholder is already string | undefined. The double cast is hiding a type misalignment rather than resolving it — the types should be compatible without any cast. If they're not aligning naturally, the root cause is in the type definitions, not here. Fix this →

4. defineStyleEditorSchema is still a no-op alias — uve/src/lib/style-editor/internal.ts:237-239

Both defineStyleEditorSchema and normalizeForm remain exported from uve/src/internal.ts. Two public names for the same operation adds surface area. Flagged previously, still present.

5. fetchStyleEditorSchemas fires on every CSR page load in any mode — sdk/client/src/lib/client/page/utils.ts:286-288

The only guard is typeof window === 'undefined'. The serial HTTP request to /api/v1/page/{pageId}/contenttype-schema fires in LIVE and PREVIEW modes too — registerStyleEditorSchemas returns early for non-EDIT mode, but the network round-trip was already paid. Since the GraphQL path already fetches the page, this is a consistent extra request on every CSR page load. The accepted fix (include schemas in GraphQL) is tracked; until then, this should be noted at the call-site as a known limitation.

6. CONTENT_CHANGES doesn't re-register schemas — sdk/react/.../useEditableDotCMSPage.ts:136-147, sdk/angular/.../dotcms-editable-page.service.ts:106-112

The CONTENT_CHANGES handler only updates internal page state — it doesn't call registerStyleEditorSchemas. Schemas are also not included in the CONTENT_CHANGES payload (they come from a separate BE endpoint). If an editor drags in a contentlet with a new content type that has a DOT_STYLE_EDITOR_SCHEMA, the style panel won't activate until hard reload. This is known but still undocumented at the call-site.

---

Clean

withFlags.ts normalization logic and tests are correct and well-covered. The styleEditorField builder helpers in public.ts are clean. Deleting the large styleEditorSchemas.js files from examples is the right call.

[rjvelazco]

@claude check frontent changes again

[claude]

Claude finished @rjvelazco's task in 3m 3s —— View job

---

Frontend Review

• Gather context
• Read key frontend changed files
• Analyze SDK client changes (page-api.ts, utils.ts)
• Analyze UVE style-editor changes (internal.ts, public.ts, types.ts)
• Analyze store/flags changes (withFlags.ts)
• Analyze Angular/React SDK changes
• Post review findings

---

Summary

The architecture shift is sound — moving schema definition from client code to server-side DOT_STYLE_EDITOR_SCHEMA eliminates a large amount of integrator boilerplate (the deleted styleEditorSchemas.js files in the examples). The wiring across Angular, React, and UVE is consistent. Issues below are ordered by severity.

---

Issues

1. JSDoc/comment mismatch in normalizeSection — uve/src/lib/style-editor/internal.ts:103-153

The description says "organized as a multi-dimensional array (array of column arrays)" and the @example block shows fields: [[...]] (nested). But StyleEditorSectionSchema.fields is typed as StyleEditorFieldSchema[] (flat) and the implementation at line 147 produces a flat array. The JSDoc was not updated from the old multi-column design.

The dead comment at line 146 — // Determine if fields is multi-column or single column — is also a leftover: there is no branching, just a flat .map(). Same issue appears in normalizeForm's JSDoc block at lines 206-221, which also shows the nested structure.

Both need to be updated to reflect the actual (flat) output. Fix this →

2. fetchStyleEditorSchemas fires on every CSR page load — sdk/client/src/lib/client/page/utils.ts:286-288

The only guard is the SSR check (typeof window === 'undefined'). Every client-side client.page.get() call — including production/live mode pages — fires a serial HTTP request to /api/v1/page/{pageId}/contenttype-schema. The registerStyleEditorSchemas function (called downstream) already returns early when not in UVE_MODE.EDIT, but by that point the network round-trip has already been paid.

The @dotcms/client package intentionally doesn't depend on @dotcms/uve, so there's no clean way to gate on UVE mode at the fetch layer without a coupling violation. The right fix (noted by @rjvelazco) is to include schemas in the GraphQL response, eliminating this extra request. For now, at minimum, this design decision should be documented as a known limitation at the call-site in page-api.ts.

3. console.warn instead of consola — uve/src/lib/style-editor/internal.ts:259

console.warn(
    `[registerStyleEditorSchemas] Skipping schema with index [${index}] for not having a contentType`
);

All other SDK logging uses consola (see utils.ts). The UVE store's CLAUDE.md also flags console.* scattered across features as an anti-pattern. Fix this →

4. CONTENT_CHANGES schema registration gap — sdk/react/src/lib/next/hooks/useEditableDotCMSPage.ts:127-129 and sdk/angular/src/lib/services/dotcms-editable-page.service.ts:86-88

registerStyleEditorSchemas is called once when the initial pageResponse is received. When UVE pushes a CONTENT_CHANGES event, the payload doesn't include styleEditorSchemas (schemas are not re-fetched on content changes). This means: if a page editor drags in a contentlet whose content type has a DOT_STYLE_EDITOR_SCHEMA that wasn't present on initial load, the style panel won't activate for it until the page is hard-reloaded.

This is likely acceptable for the initial ship but should be documented as a known limitation, since it creates a confusing editing experience.

5. defineStyleEditorSchema is a no-op alias — uve/src/lib/style-editor/internal.ts:237-239

export function defineStyleEditorSchema(form: StyleEditorForm): StyleEditorFormSchema {
    return normalizeForm(form);
}

This is a transparent wrapper with no additional logic or validation. Having two exported names for the same operation (defineStyleEditorSchema and normalizeForm) adds surface area without benefit. If defineStyleEditorSchema is the public-facing name for schema registration, normalizeForm should be unexported (or vice versa). Currently both are exported from uve/src/internal.ts.

---

Nits

• withFlags.ts — the FEATURE_FLAG_NOT_FOUND → true normalization is correct and the added comment explaining the behavior is a good addition.
• public.ts (uve) — the styleEditorField builder helpers are clean and well-typed.
• Deleting the large styleEditorSchemas.js files from the examples (336 lines each × 3 frameworks) is the main win of this PR — integrators no longer need to maintain those.
• page-api.spec.ts line 130-139 correctly asserts that the contenttype-schema endpoint is called, which is good test coverage for the new flow.