aglinxinyuan opened a new pull request, #7787:
URL: https://github.com/apache/texera/pull/7787
### What changes were proposed in this PR?
Three template fixes. The first is a real user-facing bug; the other two are
safe no-ops.
**1. The Hugging Face model field never showed validation errors.**
```diff
- *ngIf="props.showError && formControl.errors">
+ *ngIf="showError && formControl.errors">
```
`showError` is a getter on `@ngx-formly`'s `FieldType`
(`templates/field.type.d.ts:25`), a sibling of `get props()` — **not** a
`props` field. The only other `showError` declarations in formly are predicate
*functions* (`FormlyFormOptions.showError`, `FormlyConfig.extras.showError`).
So `props.showError` was permanently `undefined` and
`<formly-validation-message>` could never render. It typechecked only because
formly's props type carries an index signature, which is why it went unnoticed.
The two working siblings in this codebase already use the bare getter:
`common/formly/object.type.ts:23` and `multischema.type.ts:24`.
**2. `console-frame.component.html`: removed a shadowed duplicate template
pair.** `#checkedTemplate` was declared at lines 36 *and* 53,
`#unCheckedTemplate` at 41 *and* 58, with both `nz-switch`es referencing the
same two names. First declaration wins, so the second pair was unreachable —
and both bodies were byte-identical.
**3. `dataset-detail.component.html`: removed a redundant conjunct.** Line
585's `userHasWriteAccess() &&` is dominated by the enclosing `nz-collapse`
(line 452), already gated on `userDatasetAccessLevel === "WRITE"` — exactly
what that method returns (`dataset-detail.component.ts:560-562`). Both read the
same field, so they cannot disagree even at runtime.
### The fix is pinned by a test that fails without it
A `validation message` describe in `hugging-face.component.spec.ts` asserts
both directions. With the template reverted to `props.showError`, that test
fails (**1 failed | 86 passed**); with the fix, **87 pass**.
The sharpest detail: on the unfixed template,
`expect(component.showError).toBe(true)` **passes** on the line above while the
DOM query returns `null`. The getter says to show the error and the template
ignores it — which is precisely the bug, and precisely why no existing test
caught it.
### One fixture change was required, and it is fixture infidelity rather
than fallout
Applying the fix initially failed 78 tests with `TypeError:
this.options.showError is not a function`, because the spec's field literals
supplied `options: { detectChanges: vi.fn() }` only. In production `FormlyForm`
always fills in `options.showError` and `options.fieldChanges`. Those fixtures
were therefore modelling a state formly never produces. Added one
`buildFormlyOptions()` helper and used it at the six existing `options:`
literals; no test asserted on `options.detectChanges`, so behaviour is
unchanged.
### Items 2 and 3 are verified as behaviour-preserving
For **console-frame**, rather than assume the duplicate was inert, the
existing settings-dropdown test was temporarily instrumented to dump
`innerHTML` of *both* switches in both on and off states, run against the
original and the fixed template, and diffed. The only delta is Angular's
generated style-scope id (`_ngcontent-a-c3896271133` →
`_ngcontent-a-c2948443161`), a template-content hash stamped consistently on
DOM and CSS. Normalising it, the rendered on/off content is identical. The
instrumentation was reverted and is not in this diff.
For **dataset-detail**, the suite passes 173/173 **both with and without**
the change — no test outcome moves, which is what makes it a safe cleanup
rather than a behaviour change. The one case that looked risky (`offers the
creator only once there is something to commit`) uses the merging render
helper, so `userDatasetAccessLevel` stays `"WRITE"` across its second render.
### Verification
- `hugging-face` + `console-frame` + `dataset-detail` in one run: **288
passed (288)**.
- `operator-property-edit-frame` + `formly-config` as regression cover for
the formly options path: **207 passed | 1 skipped**.
- `npx ng build` exits 0 with `Browser application bundle generation
complete` and zero `[ERROR]` lines — worth running here because `ng test` and
`tsc --noEmit` both miss Angular template diagnostics.
- `yarn format:ci` exits 0.
### Any related issues, documentation, discussions?
Closes #7786
### How was this PR tested?
```
npx ng test --watch=false --include="**/hugging-face.component.spec.ts"
--include="**/console-frame.component.spec.ts"
--include="**/dataset-detail.component.spec.ts"
```
```
Test Files 3 passed (3)
Tests 288 passed (288)
```
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)
--
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]
