Integrer react JS et react Native
Qu'est-ce que ça apporte React native?
Quand on développe une application web et une application mobile, on a envie de partager un maximum de code entre les deux.
Idéalement, on aimerait bien faire un code pour cibler les deux plates-formes, mais c'est délicat.
Ca a été développé par Facebook pour faire l'app mobile sur Android et IOS, au lieu de développer avec 2 langages, on n'a qu'un langage, javascript. Derrière, le code est transpilé en langage propre, objective-c pour iphone et java pour android. Ceux qui ne connaissent pas Redux, petit rapel ici avec revue de code.ou ici avec expo & graphQL ou là avec les props
Une question? Posez-la ici
Aide au développement d'applications
React Native c'est javascript
On peut utiliser les librairies classiques javascript, pour les tests unitaires, on peut utiliser ugest mocha...
Il va y avoir une base commune entre ReactJS et React Native
Que partager?
Les librairies communes, redux...
Si on utilise fetch c'est compatible.
Dom, routes, views..
Tout ce qui est manipulation de DOM, ca ne fonctionnera pas dans react native
Tout ce qui est routes ne fonctionnera pas dans react native
la view: les composants react et react native sont différents
Comment faire pour gérer l'évolution de notre app mobile et notre app web dans le temps?
On part d'une structure de base avec des composants, des containers, des actions, des reducers, sagas, c'est souvent la meme structure.
On va avoir plein de fichiers dans les dossiers containers avec des sous dossiers, etc.
On se retrouve avec un code splitté un peu dans tous les sens. Si on supprime une view on doit supprimer aussi le reducer. Si on a des milliers de views, ca devient dur à gérer.
Idée: découper le code en fonction de la fonctionnalité en elle même
On va créer un dossier module, avec un dossier prodict-list, qui contient les actions, les composents, les containers, les reducers...
Si demain je veux supprimer un module complet, je supprime le répertoire et tout disparait, c'est propre, et maintenable, et réutilisable pour le partage
C'est bien de faire des modules, mais c'est comme si on créait un package pour que demain on puisse le mettre sur NPM et le diffuser. Tiens, mon module c'est une mini application qui gère tous les produits
L'idée c'est de commencer par la partie web , on met tout en modules et si demain j'ai envie de faire une app react native, je pourrai réutiliser ce module.
Notre arborescence de base ressemble à ça, on peut cloner un repo github par exemple:
|
src |
Rappels sur qu'est-ce que redux, un reducer, un store, etc... Les concepts?
Store: objet javascript qui va etre persistent dans le temps. On va stocker les données de l'application qui vont devoir persister pendant toute l'utilisation. Il peut etre stocké dans le local storage pour durer plus longtemps
Reducer: c'est une fonction qui a le droit d'écrire dans le store. On appelle cette fonction, avec en argument un nom d'evenement, exemple, un setter de username avec le username. Cette fonction va mettre à jour la donnée dans le store.
Dans la vue, on déclenche un evenement, ensuite lun reducer va reagir à cet evenement, comme un listener., et ensuite le store va etre mis à jour.
React-Redux: quand le store est à jour, on va pouvoir mettre à jour le composant.
Une question? Posez-la ici
Aide au développement d'applications
Use import
Ce module, je vais pouvoir le mettre dans NPM avec des choses à l'intérieur (vues, conainers, reduces, constantes...) il faut charger tout ca. On peut faire des imports.
Quand on fait un redux, on a un gros objet en JSON dans le store. L'objet a besoin de savoir où il se trouve dans le store
une des solutions est d'utiliser une entrée dans le store pour s'enregistrer. On passe par une registry: éje m'appelle product listé, voilà on requete le reducer: où est-ce que je suis enregistré?
Idem pour le sagas, voilà, j'ai un sagas, où est-ce que je vais etre enregistré?
Il va y avoir une fonction qui va récupérer l'endroit où est enregistré la donnée.
On a nos modules: 1, 2, fiche produit, fiche contact uilisateur... Ils vont s'enregistrer dans la registry. L'application va juste récupérer les routes dont elle a besoin.
Les avantages
Le module est stocké dans le store, on ne sait pas où , on s'en fiche, c'est géré dynamiquement. Le module ne sait pas où il va être utilisé, c'est la registry (Une registry, comme en Java avec Ehcache et Zookeeper) qui va gérer les endroits où se trouvent les modules.
Au niveau du code et de la maintenance, le pattern
Pour la partie registry, on a un module redux qui va exposer InscriptionModuleReducer(key,reducer) pour enregistrer un reducer
le product sera dans l'index.js on exporte une fonction qui fait un InscriptionModuleReducer que l'on appelle dans redux configureStore.js
On utilise le getReducers du module qui va renvoyer toute la liste des reducers que le registre contient.
A chaque fois qu'on ajoute un module, on appelle la fonction import
Reducer, sagas, constantes
users/components/web..UserList.js
...
Ca fonctionne aussi si on utilise reselect
Une question? Posez-la ici
Aide au développement d'applications
Les routes et les points d'entrées
Une appli web veut une route comme point d'entrée.
Une appli mobile veut une vue en point d'entrée.
Les 2 applis vont avoir la partie store commune.
L'appli web va importer des routes (grace aux modules) dans le registre
L'applicaion mobile va récupérer une view mobile toujours grace au module
Un module contient les view mobiles et les routes web
Donc idéalement, on va avoir la structure du coposant avec mes 2 points d'entrée:
produit/composant/mobile
produit/composant/web
Import inter modules
On configure webpack pour mettre dans le nodepath le chemin vers les modules
Je suis dans un module "user" et j'importe les constantes et les actions de "product"
On va avoir des composant qui ont des dépendances entre eux. Un module dépend d'un autre module.
Conclusion
on va pouvoir mettre en commun les mécanismes qui sont identiques: authentification des utilisateurs, données...
On a 2 applications différentes avec du code en commun, des modules en commun, qui seront publiés petit à petit sur NPM
On développe les 2 applications de manière indépendante, MAIS on analyse voir si des composants peuvent être partagés.
Ces applications sont basiques, elles n'enregistrent que des modules.
Les modules sont indépendants, ils ne savent pas où ils sont enregistrés.
Eviter de faire de trop petits modules. Exemple, 1 widget pour un module. Regrouper les modules par composants par exemple, UI. Un module UI qui contient les boutons, ...
Inconvenient: scalabilité avec des mudules trop petits, on va devoir maintenir trop de modules, les versions, les packages, les deploiements.
Pour ceux qui sont intéréssés, il y a une super formation React Native sur Udemy
Le PAQ: plan d'assurance qualité: garantir la fiabilité du compte-rendu
Le programme d'assurance qualité qu'est-ce que c'est?
Un engagement de livrer en temps e en heure le livrable attendu avec la meilleure qualité possible, d'où votre possibilité de voter en mettant des étoiles.
Nous pouvons vous
-donner accès aux informations nécéssaires
-respecter le délai critique, le planning
-fournir les moyens
Grace aux commentaires en bas, nous pouvons vous offrir:
-une meilleure prise en compte de vos attentes
-la définition de ce qui est important pour vous en terme de qualité
-la définition de l'objectif du document
Allez, c'est à, vous: vous pouvez voter et mettre 5 étoiles!
Voilà, j'espère que ça vous a plu. Vos commentaires/remarques sont les bienvenus