FTDT — Blazor UI Migration Plan

Implementation roadmap for migrating the remaining FTDT screens from XAML to the Figma-driven Blazor design. Includes per-task status tracking, open questions, and strategy for decomposing the CA duty period monolith.

WI-1908 · Figma file owEYzHf7FrHRvWC2u82UOl · 8 screens — dashboard 4535:14038 · op-type 4535:14386 · duty periods 4544:5877 · archived 4575:9452 · add unaugmented 4535:14179 · add segment 4555:6566 · add rest 4603:13187 · add note 4603:13348 · duty period card master 4617:13876 · Branch feat/AB1908-ftdt-ui-01 · Created 2026-06-30

Dashboard · 4535:14038

Op Type Select · 4535:14386

Duty Periods · 4544:5877

Archived · 4575:9452

Add Unaugmented · 4535:14179

Add Flight Segment · 4555:6566

Add Rest · 4603:13187

Add Note · 4603:13348

DP Card (3 variants) · 4617:13876

1 · Screen inventory

2 · Implementation phases

Phases 2–4 are independent and can proceed in parallel once Phase 1 wiring is in place. Phase 5 depends on Phase 1. Phase 6 extends Phase 5. Phase 7 is last.

The card is the hub — every subsequent form screen routes from here. The collapsed/expanded/delete variants are fully defined in Figma 4617:13876.

Full-screen form matching Figma 4555:6566. XAML equivalent: FTDTDutyDetailsPage (modal). Figma renders as a full page with standard nav bar — target is full-screen. → OQ-2

Full-screen form matching Figma 4603:13187. XAML equivalent: rest section of FTDTSplitDutyPeriodPage and CA rest rows.

Minimal full-screen form matching Figma 4603:13348. Text area + single CTA.

The most complex phase. XAML: FTDTCADutyPeriodDetailsPage (1,437 lines) + FTDTDutyPeriodBasePage (707 lines). Architecture is resolved in Section 4 — use the RenderFragment shell pattern. Phase 5 targets the MVP edit form (shared fields + wired navigation); Phase 6 adds op-type-specific sections.

Extends Phase 5 shell with op-type-specific sections. Each variant is a focused Razor component injected as VariantInputs.

The new form pages (Phases 2–4, 6) introduce a two-column field row pattern not yet in ftdt.css. The existing .ftdt-field / .ftdt-field-label / .ftdt-field-input classes cover single-column fields. These additions are needed before Phases 2–4 are styled.

3 · Open questions

4 · CA monolith decomposition strategy

The problem

The XAML implementation has two layers of complexity to migrate:

• US template system — FTDTDutyPeriodBasePage.xaml (707 lines) uses a ControlTemplate with a ContentPresenter so that US op-type pages (UnAugmented, Augmented, SplitDuty) each inject their variant-specific input section into a shared layout shell. Clean separation.
• CA monolith — FTDTCADutyPeriodDetailsPage.xaml (1,437 lines) puts all CA operation types (UnAugmented, Augmented, SplitDuty, Reserve variants, SPO, DayVFR) into a single file with ~25 IsVisible-gated sections. No structural separation.

Blazor ContentPresenter equivalent: RenderFragment

RenderFragment is the direct Blazor equivalent of XAML ContentPresenter. A shell component declares it as a parameter; callers inject their variant markup as child content.

<!-- FTDTDutyPeriodShell.razor — the ContentPresenter equivalent -->
@code {
    [Parameter, EditorRequired] public RenderFragment VariantInputs { get; set; } = default!;
    [Parameter, EditorRequired] public DutyPeriod DutyPeriod { get; set; } = default!;
    [Parameter] public EventCallback OnSave { get; set; }
    [Parameter] public EventCallback OnDelete { get; set; }
    [Parameter] public EventCallback OnConclude { get; set; }
    [Parameter] public string Title { get; set; } = "Duty Period";
}

<div class="ftdt-page">
    <div class="ftdt-nav-controls">
        <button class="ftdt-nav-back" @onclick="GoBack"></button>
        <div class="ftdt-nav-title">@Title</div>
    </div>
    <div class="ftdt-scroll">
        <FTDTCommonInputs DutyPeriod="DutyPeriod" />    <!-- shared: date/TZ/segments/acclimated -->
        @VariantInputs                                      <!-- ContentPresenter slot -->
        <FTDTComputedSection DutyPeriod="DutyPeriod" />   <!-- shared: Max DP + Ends -->
    </div>
    <div class="ftdt-cta">
        <button class="alpa-btn" @onclick="OnSave">SAVE</button>
        <button @onclick="OnConclude">CONCLUDE</button>
    </div>
</div>

A caller page (e.g. /ftdt/duty-period?scope=CA) injects the CA-specific fragment:

<FTDTDutyPeriodShell DutyPeriod="_dp" Title="Duty Period" OnSave="SaveAsync" OnConclude="ConcludeAsync">
    <VariantInputs>
        <FTDTCADutyPeriodInputs DutyPeriod="(DutyPeriod_CAN_UnAugmented)_dp"
                                OnChanged="HandleChanged" />
    </VariantInputs>
</FTDTDutyPeriodShell>

Three options evaluated

Decision: Hybrid B + A — RenderFragment shell with focused sub-components

Target file structure

Data sharing pattern

All components follow the existing project convention — no deviations:

// Every variant and sub-component uses this signature:
[Parameter, EditorRequired] public DutyPeriod_CAN_UnAugmented DutyPeriod { get; set; } = default!;
[Parameter] public EventCallback<DutyPeriod> OnChanged { get; set; }

// Mutation pattern (same as RestRulesInputs, PositioningInput):
private async Task SetAcclimated(bool value)
{
    DutyPeriod.Acclimated = value;
    await OnChanged.InvokeAsync(DutyPeriod);
}

Related: ftdt-screen-data-gap.html (data layer analysis) · screen-mapping.html (component inventory) · WI-1908 · Branch feat/AB1908-ftdt-ui-01