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

[claude]

Claude finished @KevinDavilaDotCMS's task in 1m 48s —— View job

---

PR Review

• Read key changed files
• Analyze style editor schema changes
• Review page-api.ts (335 additions)
• Check type exports and module boundaries
• Flag issues

---

Issues Found

1. console.log left in production code — page-api.ts:474

console.log('styleEditorSchemas', styleEditorSchemas);

This fires on every client.page.get() call in production. Must be removed. Fix this →

---

2. Hardcoded mock with 335 lines of demo data baked into the SDK — page-api.ts:29–335

fetchStyleEditorSchemas returns a Promise.resolve of hardcoded schemas for a content type called 'Activity', complete with third-party ibb.co image URLs. All four parameters are unused (underscore-prefixed). This mock ships with the SDK as-is and runs on every page fetch. The TODO exists but the PR description says this is a production-ready refactor. If this is intentional WIP, it needs a clear signal (e.g., always returns []); if not, it should not be merged.

---

3. styleEditorSchemas is unconditionally included in every page response — page-api.ts:518

...(styleEditorSchemas && { styleEditorSchemas })

fetchStyleEditorSchemas returns Promise.resolve([{...}]) — a non-empty array, which is always truthy. So styleEditorSchemas is always spread into the response. Every consumer calling client.page.get() will receive the mock Activity schema in their response, which will break expectations in tests and applications.

---

4. Feature flag force-set to true — withFlags.ts:35

// TODO: Remove this, only hardcoded until the PR that fix is merged
flags[FeaturedFlags.FEATURE_FLAG_UVE_STYLE_EDITOR] = true;

The comment says "until the PR that fix is merged" — this is that PR, and it's still here. The TODO has not been resolved.

---

5. Breaking change: style editor types dropped from @dotcms/uve public exports

Previously @dotcms/uve/src/index.ts exported:

export * from './lib/style-editor/types';
export * from './lib/style-editor/public';

Both lines are now removed. Any consumer importing styleEditorField, StyleEditorForm, StyleEditorField, etc. from @dotcms/uve (not @dotcms/uve/internal) will break. The Angular example was updated, but there is no deprecation notice, migration guide, or semver bump in scope.

---

6. StyleEditorFormSchema from an internal module is embedded in the public page API — libs/sdk/types/src/lib/page/public.ts

import { StyleEditorFormSchema } from '../style-editor/internal';
// ...
styleEditorSchemas?: StyleEditorFormSchema[];  // added to DotCMSPageResponse

DotCMSPageResponse is public API consumed by all SDK frameworks. Importing from ../style-editor/internal into a public interface creates a dependency on an internal type. If StyleEditorFormSchema is needed in the public contract it should be in a public module, not internal.ts.

---

7. normalizeSection JSDoc describes a 2D array but the type and implementation return 1D — uve/src/lib/style-editor/internal.ts:120–153

The JSDoc says:

"Wraps the normalized fields array in an outer array to create the column structure"

And the example shows:

fields: [[field1, field2]]   // 2D

But StyleEditorSectionSchema.fields is typed as StyleEditorFieldSchema[] (1D) and normalizeSection returns fields: normalizedFields — a flat array. The comment, example, and implementation disagree. Either the type is wrong, the implementation is wrong, or the docs are wrong.

---

8. defineStyleEditorSchema is an empty wrapper with no validation — uve/src/lib/style-editor/internal.ts:237–239

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

The JSDoc says "Normalizes and validates" but there is no validation. This is identical to calling normalizeForm directly. It's an exported symbol with no behaviour of its own — either add the validation or remove the indirection.

---

Minor

• as unknown as StyleEditorFieldInputType double cast in normalizeField (internal.ts:75) — field.inputType should already satisfy the type without escaping the type system.
• fetchStyleEditorSchemas runs in Promise.all on every page request (page-api.ts:464). When the real endpoint lands, this adds a parallel HTTP call to every page fetch. Consider whether schemas should be lazily fetched or opt-in, rather than mandatory for every page load.