Aman-Mittal commented on PR #544:
URL:
https://github.com/apache/fineract-backoffice-ui/pull/544#issuecomment-5644785381
Thanks for picking this up. The instinct to make picker IDs unique is
reasonable, but I reproduced #541 in a real browser and tested this branch's
approach against it — it doesn't fix the bug. Sharing the evidence, because it
points somewhere different than the PR description assumes.
Repro: log in, create a client through the wizard, then start a second
create with a different legal form, and inspect the `ion-datetime-button`
elements on step 2.
**1. There are no duplicate IDs at the point of failure.**
On `main`, when the second form fails, the document contains exactly one
`app-client-form` and one of each picker:
```
datetime ids in document: ["submittedOnDate-picker", "activationDate-picker"]
error: [ion-datetime-button] - No ion-datetime instance found for ID
'submittedOnDate-picker'
```
The previous form is fully destroyed before the new one mounts, so nothing
collides. The cause is ordering, not collision: `ion-datetime-button` resolves
its target exactly once in `componentWillLoad` via `document.getElementById`,
and gives up permanently if that lookup misses. On a repeat visit the button
initializes *before* `ion-modal`'s `keepContentsMounted` content is in the DOM.
The first visit works only because the lazy chunk load happens to delay the
button past that point.
**2. With this branch's approach applied, the pickers are still broken.**
Same repro, unique IDs in place — the buttons render blank and stay unusable:
```
buttons:
[{"datetime":"submittedOnDate-picker-2","shadowText":"","resolves":true}, ...]
error: [ion-datetime-button] - An ID associated with an ion-datetime
instance is required to function properly.
```
Moving `datetime="…"` to `[datetime]="…"` means Angular sets the property
during change detection, so at `componentWillLoad` the value is still undefined
and the button bails on the *first* guard instead of the second. `resolves:
true` confirms the ID pairing itself is correct — the button simply never
binds. This is worse for triage than the original: the error string from the
issue no longer appears, so it reads as fixed while the user still cannot enter
a date.
**3. The added test cannot catch this.**
It asserts that six generated ID strings are distinct and that the bound
properties match. No Ionic element initializes in that environment, so it
passes whether or not the picker works. The green E2E run doesn't cover it
either — no existing spec opens the create form twice.
**What does work**
Leaving the existing hardcoded IDs alone and deferring the button by one
render, so the `ion-datetime` is in the DOM before the button initializes — a
`pickersReady` signal set from `afterNextRender`, with the
`ion-datetime-button` elements behind `@if (pickersReady())`. Verified against
the same repro:
```
buttons: [{"datetime":"submittedOnDate-picker","shadowText":"Sep 12,
2026","resolves":true}, ...]
```
Zero Ionic errors. That's the minimal change that addresses the actual cause.
Unique IDs are still worth doing on their own merits — 97
`ion-datetime-button` usages across 62 components reuse a small pool of names
(`transactionDate-picker` in 8 files, `submittedOnDate-picker` in 7), so two
such pages alive at once would collide. But that is a separate,
currently-latent problem, not this one, and it would be better as its own
change with a test that can actually fail.
Since this one is a blocker I'll push a fix along the lines above shortly.
Happy to have you take the unique-ID work as a follow-up if you're interested —
and a regression spec that opens the create form twice would be a genuinely
valuable addition either way.
--
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]
