Récit de l’expérience vécue par Ridibooks lors de la migration de son application native vers React Native
- Pourquoi avoir choisi React Native
-
Jusqu’ici, la découverte des contenus et le paiement se faisaient sur le web, tandis que l’application servait de lecteur. Il a été décidé d’introduire aussi dans l’application les fonctions de navigation et de paiement. Pour répondre rapidement aux changements et atteindre les objectifs dans le délai imparti, l’équipe a choisi une technologie permettant le développement cross-platform
-
Entre Flutter et React Native, React Native a été retenu car sa communauté paraissait un peu plus stabilisée et active
- Base native vs base React Native
-
L’équipe s’est demandé s’il fallait intégrer React Native dans l’application native, ou au contraire intégrer le natif au-dessus de React Native
-
Si l’on place React Native sur du natif, les endpoints changent selon les écrans et la gestion du cycle de vie de l’application devient plus complexe
-
Si l’on place du natif sur React Native, il faut d’abord modifier une fois le code natif existant pour le rendre compatible avec React Native. À terme, il faudra de toute façon tout réécrire directement en React Native
-
Comme la plupart des fonctionnalités devaient de toute façon être migrées vers React Native, l’équipe a décidé d’aller dans la direction où le natif s’intègre au-dessus de React Native
- Réutilisation des écrans natifs
- Pour réagir rapidement aux changements dans le délai imparti, il a été décidé d’écrire les nouveaux écrans en React Native et de conserver les écrans existants en natif (avec une migration progressive des écrans natifs vers React Native)
- Réutilisation du code natif
-
Était-il possible d’intégrer dans React Native l’essence du natif accumulée par Ridibooks au fil de 13 ans de maintenance ? L’application native existante utilisait Swift et Kotlin, et il fallait vérifier s’il était possible de les réutiliser tels quels dans React Native
-
En créant un bridge, il a été possible de les utiliser comme auparavant
- Difficultés rencontrées pendant l’adoption
-
La taille du bundle et l’usage mémoire ont augmenté
-
La taille du bundle était à peu près conforme aux attentes, mais la mémoire était catastrophique. Il a donc fallu accorder beaucoup d’attention à l’optimisation.
-
Il est difficile de faire confiance aux bibliothèques tierces
-
On ne peut négliger ni le natif ni le front-end. Les développeurs natifs doivent apprendre le développement front-end, et les développeurs front-end doivent apprendre le développement natif. Les échanges entre les deux sont la clé du succès.
- Pourquoi React Native est une bonne solution
-
Une productivité élevée
-
Une plateforme favorable à la collaboration
Grâce à React Native, l’équipe a pu tenir la roadmap produit dans le délai imparti, tout en se dotant d’un environnement et d’une productivité permettant de réagir rapidement aux changements. À l’avenir, le remplacement du périmètre natif par React Native va s’accélérer. En revanche, le lecteur continuera d’être maintenu tel quel, car il repose sur 13 ans de savoir-faire accumulé, afin d’offrir la meilleure expérience utilisateur possible.
11 commentaires
Je ne sais pas si vous avez déjà essayé de faire une recherche de mots-clés sur Google Trends, mais l’écosystème RN est presque en train de mourir. À l’inverse, Flutter connaît une croissance explosive. Pour référence, je suis développeur natif.
Du point de vue des utilisateurs, l’application desktop semble moins performante que la version précédente. Avant, on ne ressentait pas de délai lors du changement de page, mais ces derniers temps, elle saccade en permanence.
J’aimerais bien qu’ils mettent un peu ça en avant sur la version desktop… Je me demande si ce n’est pas impossible à cause de problèmes de droits d’auteur, hmm.
J’aimerais vraiment qu’on accorde aussi un peu d’attention aux applications desktop, pas seulement aux applis mobiles… snif snif
En tant qu’utilisateur de longue date de l’application desktop de Ridibooks, j’ai un peu l’impression que cette décision a été prise en ne pensant qu’au mobile, et c’est regrettable. Et je ne suis pas le seul : tous ceux que je connais qui utilisent l’application desktop, sans exception, souffrent de bugs récurrents... (c’est même pire que l’ancienne appli basée sur Qt)
J'ai vraiment beaucoup entendu autour de moi des plaintes sur les problèmes des applications desktop..
Je ne suis pas moi-même développeur, mais en voyant l’enthousiasme autour de Flutter dans les communautés que je fréquente, j’en ai parlé au développeur de l’app de mon entreprise, et il semble avoir une préférence plus marquée pour React. Il disait notamment que l’écosystème et le marché du recrutement y sont meilleurs. J’aimerais aussi connaître l’avis des autres.
Le natif évolue à une vitesse impressionnante, donc la question clé sera de savoir si RN peut suivre ce rythme.
Que vaut Flutter, comparativement, sur cette question ?
De la même façon, Android devrait s’en sortir, mais je ne sais pas s’il pourra suivre iOS.
Je pense qu’il ne faut pas sous-estimer le coût de l’entropie engendrée par l’unification.
Nous l’avons développé et lancé avec React Native il y a 2 ou 3 ans...
Personnellement, j’ai trouvé qu’il y avait plus d’inconvénients que d’avantages...
https://m.blog.naver.com/PostView.naver/…
J’avais largement cessé de m’y intéresser... mais il reste toujours aussi populaire.