Structurer son projet React Native

Accéder au sommaire de « Guide pratique du développeur React Native »

La structuration du projet reflète les choix techniques d’une application. Le langage est-il typé ? Si oui, un outil de gestion d’état a t-il été mis en place ? Y a t-il une bibliothèque de composants proposant un mécanisme de théming (identité visuelle, etc …) ? Quid de la navigation et du routage ? Autant de questions qui doivent être posées en début de projet et dont les réponses vont définir la structure, le scaffolding.

Expo ou pas expo ?

La première fois que j’ai découvert Expo en tant que développeur mobile, son utilisation m’a semblé incontournable tant Facebook en fait de la publicité dans sa documentation. J’ai compris bien plus tard que ce n’était pas le cas. Il faut même dire que la grande majorité des développeurs React Native ne l’utilisent pas. Si vous ne savez pas ce qu’est Expo, jetez un oeil sur cet article en Français. Et si vous souhaitez avoir un avis contraire, en voici un.

Pour ma part, je trouve Expo très intéressant pour du prototypage ou pour des applications simples n’ayant aucune adhérence avec des bibliothèques tierces natives. La testabilité et l’expérience RAD (Rapid App Development) en font un excellent SDK. Pour une mise en production d’application d’envergure, il est peut-être raisonnable d’imaginer plutôt une application Web progressive car Expo limite très vite la marge de manoeuvre lorsqu’il s’agit d’accéder aux ressources locale du mobile. Sans compter la gestion des dépendances dans ce SDK qui aura toujours un temps de retard par rapport à la ligne React.

Une fois le choix Expo envisagé, passons au scaffolding, la structure de notre répertoire applicatif.

Scaffolding

Sur Dossardeur le choix initial s’est porté sur TypeScript avec l’utilisation du CLI React Native comme générateur du squelette initial.

npx react-native init myapp --template react-native-template-typescript

Toutes les recommandations du guide CRNA ont été précieuses, que ce soit le nommage des fichiers, l’approche par composant pour faciliter les tests ou la configuration du linter. Il existe une théorie en React influencée par Redux qui consiste à séparer les composants de présentation (components) des pages ou écrans (containers). C’est un vaste débat au sein de la communauté et même son auteur (qui est aussi l’auteur de Redux) n’y adhère plus avec l’émergence des Hooks. On trouve malheureusement encore aujourd’hui beaucoup trop de projets s’appuyant sur ce découpage obsolescent qui continue à faire des dégâts.

« Update from 2019: I wrote this article a long time ago and my views have since evolved. In particular, I don’t suggest splitting your components like this anymore  » (Dan Abravom: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)

Avec l’expérience, il me semble que séparer les écrans et les composants reste malgré tout important car les écrans implémentent le workflow applicatif. Cet article propose une structuration moins dogmatique que celle de Redux et surtout compatible avec un outil concurrent de Redux.

 » (…)  when we are talking about organizing folders and files, it’s irrelevant to split our components by the concept of presentational vs container. That said, we are going to keep all our components inside the components folder, except the screens. »

D’où la nécessité de créer à minima un répertoire /component et un répertoire /pages ou /screens. C’est le découpage dont j’ai opté pour Dossardeur.

Gestion des styles et des Assets

Une application React Native contient des Assets. Les assets constituent les parties relatives aux images, aux CSS, aux fichiers vectoriels ou aux fichiers externes (PDF, JSON, …), tout ce qui ne relève pas du code source. La documentation React Native traite chaque type d’asset en insistant sur la nécessité d’inliner les Assets pour éviter les allers/retours réseaux. En intégrant les images de petites tailles ou les fichier SVG dans le bundle initial JavaScript aux côtés du code source, on évite la multiplication des requêtes HTTP. Tout ceci est expliqué en détail dans le guide de démarrage du CRNA (la version Web) dans la section « Gestion des Assets ».

Il est recommandé d’utiliser des assets importés via l’ordre 'import asset from ./assets/assetXX' pour les raisons suivantes :

• Les scripts et les CSS sont minifiés et regroupés dans un même bundle.
• Les fichiers manquants vont provoquer des erreurs de compilation ce qui évitera les erreurs 404.
• Les fichiers générés par les assets importés contiendront un code de hachage qui permettra d’éviter les mises en cache abusives de certains navigateurs.

Une fois le projet généré, il suffit de lancer le bundler metro avec la commande  npx react-native run-android

Vous trouverez un exemple de projet ayant été généré avec le CLI react native et son template TypeScript sur notre github.

Le répertoire android contient l’ensemble des fichiers projets liés à Android et à l’inverse, le répertoire ios, l’ensemble des fichiers projets liés à l’environnement XCode.

N’hésitez pas à télécharger Android Studio et XCode, ils vous seront parfois très utiles pour déboguer des cas à la marge.

Bibliographie

RN BoilerPlate, un générateur de code :  https://github.com/thecodingmachine/react-native-boilerplate

Ignite, un autre générateur : https://github.com/infinitered/ignite

RN Feature BoilerPlate : https://github.com/victorkvarghese/react-native-feature-boilerplate