Mark U-11 as won't-do after second failed attempt
Second attempt with all three suspected fixes applied (materialised Items field, static readonly identity delegates, Autocomplete downgraded from Both to List) still froze the UI on Home. FluentCombobox in Fluent UI Blazor 4.11.8 is not viable inside a per-row @foreach on a Blazor Server page independent of parameter stability. Native <input list> stays. Record both attempts and the fallback options for anyone who wants to try again later. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
parent
0432a2db75
commit
acc8b14c06
1 changed files with 5 additions and 1 deletions
|
|
@ -177,7 +177,11 @@ Split into two PRs on delivery because the header path touches ~15 pages.
|
|||
### Phase 5 — Home page split
|
||||
|
||||
- **U-10** Extract `<StatementImport />` and `<PendingBookings />` components. Home stacks them.
|
||||
- **U-11** ~~Replace the Home `<input list="texts">` + `<datalist>` with `FluentAutocomplete` so the autocomplete UI is uniform with the split dialog.~~ **Attempted with `FluentCombobox` in `ceef2c1`, reverted in `2522274` because the UI became unresponsive.** Root cause: rendered per row inside a `@foreach`, three parameters were re-created on every render — `sortedBookingTexts` as a computed `.OrderBy(...)` getter (fresh `IEnumerable` each access), `OptionText="@(t => t)"` and `OptionValue="@(t => t)"` inline lambdas (fresh delegate each render), plus `Autocomplete=Both` which does JS interop per keystroke. Combined, N pending bookings flooded the SignalR circuit with render + interop messages until the whole UI froze. Retry needs: materialise `sortedBookingTexts` to a real field populated in `LoadDataAsync`, extract the identity lambdas to `static readonly Func<string, string>` fields, and test in the browser with a realistic pending-bookings count before merging.
|
||||
- **U-11** ~~Replace the Home `<input list="texts">` + `<datalist>` with `FluentAutocomplete`.~~ **Won't do.** Two attempts, both broke the UI:
|
||||
- Attempt 1 (`ceef2c1`, reverted in `2522274`): `FluentCombobox` with `Autocomplete=Both`, a computed-getter `Items` source (fresh `IEnumerable` per access), and inline `@(t => t)` delegates. Suspected root cause: per-render parameter churn triggering re-init inside every row's Combobox, flooding the SignalR circuit.
|
||||
- Attempt 2 (branch `refactor/pr-u11b-retry`, never merged): all three suspected causes fixed — `sortedBookingTexts` materialised into a real field populated in `LoadDataAsync`, `OptionText`/`OptionValue` extracted to `static readonly Func<string, string>`, `Autocomplete` downgraded to `List`. Same UI lockup.
|
||||
|
||||
Conclusion: `FluentCombobox` in Fluent UI Blazor 4.11.8 is not usable inside a per-row `@foreach` on a Blazor Server page with more than a handful of rows, independent of parameter stability. The native `<input list>` + `<datalist>` stays. If someone wants Fluent styling later, options that avoid the per-row Fluent component are: (a) a lightly-styled `<input>` wrapped in Fluent's CSS classes; (b) rendering the suggestions as a single shared component with a `TextChanged` callback that updates the row's `Text` field.
|
||||
|
||||
### Phase 6 — Report componentization
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue