mengw15 commented on code in PR #8438:
URL: https://github.com/apache/texera/pull/8438#discussion_r3945130471
##########
frontend/src/app/workspace/component/workflow-form/workflow-form.component.ts:
##########
@@ -367,9 +364,104 @@ export class WorkflowFormComponent implements OnInit,
OnDestroy {
field.props = { ...(field.props ?? {}), disabled: true };
}
+ this.applyFieldOverrides(field, binding);
return { resolved, fields: [field], form, model };
}
+ /**
+ * The template for one row of a repeated section. formly's `fieldArray` may
be the template
+ * object or a function that builds one per row; resolve both so an array
property's sub-fields
+ * are reachable (treating the function case as a leaf hid them). @internal,
exported for tests.
+ */
+ public static arrayItemOf(node: FormlyFieldConfig): FormlyFieldConfig |
undefined {
+ const fa = node.fieldArray;
+ if (!fa) {
+ return undefined;
+ }
+ if (typeof fa !== "function") {
+ return fa;
+ }
+ try {
+ return fa(node);
+ } catch {
+ // A builder that needs more context than we can give it tells us
nothing about the row's
+ // shape; better to list no sub-fields than to guess at them.
+ return undefined;
+ }
+ }
+
+ /**
+ * The override path for a child field: the parent path joined with the
child's key, but array
+ * indices are dropped so one override entry covers every row of a repeated
section. @internal,
+ * exported for tests.
+ */
+ public static childPath(parent: string, key: unknown): string {
+ if (typeof key !== "string" || key === "" || /^\d+$/.test(key)) {
+ return parent;
+ }
+ return parent ? parent + "." + key : key;
+ }
+
+ /**
+ * Walk the field and its sub-fields, dropping the operator schema's own
per-field descriptions
+ * (author notes about the operator, not guidance to a form reader) and
applying the author's
+ * stored per-sub-field overrides (rename, hide), keyed by field path. A
repeated section builds
+ * its row template on demand, so its builder is wrapped to decorate every
row formly ever makes.
+ */
+ private applyFieldOverrides(field: FormlyFieldConfig, binding:
FormFieldBinding): void {
+ const walk = (node: FormlyFieldConfig, path: string): void => {
+ // Drop the schema's own description on every field, nested ones
included: on this page the
+ // one piece of guidance is the help text the form's author writes,
rendered once by the card.
+ node.props = { ...(node.props ?? {}), description: "" };
+ // Apply the author's stored overrides so a reader sees each sub-field
renamed and hidden as
+ // set up. The root (path "") carries the binding's own displayName, set
in renderField.
+ if (path) {
+ const override = binding.overrides?.[path] ?? {};
+ if (override.displayName) {
+ node.props = { ...(node.props ?? {}), label: override.displayName };
+ }
+ if (override.hidden) {
+ node.hide = true;
Review Comment:
This likely erases the value the hide is supposed to protect: formly v6+
defaults `resetFieldOnHide` to true (we're on 7.1.0 with no override anywhere),
which removes a hidden field's value from the model when the field renders. The
surviving controls' first emission then carries the property object without the
hidden sub-field's value — and the write-back guard does not catch it, because
`isEmpty()` only knows undefined/null/"" and the emitted value is a non-empty
object. Net effect, if formly does strip on first build: a writer merely
opening the form writes the author's pinned value out of the operator. The
specs can't see this — they assert `hide` on the config and never render
formly. Suggest `node.resetOnHide = false` next to the `hide` (the per-field
switch; the global extra would also change the canvas's task-driven hides),
plus a quick check in the running app that the pinned value survives opening
the form.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
