recipe-app/next_steps_flutter.md

Next Steps: Flutter-migrering (Alternativ 3)

Relaterade dokument:

• flutter/README.md
• teknisk_beskrivning_flutter.md

1. Definiera malbild och scope forst

• Bestam vilka floden som maste vara parity i v1: login, receptlista, receptdetalj, inventarie, matsedel, profil.
• Satt tydlig definition of done per feature: UI, navigation, API, felhantering, loading states, auth-skydd.

2. Bygg gemensam app-shell innan fler sidor

• Stabil routingstruktur.
• Gemensam navigation (top/bottom/nav drawer).
• Auth-gate och logout-flode.
• Standardkomponenter for tomma lagen, felmeddelanden och laddning.

Det gor att varje ny sida gar snabbare och mer konsekvent.

3. Migrera i denna ordning (hogst affarsvarde forst)

• Auth: login, session, logout.
• Recept: lista -> detalj -> skapa/andra.
• Inventarie: lista -> skapa -> uppdatera -> forbrukning.
• Import-funktionen
• Matsedel.
• Profil/admin.

Ordningen minimerar blockerare eftersom recept + auth ofta anvands av allt annat.

4. Kor API-contract first per feature

• Verifiera exakt request/response mot backend innan UI putsas.
• Mappa datamodeller robust (null, typskillnader, fallback-falt).
• Lagg in central felhantering for 401/403/500 tidigt.

5. Satt enhetliga kvalitetsgrindar per migrerad feature

• Manuell testlista for kritiska scenarier.
• En liten smoke-test efter varje deploy.
• Kontroll att web + mobilanpassning fungerar (utan web-specifika genvagar).

6. Leverera i korta iterationer

• 1 feature at gangen till testmiljo.
• Demo + snabb feedback.
• Justera innan nasta feature.

Det minskar risken att du bygger fel saker for langt.

7. Avveckla gamla frontend stegvis

• Kor dubbel drift under en period.
• Peka en testdoman mot Flutter tills parity ar bekräftad.
• Flytta trafik gradvis nar karnfloden ar stabila.

Tumregel

• Sikta pa funktionell parity forst, pixel-perfect parity senare.
• Det ger snabbare nytta och farre regressionsproblem.