Aman-Mittal opened a new issue, #548: URL: https://github.com/apache/fineract-backoffice-ui/issues/548
Found while broadening the e2e coverage for #541. Two distinct defects in the same markup, both **pre-existing** and neither addressed by the #546/#547 fix. ## 1. A picker created after the first render never binds `floating-rate-form.component.ts` renders its date controls inside `@for (period of periods(); track $index)`, so they are created when the user clicks **Add Period**, not with the page. `ion-datetime-button` resolves its target `ion-datetime` exactly once, in `componentWillLoad`, through a global `getElementById`, and gives up for good when that lookup misses. The button and the `ion-modal[keepContentsMounted]` that holds its picker are created in the same change-detection pass, and the modal's contents are not in the DOM yet when the button initializes. The control renders blank and never opens. Unlike #541 this needs no revisit — it fails on the **first** visit, as soon as a period is added. `createPickersReady()` does not help here. It gates the initial render, and by the time a row is added the flag is already `true`, so the new row's button is created immediately alongside its modal. Verified: - with the `@if (pickersReady())` wrapper removed (the pre-fix shape), the picker fails identically — so this is not a regression from #547, just a case that fix does not reach - moving `<ion-modal>` before `<ion-datetime-button>` in the row does not help either; the modal's contents still are not in the DOM in that pass A per-instance deferral is needed — something that defers each button relative to its *own* creation rather than the page's, which likely means a small wrapper component owning the button, modal and picker together. ## 2. Rows share a single picker ID Within that same `@for`, the ID is a constant: ```html <ion-datetime-button datetime="periodfromDate-picker"></ion-datetime-button> ... <ion-datetime id="periodfromDate-picker" data-testid="periodfromDate-picker" ...> ``` Two rate periods therefore put two elements with `id="periodfromDate-picker"` in the document. `getElementById` returns the first, so every row's button points at the first row's picker — editing period 2's date would edit period 1's. This is the ID-collision problem discussed in #544, in a place where it actually bites rather than staying latent. The ID needs to vary per row. ## Reproduce 1. Go to `/products/floating-rates/create` 2. Click **Add Period** 3. The From Date control renders blank and does not open 4. Add a second period — both rows' controls target the same picker ## Coverage `e2e/date-picker-revisit.spec.ts` covers this page with `test.fail()`, so the suite asserts the bug is still present and turns red when it is fixed, prompting removal of the marker. Other components rendering pickers inside `@for`/`@if` blocks should be audited for the same shape. -- 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]
