React Native du point de vue d'un développeur mobile

L'article s'adresse aux développeurs iOS et Android qui sont déjà assez bien informés dans leur domaine et regardent React Native.

Lorsque j'ai découvert React Native pour la première fois, j'ai profité de l'occasion pour les développeurs Web d'envahir mon territoire ( absolument impossible! ) Et en même temps de gâter le bon fonctionnement du produit 60-fps sans crash. Et c'est arrivé. La fin. La vraie histoire s'est avérée plus longue.

Déni

JavaScript dans une application mobile? Seules quelques bibliothèques utilisant JavaScriptCore sur iOS me sont venues à l'esprit (ces mêmes bibliothèques représentaient 90% des plantages des applications dans lesquelles elles étaient utilisées) et des applications hybrides de «l'ancien modèle» (enfin, c'est atas).

Les applications hybrides ont montré de l'espoir jusqu'au moment où vous les essayez, après quoi vous commencez à les fuir tête baissée et autant que possible.

Rappelant les tentatives infructueuses d'apprendre Xamarin il y a 3 ans, j'ai rapidement abandonné l'idée d'utiliser React Native.

Il est à noter que j'ai toujours été heureux de percevoir de nouvelles façons d'écrire des applications natives (d'ObjC à Swift, de Java à Kotlin, d'Eclipse à Android Studio). Je suis engagé dans le développement iOS et Android comme passe-temps et professionnellement depuis de nombreuses années. Après être passé à une nouvelle langue (au sein du même système d'exploitation) ou IDE, je suis rarement revenu à la précédente. Il semblerait que React Native soit une prochaine étape logique, une autre nouvelle étape. Ou est-ce un pas en arrière?

La colère

Pourquoi devrais-je enseigner une version simplifiée alors que je sais déjà comment faire cela «pour de vrai»?!
Je devais encore trouver une réponse à cette question lorsque la société a décidé de repenser complètement l'une des applications (disponible à ce moment uniquement sur iOS) et de la publier sur Android.

Comment faire deux choses à la fois et écrire moins de code? Suggestions comme: un client léger, des bibliothèques C avec un appel du code Swift / Kotlin, React Native?

React Native semblait assez prometteur en raison de la possibilité de créer des bibliothèques et de les utiliser immédiatement sur trois plates-formes (iOS / android / web).

Enchères

Prometteur pour tout le monde, mais pas pour moi. Je n'étais certainement pas satisfait de ce virage. J'ai senti que j'étais au sommet de la capacité de développer iOS et Android, puis on m'a demandé de jeter toutes ces connaissances, comme si j'étais un nouveau diplômé et que j'avais 0. Je doutais même qu'avec React Native, vous pouviez créer un produit de qualité.

La dépression

Les doutes étaient raisonnables. Les principaux problèmes sont:

• une quantité décente de gouttes dans le cœur de React Native;
• des méthodes qui ne fonctionnent que sur une seule plate-forme (les quais indiquent qu'ils fonctionnent partout);
• description incomplète. Il suffit de regarder les quais du collecteur React Native .

Le principal problème caché: le blocage interne dans ma tête, qui m'a empêché de voir les avantages derrière un tas de inconvénients.

Acceptation

Et bien sûr, React Native n'est pas seulement un inconvénient. Il y a beaucoup de bien, il est écrit beaucoup plus facilement et fonctionne mieux que le même sur des plates-formes spécifiques.

Si nous éliminons les problèmes évidents, tels que les accidents et les maigres quais, voici des exemples de ce que j'ai dû affronter:

Javascript

Pas étonnant. C'est la première chose qui va de pair avec le sang, la sueur et les larmes.
Quand j'ai commencé à me remémorer mon expérience précédente en tant que développeur front-end (je travaillais sur des sites avant des applications mobiles), j'ai commencé avec le syndrome vietnamien: Johnny, JavaScript nous entoure!

Si vous décidez d'écrire des applications sur React Native, je vous recommande de suivre l'un des derniers cours JS. Ils n'ont pas besoin d'être React ou React Native.

Au cours des dernières années, avec la publication des normes ES6, ES7 et ES8, la façon dont vous écrivez le code a beaucoup changé.

Et il est devenu très personnel .

Contrôle statique

Dans les premiers mois, l'analyseur statique, qui est dans toutes les langues mobiles natives, fait très défaut.

Il existe divers utilitaires qui atténuent son absence, exécutant une partie des fonctions

Éléments de mise en page

Le plus grand défi sera ici pour les développeurs iOS débutants.

Ce défi est le manque d'un éditeur d'interface visuelle.

Tout se fait en code à l'aide du balisage JSX . Techniquement, ce balisage est facultatif, il permet de voir la hiérarchie des composants. Les développeurs Android seront à l'aise, notant les similitudes avec XML.

Dans le même temps, il y a une vue claire sur les vues et le potentiel de réutilisation.

Dans iOS, il y a l'un ou l'autre, selon la méthode à choisir (mise en page dans le code ou dans le générateur d'interface). Oui, ces deux problèmes peuvent être résolus, mais vous devez écrire une quantité décente de code.

React Native n'a pas ce problème.
Sur Android, d'ailleurs, il n'est pas là non plus.
Mais les experts Android apprécieront la façon dont les paramètres sont transférés des composants externes vers les composants internes directement dans le balisage.

La vue de base ici est un analogue de LinearLayout (android) et UIStackView (iOS) avec un mélange de constantes en même temps. Une manière assez simple (par rapport aux interprétations) de positionner les éléments.

UIViewController et activité

React Native n'a ni l'un ni l'autre.
Bien sûr, ils sont sous le capot. Interagir directement avec eux ne fonctionnera pas. Oui, ce n'est pas nécessaire.

Le cycle de vie de tous les composants React Native est complètement différent de iOS et Android, il est difficile de faire des parallèles. Si vous vous concentrez sur les différences par rapport aux systèmes natifs, alors:

• Les éléments de l'interface utilisateur eux-mêmes changent d'état / d'apparence lors de la modification des paramètres d'entrée;
• sur android, il n'est pas nécessaire de jongler avec onSaveInstantState . React Native fait tout cela pour nous;
• sur iOS, il n'y a pas de méthodes qui signalent directement et explicitement le moment où les écrans d'application apparaissent / se cachent.

Temps de construction / rechargement en direct / rechargement à chaud

Une grande vitesse est obtenue grâce à un assemblage incrémental - seuls les modules modifiés sont reconstruits, et non l'ensemble complet.

Toutes les modifications du code JS sont visibles immédiatement visibles dans le simulateur. Accélère énormément le développement!

Manque de fonctionnalités natives dans JS

Dans la partie JS de React Native, tout ce dont vous avez besoin n'est pas prêt à l'emploi.

Vous pouvez écrire la partie native sur les deux plates-formes, créer un wrapper JS et l'appeler comme le reste du code. Il n'y a rien de compliqué.

Il existe un grand nombre de modules prêts à l'emploi écrits par des développeurs tiers.

Tous les modules sont connectés via npm (analogue de CocoaPods pour iOS et Gradle pour Android), qui ont un code natif avec les fonctionnalités nécessaires.

Liens universels et profonds

La fonctionnalité est implémentée par Facebook.
Cela fonctionne bien et régulièrement.

Traitement des intentions de tiers

Comme cas particulier du paragraphe précédent.

Le plus gros problème sur Android est de gérer une intention autre qu'un lien profond dans une application.
Cela dépend, bien sûr, de l'intention et de ce qui doit être fait lors de sa réception.

Vous pouvez écrire un article séparé sur ce sujet. Le point de départ est d'ajouter la méthode createReactActivityDelegate à MainActivity.

Performances

Il est assez facile d'obtenir 60 FPS lors du défilement de longues listes avec des cellules complexes.
Les performances de tout le reste (par exemple, en appuyant sur un bouton, en imprimant du texte dans un champ) sont plus faibles. Il est visible lors d'un changement d'état animé dans un grand nombre d'éléments. Cela peut être facilement résolu. Une bonne section dans la documentation Utilisation du pilote natif pour l'animation .

Et vous ne pouvez pas obtenir un contrôle normal des gestes et de leur association avec l'animation hors de la boîte.

Instabilité

Souvent, un projet s'arrête simplement de se construire, par exemple après:

• Réagir aux mises à jour du noyau natif (y compris lors de la mise à jour de la version mineure);
• mises à jour du module npm;
• Mises à jour Xcode;
• Mises à jour CocoaPods (problèmes permanents avec cela);
• juste comme ça. Oui, cela arrive aussi.

Heureusement, la plupart de ces problèmes sont résolus assez rapidement. Vous pouvez ajouter un script qui nettoie tous les caches partout et l'exécuter en cas de problème. Aide à résoudre 98% des problèmes étranges qui surgissent de nulle part. À l'exception des CocoaPods, tout est triste.

Instabilité de dépendance de tiers

Le plus gros problème sur iOS était et reste le désir répandu des modules npm d'utiliser la méthode swizzling .

De nombreux modules natifs sont connectés par des binaires. Comprendre que plusieurs modules indépendants utilisent la même méthode n'est pas si simple.

L'assemblage se déroule en plusieurs étapes et à chacune d'elles, quelque chose peut mal tourner.

Instabilité lors de la mise à jour des dépendances tierces

Certains modules npm dépendent d'autres modules npm, etc. Si deux modules sont liés à des versions différentes du troisième module, nous recevons immédiatement un avertissement lors de l'installation, dans le meilleur des cas. Et dans le pire des cas, il n'y a pas d'avertissement, mais rien ne fonctionne.

Un problème similaire si les modules npm s'appuient sur des modules Android natifs avec différentes versions.

Après avoir nettoyé le cache, les nouvelles versions peuvent se charger silencieusement. Il semble qu'il n'a rien fait, mais a cessé de travailler.

Tests unitaires et d'interface utilisateur

Un mécanisme de test très simple grâce à la bibliothèque Jest, est livré avec React Native. Analyse pratique de la couverture du test - montre quelles lignes de la fonction testée n'ont jamais été appelées.

Il existe des bibliothèques pour les tests d'interface utilisateur. Jusqu'à présent, en fait, je n'ai pas eu à l'utiliser.

Conclusion

Après 13 mois de travail avec React Native, je peux dire en toute confiance:

• il convient à la plupart des applications dans lesquelles il vous suffit d'obtenir une liste du serveur, d'afficher la liste, d'afficher une vue détaillée de l'élément de liste, d'envoyer des modifications au serveur;
• tout ce qui précède est réalisé avec moins de code;
• maintenant c'est mon choix «par défaut» pour les nouveaux projets qui me contactent, car voir le paragraphe précédent;
• ne convient pas aux projets à l'étranger "a envoyé une demande - a reçu une réponse", quelques exemples: éditeur de photos, lecteur, travail avec Bluetooth, AI, ML, social. messager réseau;
• Les projets avancés peuvent être effectués sur React Native, mais vous devez encore écrire beaucoup de code natif, donc le point n'est plus valide;
• React Native est venu et n'ira nulle part, cela doit être pris en compte;
• la demande de développeurs mobiles natifs diminuera légèrement, l'afflux de nouveaux développeurs mobiles natifs diminuera beaucoup plus. Pourquoi? voir ci-dessous;
• une personne suit généralement la manière la plus simple, et il n'est pas nécessaire d'essayer si 95% des applications peuvent être faites en dépensant 20% de l'effort (par rapport au développement natif) pour étudier;
• en conséquence des trois points précédents: l'écart entre la demande et l'offre de développeurs mobiles natifs va encore se creuser. Ceux qui ne peuvent vraiment pas s'en passer auront encore plus de mal à les trouver. Et c'est triste.

Le dernier mot pour quelqu'un qui a immédiatement commencé à écrire sur React Native et pour une raison quelconque a décidé de lire cet article, même jusqu'à la fin.

Si vous pensez que vous comprenez le sujet et que vous vous débrouillez bien, alors s'il vous plaît, essayez-vous en tant que développeur natif.