Cette série d’article sur les bonnes pratiques et les outils React Native, fait suite à une présentation donnée à « La Tech Amiénoise » : 1 an avec React Native.
Mes slides étant dépourvus de texte, ils ne seront pas d’une grande aide à ceux qui voudraient approfondir les éléments évoqués pendant cette présentation. J’espère que ces articles répondront à ce besoin.
Je vous propose de commencer par reprendre la liste des outils que je trouve utiles, voire indispensables pour développer un projet React Native.
Je l’avais dit pendant la présentation, mon article « référence » quand on parle de React Native est un article de Housing.
Si vous lisez l’article, ne vous étonnez pas de trouver des similitudes avec ce que j’évoque.
Code style
Avez-vous déjà essayé de lire un « git diff » après que quelqu’un ait changé toute l’indentation du code ?
Aimez-vous que votre intégration continue vous plante parce que vous avez oublié un point virgule et que le linter vous rappelle à l’ordre ?
Pour éviter ces désagréments, la solution s’appelle Prettier. Prettier formatte votre code de manière « opinionated », autrement dit il a des idées un peu arrêtées sur les choses. Avec lui, vous ne choisirez plus quand vous retournez ou non à la ligne. C’est le prix à payer pour qu’il corrige tout seul l’indentation du code, les points virgules, les parenthèses optionnelles, …
L’autre prix est évidemment qu’il faut le faire tourner à chaque modification de code.
Pour cela, il existe des extensions « Prettier » pour les principaux éditeurs de texte, qui modifieront votre code à chaque sauvegarde de fichier. C’est très pratique, mais rien ne vous assure que toute l’équipe va penser à configurer correctement son poste. Le mieux, c’est de l’ajouter en tant que « git hook ».Avant de commiter, le hook va s’occuper de passer vos fichiers par Prettier. Pour une configuration simple dans le projet, je vous recommande l’usage combiné de Husky et de lint-staged.
Un exemple de configuration est disponible dans la documentation de Prettier : https://prettier.io/docs/en/precommit.html
Une fois que l’on ne peut plus se tromper sur l’indentation et les points virgules, l’intérêt d’un linter, validant le code style en profondeur, est fortement réduit.
Je trouve le conseil de Ryan Florence au sujet d’Eslint plutôt judicieux.
I’ve been telling people to ditch that thing for years. Prettier + no-unused-vars + no-undef and move on with your life!
— Ryan Florence (@ryanflorence) 31 mai 2018
Mais dans le cas de React-Native on peut apprécier quelques règles supplémentaires concernant le style.
L’article suivant explique cela, plutôt que de le paraphraser, je vous laisse le lire : https://medium.com/the-react-native-log/getting-eslint-right-in-react-native-bd27524cc77b.
React-Native-Version
Le numéro de version d’une application, au démarrage cela peut sembler sans intérêt. Il suffit de l’incrémenter à chaque grosse livraison et puis c’est tout.
Mais dans un projet React Native, il faut le changer à plusieurs endroits. Pour chaque plateforme, il faut souvent modifier 2 valeurs différentes.
L’autre souci, c’est que si vous oubliez de monter la version de votre projet iOS, le build va bien se passer et c’est après plusieurs minutes, lors de l’upload vers l’App Store qu’une erreur va vous indiquer que cette version existe déjà.
Pour plus de simplicité, vous pouvez associer react-native-version à la commande `npm version`, pour monter le numéro de version de manière uniforme dans l’application et profitant au passage de la sémantique « major, minor et patch ».
React Native Debugger
Pour débugger votre application, vous êtes souvent amené à la lier à un Chrome pour voir les logs, …
Mais personnellement, je perdais tout le temps l’onglet de debug au milieu des recherches et des documentations ouvertes.
De plus, si votre projet comporte Redux, il faudra une extension dans Chrome pour vous aider.
Pour vous simplifier la vie, je vous conseille d’utiliser React Native Debugger. C’est une solution clef en main pour débugger les projets React Native avec Redux.
Icônes
En faisant votre application, vous avez certainement pensé au fait qu’il vous faudrait une icône et un splashscreen.
Sauf que dans la réalité, il ne vous en faut pas un, mais plusieurs pour les différents types de mobiles, les différentes résolutions, …
S’il est possible de tout faire dans Photoshop ou Gimp, cela peut s’avérer fastidieux. Et quand on vous demandera de changer l’icône, l’idée même de tout refaire risque de vous énerver.
La solution se trouve ici: https://github.com/bamlab/generator…
Il s’agit d’un générateur Yeoman créé par Bam Tech, qui à partir de deux images (icône et splashscreen), vous génère toutes les versions des images, les enregistre au bon endroit, bref qui vous simplifie la vie.
Déploiement
Si vous codez une application, votre objectif est qu’elle finisse sur les stores.
Or, si la plupart du temps vous pouvez ignorer le travail en double avec iOS et Android, pour le déploiement vous n’aurez pas le choix. Il va falloir builder les deux applications et les envoyer dans les stores, chacune avec sa méthode et ses petites spécificités.
Je ne parlerais pas ici des certificats et autres comptes « iTunes Connect », vous n’échapperez pas à un peu de configuration quoi qu’il arrive. Et elle n’est à faire qu’une fois au début du projet.
Là où l’utilisation d’un outil est intéressante, c’est dans la gestion des tâches répétitives. Fastlane propose de prendre à son compte aussi bien la partie build, que la partie upload, mais surtout d’enchaîner ces actions sans que vous ayez à intervenir.
Pour Fastlane aussi, il faut un peu de configuration (lui donner les droits d’écrire dans le Play Store, lui fournir l’accès aux certificats Apple), mais une fois en place, vous pouvez déployer votre application en deux lignes de commande. (Notez qu’il est possible de regrouper les configurations iOS et Android dans un seul fichier, mais je n’ai jamais pris le temps de regarder comment faire.)
Si le déploiement est facilité, vous déploierez plus souvent et vous pourrez montrer votre avancement (via les builds alpha et Test Flight) à vos responsables/clients.
Dans sa documentation, Fastlane propose plein d’autres fonctionnalités, dont par exemple la prise automatique de screenshots. Mais ceci demande encore de la configuration et je pense que celle-ci n’est rentable que sur de (très) gros projets.
Fastlane peut tourner sur votre machine ou dans l’idéal sur un environnement d’intégration continue.
Toutefois, n’oubliez pas qu’il faudra partager un certain nombre de secrets avec cet environnement. Il faut donc qu’il soit correctement sécurisé.
Conclusion
L’objectif de tels outils est de vous rendre la vie plus facile, de vous éviter les tâches répétitives et les erreurs humaines.
React Native est aujourd’hui extrêmement populaire et la présence de tous ces outils Open Source est un des facteurs de cette popularité.
Références
Lien vers React-Native-Version : https://github.com/stovmascript/react-native-version
Lien vers React Native Debugger : https://github.com/jhen0409/react-native-debugger