[7418] plugin - serializers/retrievers/validators - #8882
Conversation
WalkthroughFE2 control plugins now support value retrieval, serialization, and validation hooks. Forms Engine preloads referenced plugins before embedded, create, and edit form initialization. The controls host exposes hook lookups and ChangesFE2 control plugin lifecycle
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Plugin
participant registerPlugin
participant registry
participant FormsEngine
participant controlPluginLoader
Plugin->>registerPlugin: provide control hooks
registerPlugin->>registry: register contribution
FormsEngine->>controlPluginLoader: preload plugins for form fields
controlPluginLoader-->>FormsEngine: resolve loaded plugins
FormsEngine->>registry: resolve retriever, serializer, or validator
registry-->>FormsEngine: return registered hook
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@studio-ui/docs/type-builder-forms-engine.md`:
- Around line 667-670: Synchronize the Progress and Open decisions sections in
the Forms Engine documentation with the completed control cleanup: remove or
mark resolved the entries for retired IDs link-input, link-textarea,
linked-dropdown and the remapped disabled/internal-name aliases, ensuring no
unresolved null-map-slot item remains.
In `@studio-ui/ui/app/src/components/FormsEngine/FormsEngine.tsx`:
- Around line 539-543: In
studio-ui/ui/app/src/components/FormsEngine/FormsEngine.tsx:539-543, update the
preload promise handling around initCreateForm to set the preparation error and
prevent initCreateForm from running when preloadControlPluginsForFields fails.
Apply the same behavior in
studio-ui/ui/app/src/components/FormsEngine/FormsEngine.tsx:586-621: set the
preparation error and do not call createParsedValuesObject after preload
failure; retain the existing success paths.
- Around line 539-546: Update the embedded-component initialization flow around
prepareEmbeddedItemForm and invokePrepareFn so the embedded content type’s
fields are preloaded before invokePrepareFn parses or validates values. Reuse
the existing preloadControlPluginsForFields mechanism, awaiting or chaining it
before invokePrepareFn, while preserving the current parent-field preload and
initCreateForm behavior.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 98e61389-0047-4be3-bb0d-ac26f0c1ae00
📒 Files selected for processing (14)
studio-ui/docs/type-builder-forms-engine-plugins.mdstudio-ui/docs/type-builder-forms-engine.mdstudio-ui/ui/app/src/components/FormsEngine/FormsEngine.tsxstudio-ui/ui/app/src/components/FormsEngine/components/TableOfContents.tsxstudio-ui/ui/app/src/components/FormsEngine/controls/registry.tsstudio-ui/ui/app/src/components/FormsEngine/dataSources/host.tsstudio-ui/ui/app/src/components/FormsEngine/lib/controlPluginLoader.tsstudio-ui/ui/app/src/components/FormsEngine/lib/controlValueTypes.tsstudio-ui/ui/app/src/components/FormsEngine/lib/rteUtils.tsstudio-ui/ui/app/src/components/FormsEngine/lib/validators.tsstudio-ui/ui/app/src/components/FormsEngine/lib/valueRetrievers.tsstudio-ui/ui/app/src/components/FormsEngine/lib/valueSerializers.tsstudio-ui/ui/app/src/models/PluginDescriptor.tsstudio-ui/ui/app/src/services/plugin.ts
|
@coderabbitai can you check if everything looks good? Please give it a final review before I hand over for human review |
|
|
|
Your plan includes PR reviews subject to rate limits. Reviews are available now. |
|
@coderabbitai can you check if everything looks good? Please give it a final review before I hand over for human review |
|
|
|
@coderabbitai how does this work look to be merged? Any issues you can point out? |
|
✅ Action performedFull review finished. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@studio-ui/ui/app/src/components/FormsEngine/lib/controlPluginLoader.ts`:
- Around line 92-116: Update the preload flow around the Promise.all call in the
control plugin loader to wait for every import to settle before returning,
rather than rejecting immediately on the first failure. Preserve the existing
controlPluginCache cleanup, console.error logging, and rejection/continue
behavior for failed imports while ensuring successful plugin imports finish
before callers proceed.
- Around line 69-70: Extend the recursive preload traversal alongside the
field.fields handling in the loader to inspect node-selector item.component
values, resolve each embedded content type, and walk its fields before
createParsedValueForField parses values. Reuse the existing plugin-discovery and
content-type resolution logic so embedded controls are registered before
parsing.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 46eb676d-e67b-410a-bc6b-ddc58c6be044
📒 Files selected for processing (14)
studio-ui/docs/type-builder-forms-engine-plugins.mdstudio-ui/docs/type-builder-forms-engine.mdstudio-ui/ui/app/src/components/FormsEngine/FormsEngine.tsxstudio-ui/ui/app/src/components/FormsEngine/components/TableOfContents.tsxstudio-ui/ui/app/src/components/FormsEngine/controls/registry.tsstudio-ui/ui/app/src/components/FormsEngine/dataSources/host.tsstudio-ui/ui/app/src/components/FormsEngine/lib/controlPluginLoader.tsstudio-ui/ui/app/src/components/FormsEngine/lib/controlValueTypes.tsstudio-ui/ui/app/src/components/FormsEngine/lib/rteUtils.tsstudio-ui/ui/app/src/components/FormsEngine/lib/validators.tsstudio-ui/ui/app/src/components/FormsEngine/lib/valueRetrievers.tsstudio-ui/ui/app/src/components/FormsEngine/lib/valueSerializers.tsstudio-ui/ui/app/src/models/PluginDescriptor.tsstudio-ui/ui/app/src/services/plugin.ts
|
@coderabbitai can you check if everything looks good? Please give it a final review before I hand over for human review |
|
✅ Action performedFull review finished. |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
studio-ui/ui/app/src/components/FormsEngine/lib/rteUtils.ts (1)
119-126: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUpdate the
content_cssfallback comment.Line 286 still says that missing
content_cssalways selects dark/default styles. The new branch selects[]for inline editors. Update the comment to describe both paths.As per coding guidelines, “Do not remove comments unless they are no longer applicable to the code they describe”; keep Line 286 accurate.
Proposed comment update
- 'content_css' // Handled above, if no content_css is found it will use dark/default styles. + 'content_css' // Handled above: inline editors use [] when no content_css is configured; non-inline editors use dark/default styles.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@studio-ui/ui/app/src/components/FormsEngine/lib/rteUtils.ts` around lines 119 - 126, Update the fallback comment associated with content_css in the TinyMCE options logic to accurately describe both behaviors: inline editors use an empty stylesheet array and non-inline editors select dark or default styles based on the preferred color scheme. Keep the comment in place and aligned with the conditional branches.Source: Coding guidelines
studio-ui/docs/type-builder-forms-engine-plugins.md (1)
285-288: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDocument the non-blocking preload failure path.
The hook contract documents preload timing but not failure handling. If
preloadControlPluginsForFieldsrejects for one locator, Forms Engine logs the failure and continues initialization. Hooks for that plugin can be unavailable. Add this behavior to the preload documentation.Based on learnings, this is the expected host behavior. As per path instructions, record this durable behavior in
studio-ui/docs/type-builder-forms-engine.md's Progress and Open decisions sections.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@studio-ui/docs/type-builder-forms-engine-plugins.md` around lines 285 - 288, Update the preload documentation around preloadControlPluginsForFields to state that a rejection for one locator is logged, does not block Forms Engine initialization, and may leave that plugin’s hooks unavailable. Also record this established host behavior in the Progress and Open decisions sections of the Forms Engine documentation.Sources: Path instructions, Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@studio-ui/docs/type-builder-forms-engine-plugins.md`:
- Around line 285-288: Update the preload documentation around
preloadControlPluginsForFields to state that a rejection for one locator is
logged, does not block Forms Engine initialization, and may leave that plugin’s
hooks unavailable. Also record this established host behavior in the Progress
and Open decisions sections of the Forms Engine documentation.
In `@studio-ui/ui/app/src/components/FormsEngine/lib/rteUtils.ts`:
- Around line 119-126: Update the fallback comment associated with content_css
in the TinyMCE options logic to accurately describe both behaviors: inline
editors use an empty stylesheet array and non-inline editors select dark or
default styles based on the preferred color scheme. Keep the comment in place
and aligned with the conditional branches.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: dd6da48b-58a7-41b4-8af1-4cfecc9d721b
📒 Files selected for processing (14)
studio-ui/docs/type-builder-forms-engine-plugins.mdstudio-ui/docs/type-builder-forms-engine.mdstudio-ui/ui/app/src/components/FormsEngine/FormsEngine.tsxstudio-ui/ui/app/src/components/FormsEngine/components/TableOfContents.tsxstudio-ui/ui/app/src/components/FormsEngine/controls/registry.tsstudio-ui/ui/app/src/components/FormsEngine/dataSources/host.tsstudio-ui/ui/app/src/components/FormsEngine/lib/controlPluginLoader.tsstudio-ui/ui/app/src/components/FormsEngine/lib/controlValueTypes.tsstudio-ui/ui/app/src/components/FormsEngine/lib/rteUtils.tsstudio-ui/ui/app/src/components/FormsEngine/lib/validators.tsstudio-ui/ui/app/src/components/FormsEngine/lib/valueRetrievers.tsstudio-ui/ui/app/src/components/FormsEngine/lib/valueSerializers.tsstudio-ui/ui/app/src/models/PluginDescriptor.tsstudio-ui/ui/app/src/services/plugin.ts
1 participant
#7418
Summary by CodeRabbit