React Native 0.87 face din Strict TypeScript API varianta implicită. Iată ordinea de actualizare.

React Native 0.87 a fost lansat pe 11 august și este cea mai importantă versiune cu schimbări majore pe care framework-ul a avut-o de ceva vreme. Titlul principal este că Strict TypeScript API, care a apărut ca previzualizare opțională în 0.80, este acum valoarea implicită pentru orice proiect. Alături de aceasta: suport experimental Swift Package Manager pe iOS, suport nativ Android Gradle Plugin 9 și un prag mai ridicat al lanțului de instrumente. Node.js 22.13+, Kotlin 2.0+ cu 2.2 inclus și compileSdk ridicat la 37.

Dacă aplicația ta este încă pe o versiune mai veche, aceasta nu este o actualizare de rutină. Echipa React Native o numește cel mai important pas spre 1.0 din ultimii ani, iar lista de eliminări confirmă asta.

Ce schimbă efectiv Strict API

Până acum, tipurile TypeScript ale React Native erau menținute manual, separat de sursă, astfel că au divergut. Tipurile promiteau lucruri pe care codul nu le făcea, iar căile fișierelor interne scăpau ca și cum ar fi fost publice. Strict API rezolvă asta prin generarea tipurilor direct din sursă și limitând contractul public la ceea ce react-native exportă la rădăcina sa.

Consecința practică: importurile adânci de tipul react-native/Libraries/... sunt acum erori de tip. Dacă ai ajuns vreodată la o cale internă pentru a lua ceva ce nu era exportat oficial, acel cod nu va mai trece verificarea de tip. Tipurile de ref se schimbă și ele. Componentele built-in sunt acum tipizate ca funcții, nu ca clase, deci useRef<View>() nu mai funcționează. Fiecare componentă primește în schimb un tip de instanță dedicat, precum ViewInstance și TextInputInstance.

Există o ieșire de urgență temporară. Poți reveni la tipurile manuale vechi cu customConditions: ["react-native-legacy-deep-imports"] în tsconfig.json. Tratează asta ca pe o marjă de respirație, nu ca o destinație. Echipa a declarat că opțiunea de ieșire va dispărea într-o versiune viitoare, deci migrarea vine indiferent dacă o faci acum sau mai târziu.

Un detaliu care te va scuti de o după-amiază neplăcută: Strict API afectează doar analiza TypeScript a propriului proiect, limitată de tsconfig.json, și se bazează pe activarea skipLibCheck. Configurația TypeScript React Native o activează implicit. Dacă ai dezactivat skipLibCheck, reactivează-l înainte de a începe, altfel vei fi copleșit de erori din fișierele .d.ts ale unor terți pe care nu le poți remedia.

Eliminările care afectează aplicațiile mature

Strict API primește titlul principal, dar eliminările silențioase sunt cele care strică codebazele mai vechi. Câteva pe care le-am căuta mai întâi:

• InteractionManager a dispărut. Mută munca amânată la requestIdleCallback.
• TurboModules sunt acum mereu active. Flag-ul de funcționalitate useTurboModules a fost eliminat, deci dacă îl mai comutai, acel cod trebuie să dispară.
• useColorScheme() returnează ColorSchemeName | null și nu mai returnează 'unspecified'. Orice ramură care gestionează acel șir este acum moartă.
• Proprietățile deprecate ale StatusBar (backgroundColor, translucent) și setterele lor sunt eliminate, împreună cu proprietatea animated a Modal și suportul boolean pentru keyboardShouldPersistTaps al ScrollView.

Niciuna dintre acestea nu este dificilă în sine. Problema este să le găsești pe toate într-o aplicație mare înainte ca ele să apară la runtime sau într-un CI eșuat.

SwiftPM și AGP 9: reale, dar nu urgente

Schimbările pe partea nativă sunt cele care ne interesează cel mai mult din munca noastră mobilă. Suportul Swift Package Manager înseamnă că poți în sfârșit construi un proiect iOS fără Ruby, Bundler sau CocoaPods în lanț. Este experimental și opțional, CocoaPods rămâne calea implicită și suportată, și consumă aceleași XCFrameworks precompilate pe care React Native le livrează deja. În proiectele noastre iOS native, lanțul de instrumente CocoaPods a fost o sursă fiabilă de eșecuri CI de tip „funcționează pe mașina mea”, deci o cale care este doar Xcode este binevenită. Nu am muta o compilație de producție pe ea încă, dar merită testat pe o ramură pentru a vedea cum gestionează graful de dependențe.

Pe Android, 0.87 este prima versiune cu suport AGP 9. Recomandarea propriei echipe este revelatoare: dezactivează Kotlin-ul built-in și noul DSL al AGP 9 pentru moment, setând android.builtInKotlin=false și android.newDsl=false în gradle.properties. Aceste opțiuni de dezactivare sunt menite să dispară în jurul AGP 10. Cu alte cuvinte, Google și echipa React Native încă stabilizează asta, iar calea sancționată este deliberat conservatoare. Din munca noastră cu Kotlin și Jetpack Compose, am învățat să respectăm acest tip de îndrumare. Adoptarea unui plugin Gradle major în săptămâna lansării sale, cu setările implicite pe care înșiși mentenanții te sfătuiesc să le dezactivezi, este cum pierzi un sprint din cauza erorilor de compilare.

Ordinea de actualizare pe care am folosi-o

Iată secvența pe care am rula-o pentru o aplicație reală, cel mai mic risc primul:

1. Actualizează lanțul de instrumente înainte de a atinge React Native. Treci la Node.js 22.13+, Kotlin 2.0+ și compileSdk 37 ca pași separați, verificabili. Dacă ceva se strică aici, vrei să știi că a fost lanțul de instrumente, nu framework-ul.
2. Actualizează la 0.87 cu opțiunea de dezactivare a tipurilor vechi încă activă. Asta izolează eliminările runtime — schimbările InteractionManager și StatusBar — de migrarea tipurilor, astfel încât depanezi un lucru pe rând.
3. Activează Strict API la final. Elimină opțiunea de dezactivare, rulează tsc și lucrează prin erorile de import adânc și tip de ref ca o trecere dedicată. Aceasta este modificarea care cel mai probabil va atinge codul partajat și bibliotecile terțe, deci dă-i propriul PR.

Partea acționabilă pe care o poți face astăzi, înainte de orice actualizare: rulează o căutare la nivel de proiect pentru react-native/Libraries/ și fiecare import adânc în interioarele React Native. Acel singur grep îți spune cât de multă muncă Strict API te așteaptă efectiv. Dacă numărul este zero, această actualizare este în mare parte mecanică. Dacă este în sute, ai o conversație de planificare, nu o actualizare de vineri după-amiază.

Există o lecție mai largă aici pe care o vedem atât în web, cât și în mobil. Când construim aplicații cloud-native pentru clienți enterprise, framework-urile care supraviețuiesc sunt cele care în cele din urmă trasează o graniță fermă în jurul API-ului lor public și o respectă. React Native a derivat ani de zile deoarece tipurile și sursa erau două lucruri diferite menținute manual. Această versiune este corectarea. Doare o dată, și apoi refactorizările interne nu mai sunt schimbările tale majore. Este un compromis care merită făcut, iar echipele enterprise elvețiene cu care lucrăm, unde o schimbare majoră neplanificată poate bloca aprobarea de conformitate, vor prefera întotdeauna un API previzibil unuia convenabil. Poți vedea tipul de muncă mobilă și de development pe care o facem în proiecte native și cross-platform.

Dacă un audit „care dintre importurile noastre vor deveni erori de tip” sună familiar, haideți să discutăm. Ajutăm echipele să planifice actualizări de framework care nu se transformă în yak-shave-uri de o lună.