Przepisy UI dla React Native i Flutter

Rozwój mobilny z narzędziami AI jest trudny, ponieważ zachowanie specyficzne dla platformy ma znaczenie. Komponent działający w podglądzie webowym zawali się na prawdziwym urządzeniu, jeśli używa nieobsługiwanych API. Te przepisy generują kod uwzględniający różnice iOS/Android, obsługują bezpieczne obszary, respektują konwencje platformy i prawidłowo używają modułów natywnych.

Co z tego wyniesiesz

Przepisy komponentów React Native z obsługą specyficzną dla platformy
Przepisy widgetów Flutter z designem Material i Cupertino
Wzorce nawigacji dla obu frameworków z deep linkingiem
Przepisy wydajności dla list, animacji i ładowania obrazów

Przepis 1: Adaptacyjna nawigacja platformowa (React Native)

Scenariusz: Twoja aplikacja potrzebuje nawigacji zakładkowej na iOS i nawigacji szufladowej na Android, zgodnie z konwencjami każdej platformy.

Rusztowanie nawigacji dotyka wielu plików naraz — nawigatora, każdego ekranu, typów parametrów i konfiguracji deep linkingu — więc narzędzie, po które sięgasz, zmienia sposób, w jaki nim sterujesz.

Otwórz folder nawigacji i użyj trybu agenta, aby jednym przebiegiem edytował RootNavigator.tsx, pliki ekranów i linking.ts. Zostaw checkpoint przed zaakceptowaniem — nawigatory rozdzielone na platformy to klasyczny przypadek, gdzie AI poprawnie obsługuje gałąź iOS, a po cichu psuje domyślne wartości headerShown dla Androida, więc chcesz mieć rollback jednym kliknięciem.

Uruchom w trybie headless, aby napisał nawigator, ekrany i RootStackParamList w jednej turze: claude -p "build the platform-adaptive navigator described in linking.ts and wire all four screens". Dodaj hook PostToolUse na *.tsx, który uruchamia tsc --noEmit, aby pominięty typ parametru zawiódł natychmiast, a nie w runtime.

Utwórz system nawigacji adaptacyjny dla platformy używając React Navigation v7. (1) Zdefiniuj RootNavigator wykrywający platformę i renderujący BottomTabNavigator na iOS lub DrawerNavigator na Android. (2) Oba zawierają te same 4 ekrany: Home, Search, Notifications, Profile. (3) Dla iOS: użyj @react-navigation/bottom-tabs z ikonami SF Symbols, haptycznym feedbackiem przy naciśnięciu zakładki i pływającym przyciskiem akcji nad paskiem zakładek. (4) Dla Android: użyj @react-navigation/drawer ze stylowaniem Material 3, nagłówkiem użytkownika z avatarem i separatorami sekcji. (5) Oba współdzielą te same ekrany stosu wewnątrz każdego elementu zakładki/szuflady. (6) Dodaj mapowanie deep linkingu URL typu myapp://profile/123 do ekranów z parametrami. (7) Obsługuj przycisk wstecz Android: najpierw pop zagnieżdżonego stosu, potwierdzenie wyjścia na root. Typuj wszystkie params z RootStackParamList. Napisz test weryfikujący rozwiązywanie deep linków.

Oczekiwany wynik: Nawigator root, zakładki iOS, szuflada Android, konfiguracja deep linkingu, typowane params i testy.

Przepis 2: System responsywnego layoutu (React Native)

Scenariusz: Twoja aplikacja musi działać na telefonach, tabletach i składanych urządzeniach z różnymi layoutami dla każdego punktu przerwania.

Utwórz system responsywnego layoutu. (1) Hook useResponsive() zwracający { width, height, breakpoint, isPhone, isTablet, isFoldable, orientation }. Punkty przerwania: phone (<600), tablet (600-1024), desktop (>1024). Wykrywaj składane przez API geometrii zawiasów. (2) Komponent ResponsiveGrid renderujący 1 kolumnę na telefonie, 2 na tablecie portrait, 3 na tablecie landscape używając FlatList numColumns. (3) ResponsiveStack renderujący dzieci pionowo na telefonie, poziomo na tablecie. (4) Layout MasterDetail: na telefonie pokaż listę, następnie nawiguj do szczegółów; na tablecie pokaż listę (1/3) i szczegóły (2/3) jednocześnie. (5) useScaledSize(baseSize) skalujący proporcjonalnie do szerokości ekranu względem bazy 375px. Testuj zmiany layoutu mockując Dimensions.

Oczekiwany wynik: Hook useResponsive, trzy komponenty layoutu, hook useScaledSize i testy.

Scenariusz: Twoja aplikacja Flutter potrzebuje brandowanego systemu designu działającego na iOS i Android.

Utwórz bibliotekę widgetów w lib/widgets/. (1) AppButton z wariantami (primary, secondary, outline, ghost, destructive), rozmiarami (sm, md, lg), spinnerem ładowania, stanem wyłączonym, opcjonalnymi ikonami. Używa Theme.of(context). Zaokrąglone rogi Cupertino na iOS, ripple Material na Android. (2) AppTextField z etykietą, tekstem pomocniczym, tekstem błędu, ikonami prefix/suffix, przełącznikiem obscure dla haseł. (3) AppCard z opcjonalnym nagłówkiem, ciałem, stopką, konfigurowalnym elevation. (4) AppAvatar z okrągłym obrazem, fallbackiem inicjałów, shimmerem ładowania, odznaką online/offline. (5) AppBottomSheet z uchwytem przeciągania, punktami przyciągania (half/full screen), dismissible. (6) Klasa AppTheme z metodami fabrycznymi light() i dark() definiującymi wszystkie tokeny. (7) Ekran showcase WidgetBook wyświetlający każdy wariant. Napisz testy widgetów dla każdego.

Oczekiwany wynik: Pięć plików widgetów, klasa motywu, widget book i testy widgetów.

Przepis 4: Wydajna lista feedu (React Native)

Scenariusz: Twój ekran feedu pokazuje 1000+ elementów z obrazami i zacina się przy przewijaniu. Pull-to-refresh czuje się opóźnione.

Oczekiwany wynik: Ekran feedu z FlashList, zmemoizowany FeedItem, ładowanie FastImage i test wydajności.

Przepis 5: Architektura offline-first (React Native)

Scenariusz: Twoja aplikacja serwisowa w terenie musi działać bez łączności. Użytkownicy wprowadzają dane offline i synchronizują się po połączeniu.

Silnik synchronizacji obejmuje modele, adapter, hooki i UI — a najtrudniejsza część to logika rozwiązywania konfliktów last-write-wins, którą łatwo subtelnie zepsuć. Sposób, w jaki to nadzorujesz, różni się w zależności od narzędzia.

Zbuduj to w trybie agenta w plikach modelu i adaptera, ale zrób checkpoint tuż przed krokiem adaptera synchronizacji i przejrzyj ten diff osobno — rozwiązywanie konfliktów to miejsce, gdzie AI po cichu gubi uzgadnianie syncStatus. Widok inline diff sprawia, że logikę porównywania timestampów łatwo skanuje się linijka po linijce.

Wygeneruj modele i adapter w trybie headless, a następnie uczyń logikę synchronizacji weryfikowalną: claude -p "write WatermelonDB sync tests: create offline, go online, assert last-write-wins" i dodaj hook PostToolUse uruchamiający test offline-then-online przy każdej edycji sync/*.ts. Chcesz, aby ścieżka konfliktu była pokryta testem, a nie nadzieją.

Zaimplementuj offline-first z WatermelonDB. (1) Zdefiniuj modele: WorkOrder (id, title, status, assignedTo, description, syncStatus), Photo (id, workOrderId, uri, caption, syncStatus), Note (id, workOrderId, content, syncStatus). (2) Adapter synchronizacji: przy zmianie łączności (NetInfo), porównaj timestampy, wypchnij lokalne zmiany (last-write-wins), pociągnij zmiany serwera, oznacz zsynchronizowane. (3) Kolejkuj mutacje offline z kolejką synchronizacji. Pokazuj badge “oczekująca synchronizacja” na niezsynchronizowanych elementach. (4) Zdjęcia: przechowuj lokalnie w dokumentach aplikacji, uploaduj podczas synchronizacji, zamień URI po uploadzie. (5) Hook useNetworkStatus(): { isOnline, pendingSync, lastSyncedAt, syncNow() }. (6) Banner offline pokazujący liczbę oczekujących zmian. Testuj: twórz offline, przejdź online, weryfikuj synchronizację.

Oczekiwany wynik: Modele WatermelonDB, silnik synchronizacji, hooki sieciowe, banner offline i testy synchronizacji.

Przepis 6: Zarządzanie stanem z Riverpod (Flutter)

Scenariusz: Twoja aplikacja Flutter używa wszędzie Provider. Migruj do Riverpod dla testowalności i bezpieczeństwa typów.

Oczekiwany wynik: Trzy pliki providerów, integracja drzewa widgetów i testy widgetów z mock overrides.

Przepis 7: Integracja modułu natywnego (React Native)

Scenariusz: Potrzebujesz czytania tagów NFC nieobsługiwanego przez istniejące biblioteki.

Użyj trybu agenta, aby jedną edycją wygenerował NativeNfc.ts, klasę Swift i klasę Kotlin, a następnie trzymaj symulator iOS i emulator Androida w podzielonych panelach, by mieć oba mosty na oku. Ponieważ zmiany natywne nie podlegają hot-reload, zaakceptuj checkpoint i wyzwól pełny rebuild, zamiast oczekiwać, że Fast Refresh je podchwyci.

Wygeneruj .swift, .kt i .ts w jednym przebiegu headless, a następnie wepnij rebuild w hook, aby nigdy nie testować nieaktualnych binarek: dodaj hook PostToolUse dopasowujący *.swift i *.kt, który uruchamia npx expo prebuild --clean (lub cd ios && pod install dla czystego RN). Przepływ zorientowany na terminal sprawia, że natywny rebuild jest o jedno polecenie od edycji.

Oczekiwany wynik: Specyfikacja TurboModule, iOS Swift, Android Kotlin, hook useNfc i testy.

Przepis 8: Animacje przesuwania kart (React Native)

Scenariusz: Potrzebujesz płynnych animacji 60fps dla stosu kart do przesuwania.

Zbuduj stos kart do przesuwania z react-native-reanimated v3 i react-native-gesture-handler. (1) SwipeableCard używający Gesture.Pan() mapującego translationX na rotację i opacity nakładki like/nope. (2) Przy zwolnieniu: jeśli poza progiem (150px), animuj poza ekran. W przeciwnym razie sprężynuj z powrotem do środka. Użyj withSpring dla powrotu, withTiming dla wyjścia. (3) CardStack renderujący górne 3 karty z przesunięciami głębokości scale/translateY. Odrzucona górna karta animuje następną w górę. (4) Pionowe przesunięcie w górę dla “super like” z animacją scale+rotate. (5) Przycisk cofnij animujący ostatnią kartę z powrotem. (6) Wszystkie animacje na wątku UI przez useSharedValue i useAnimatedStyle. (7) Haptyczny feedback przy progu przesuwania. Testuj wykrywanie gestów z mock events.

Oczekiwany wynik: SwipeableCard, CardStack, logika cofnij, integracja haptyczna i testy gestów.

Przepis 9: Adaptacyjny design platformowy (Flutter)

Scenariusz: Twoja aplikacja Flutter wygląda identycznie na iOS i Android. Użytkownicy oczekują natywnych wzorców platformy.

Oczekiwany wynik: Sześć adaptacyjnych widgetów, PlatformHelper, klasa bazowa strony i testy międzyplatformowe.

Przepis 10: Powiadomienia push (React Native)

Scenariusz: Twoja aplikacja potrzebuje powiadomień push na obu platformach z deep linkingiem do konkretnych ekranów.

Oczekiwany wynik: Konfiguracja Firebase, setup, handlery, parser deep linków, hook i testy.

Przepis 11: Nawigacja GoRouter (Flutter)

Scenariusz: Twoja nawigacja to rozproszone wywołania Navigator.push bez bezpieczeństwa typów. Potrzebujesz deklaratywnego routingu.

Oczekiwany wynik: Konfiguracja routera, typowane helpery, konfiguracja deep linków, guardy i testy nawigacji.

Przepis 12: Przygotowanie do zgłoszenia do sklepu aplikacji

Scenariusz: Twoja aplikacja jest kompletna funkcjonalnie. Przygotuj się do zgłoszenia do App Store i Play Store.

Przygotowanie do zgłoszenia to głównie edycje konfiguracji plus skrypt weryfikacyjny, więc to przepis, w którym skryptowany, powtarzalny przebieg opłaca się najbardziej.

Pozwól trybowi agenta edytować Info.plist i build.gradle razem, a następnie uruchom skrypt weryfikacji buildu ze zintegrowanego terminala. Wizualny diff przydaje się do wyłapania błędnego versionCode lub zabłąkanego uprawnienia debug, zanim wyślesz.

To najlepsze dopasowanie do skryptowania headless: niech wygeneruje prepare-release.sh, który podbija wersje, buduje obie platformy i greppuje bundle release pod kątem console.log i zależności debug — a potem uruchom go w CI, aby każdy kandydat na release był weryfikowany tak samo. Krok weryfikacji buildu to dokładnie ten rodzaj powtarzalnej bramki, do której stworzono CLI.

Odpal przygotowanie release jako zadanie Cloud ze świeżego worktree i niech otworzy PR ze zmianami konfiguracji plus RELEASE_CHECKLIST.md. Recenzent zatwierdza podbicia wersji i konfigurację podpisywania na PR, zanim cokolwiek trafi do sklepów.

Przygotuj tę aplikację React Native do zgłoszenia do sklepu. (1) iOS Info.plist: Wszystkie opisy użycia prywatności, bundle identifier, wersja, numer buildu, ATS włączony, możliwości urządzenia. (2) Android build.gradle: applicationId, versionCode/Name, minSdkVersion 24, targetSdkVersion 35, podpisywanie release, ProGuard/R8. (3) Obie: Generuj ikony aplikacji we wszystkich rozmiarach ze źródła 1024x1024. Konfiguruj ekrany splash. (4) Skrypt weryfikacji buildu: buduje release dla obu platform, weryfikuje brak console.log w produkcji, brak zależności debug w release. (5) Generuj RELEASE_CHECKLIST.md: testuj na prawdziwych urządzeniach, weryfikuj deep linki, sprawdź analitykę, testuj powiadomienia push, weryfikuj zakupy in-app, zrób screenshoty wszystkich ekranów.

Oczekiwany wynik: Zaktualizowane konfiguracje natywne, skrypt ikon, skrypt weryfikacji buildu i checklist release.

Gdy przepisy nie działają

Co dalej

Przepisy Expo dla wzorców zarządzanego workflow
Przepisy Flutter dla głębszych workflow Flutter
Przepisy React Native dla zaawansowanych wzorców React Native