Dans les articles précédents (intro, chapitre 1, chapitre 2), nous avons répondu aux problématiques liées aux dépendances et à l’outillage de développement. Nous allons maintenant nous concentrer sur le contenu de la librairie, ses composants et sa configuration.

La librairie doit être personnalisable sur plusieurs aspects, notamment :

• le thème graphique
• l’internationalisation : les locales supportées ainsi que la langue courante
• la gestion des appels serveurs et l’authentification
• le paramétrage de certains composants exposés par la librairie
• le paramétrage propre à notre métier

Comme évoqué précédemment, toutes nos applications partagent la même stack technologique. Côté code, on retrouve principalement :

• react-native-paper, une librairie de composants React Native qui implémente le design Material de Google et qui porte le thème
• i18n-js pour l’internationalisation
• axios pour les appels serveur

Un provider pour notre librairie

Notre librairie doit être capable de prendre un certain nombre de paramètres en entrée. Ces paramètres doivent être accessibles depuis n’importe quel composant de la librairie, voir même depuis l’application.

Un contexte React est la solution parfaite pour ce besoin. Pour utiliser un contexte, il faut déclarer un Provider. Tous les enfants de ce Provider ont ainsi accès à la valeur du contexte.

Nous avons repris cette logique pour notre librairie. La librairie expose donc un composant « Provider« , qui a été volontairement simplifié pour notre exemple :

Composant Provider de la lib
import { FC } from 'react'
import { ConfigContextProvider } from '../contexts/ConfigContext'

interface Props {
locale?: string
mode?: 'TEST' | 'PRODUCTION'
}

export const Provider: FC = ({
locale = 'fr-FR',
mode = 'PRODUCTION',
children,
}) => (
{children}
)

Ce composant prend tous les paramètres de configuration de la librairie et les stock dans un contexte interne à la librairie.

En situation réelle, notre Provider prend plus de props et déclare plusieurs contextes, mais vous avez compris l’idée 😉

Les applications doivent obligatoirement déclarer ce Provider pour utiliser la librairie. Voici un exemple simplifié du composant App de notre application :

Déclaration du Provider dans l'app

import { Provider as SharedComponentsProvider } from '@lyra/shared-components'
import { FC } from 'react'
import { AppContext, AppContextProvider } from './src/contexts/AppContext'
import { Root } from './src/Root'

export const App: FC = () => (
{({ locale, mode }) => ( )}
)

L’utilisation des contextes nous permet de rester dans le cycle de vie React et d’être totalement synchronisé, de manière à ce que si par exemple, l’utilisateur change la locale dans sa page de paramètres de l’application, la valeur sera mise automatiquement à jour dans la librairie.

Gestion du thème

Dans nos applications, le thème est porté par React Native Paper (RNP). RNP est une librairie de composants React Native qui implémente le design Material de Google.

Sur les screenshots ci-dessous, on remarque que les composants se ressemblent mais que la palette de couleur est différente pour chaque application. Ces différences sont justement configurées dans le thème.

La librairie va donc utiliser des composants de RNP, en prenant en compte le thème de l’application cible.

Nos besoins sont les suivants :

• Tous les composants de la librairie doivent utiliser le thème de l’application cible
• Le format du thème sera basé sur celui de RNP mais contiendra quelques champs supplémentaires, il faut que le typage du thème fonctionne correctement dans la lib et dans les apps
• La librairie doit proposer un thème par défaut
• Les applications doivent pouvoir passer un thème personnalisé
• Les applications doivent pouvoir accéder au thème avec un hook ou un High-Order Component (HOC)

Mais plusieurs problématiques apparaissent :

• Le thème est passé à RNP via un Provider, mais qui doit déclarer ce Provider : l’application ou la librairie ?
• Le format de nos thèmes hérite de celui de RNP mais rajoute quelques champs custom, comment faire pour que les apps et la lib aient accès au typage de notre thème ?
• Comment faire pour pouvoir accéder au thème au moment de déclarer nos styles (depuis l’app ou la lib) ?

Qui doit déclarer le Provider RNP ?

Celui qui déclare le Provider RNP devra aussi être responsable d’augmenter le type du thème RNP avec les champs qu’il veut ajouter, comme ceci par exemple :

react-native-paper.ts
declare global {
namespace ReactNativePaper {
interface ThemeColors {
highlighted: string
}
}
}

Avec cette augmentation de module, il est maintenant possible d’accéder à theme.colors.highlighted (qui n’existe pas dans le thème RNP) sans erreur TypeScript.

Si ce sont les apps qui déclarent le Provider RNP, plusieurs problèmes apparaissent :

• La lib pourra utiliser des composants RNP mais n’aura pas accès au thème en dehors du contexte React (avec useTheme). Les feuilles de style en React Native se déclarent en dehors des composants, donc ça pose problème.
• La lib ne pourra pas augmenter le type du thème et ne bénéficiera pas de l’augmentation du type par l’app.
• La lib ne pourra pas proposer de thème par défaut.

C’est pour ces raisons que nous avons choisi de déléguer la responsabilité de déclarer le Provider RNP à notre librairie.

C’est la solution la plus logique, la librairie peut ainsi proposer un thème par défaut, avec son typage. Les apps restent libres d’étendre ce thème (en créant un thème custom) comme bon leur semble.

La librairie déclare donc le Provider RNP au niveau de son propre Provider :

Composant Provider de la lib
import { FC } from 'react'
import { Provider as PaperProvider } from 'react-native-paper'
import { ConfigContextProvider } from '../contexts/ConfigContext'
import { LyraTheme } from '../styles/LyraTheme'

interface Props {
locale?: string
mode?: 'TEST' | 'PRODUCTION'
theme?: ReactNativePaper.Theme
}

export const Provider: FC = ({
locale = 'fr-FR',
mode = 'PRODUCTION',
theme = LyraTheme,
children,
}) => (
{children}
)

À noter que la dépendance react-native-paper sera déclarée en peerDependencies au niveau de la librairie pour ne pas dupliquer la dépendance (voir notre deuxième article pour plus de détails).

Thème par défaut

Si aucun thème n’est passé à la lib, un thème par défaut « Lyra » est utilisé.

Les applications peuvent passer un autre thème en se basant (ou pas) sur le thème par défaut, par exemple :

Déclaration du Provider dans l'app
import { LyraTheme, Provider } from '@lyra/shared-components'

const theme: ReactNativePaper.Theme = {
…LyraTheme,
colors: {
…LyraTheme.colors,
primary: '#29337a',
}
}

export const App = () => (

)

Hook et High Order Component pour la création de styles

Maintenant que le thème et son type associé sont bien en place, il reste un dernier point à adresser sur notre liste de besoins : la mise à disposition d’un hook et d’un HOC pour la création de styles.

Rappel sur les hooks

Les Hooks sont des fonctions qui permettent de « se brancher » sur la gestion d’état local et de cycle de vie de React depuis des fonctions composants.

source

Rappel sur les HOC

Un HOC est une technique avancée de React qui permet de réutiliser la logique de composants. Concrètement, un composant d’ordre supérieur est une fonction qui accepte un composant et renvoie un nouveau composant.

Source

En React Native, le style est passé aux composants grâce à la propriété style. Généralement, on externalise le style avec StyleSheet.create pour plus de lisibilité. Cette méthode ne fait pas grand chose mais au moins elle valide le format du style qu’on lui passe. Exemple :

import { FC } from 'react'
import { StyleSheet } from 'react-native'
import { Text } from 'react-native-paper'

const styles = StyleSheet.create({
link: {
color: 'blue',
textDecorationLine: 'underline',
},
})

export const LinkText: FC = ({ children }) => (
{children}
)

Admettons que ce composant fasse partie de notre librairie et que l’on souhaite que le texte soit de la couleur « primary » du thème. Cela donne :

import { FC } from 'react'
import { StyleSheet } from 'react-native'
import { Text, useTheme } from 'react-native-paper'
 
const styles = StyleSheet.create({
  link: {
    textDecorationLine: 'underline',
  },
})
 
export const LinkText: FC = ({ children }) => {
  const { colors } = useTheme()
  return <Text style={[styles.link, { color: colors.primary }]}>{children}</Text>
}

Ça fonctionne, mais ce n’est pas encore optimal. En effet, cela nous oblige à avoir du style à la fois à l’extérieur du composant mais aussi en inline. Et c’est assez verbeux.

Nous avons donc trouvé une solution qui s’inspire du makeStyles de MUI : une fonction de création de hook.

import { FC } from 'react'
import { Text } from 'react-native-paper'
import { createUseStyles } from '../styles'
 
const useStyles = createUseStyles((theme) => ({
  link: {
    color: theme.colors.primary,
    textDecorationLine: 'underline',
  },
}))
 
export const LinkText: FC = ({ children }) => {
  const { styles } = useStyles()
  return <Text style={styles.link}>{children}</Text>
}

Le hook useStyles retourne un objet avec les styles et le thème. Il est possible de lui passer des propriétés qui sont récupérées en deuxième argument de la callback de createUseStyles.

Pour les composants sous forme de classe, nous mettons également à disposition un HOC withStyles :

import { Component } from 'react'
import { Text } from 'react-native-paper'
import { withStyles } from '../styles'
 
const getStyles = (theme) => ({
  link: {
    color: theme.colors.primary,
    textDecorationLine: 'underline',
  },
})
 
class LinkTextComponent extends Component {
  render() {
    const { styles } = this.props
    return <Text style={styles.link}>{children}</Text>
  }
}
 
export const LinkText = withStyles(getStyles)(LinkTextComponent)

Pour la partie relative au thème, les problématiques sont résolues :

• La librairie s’occupe de déclarer le Provider de React Native Paper.
• La librairie propose un thème par défaut, qui reste extensible par les applications.
• La librairie expose des utilitaires de création de style qui permettent d’accéder au thème.

Gestion de l’internationalisation

Sans rentrer dans les détails, l’internationalisation et la localisation sont des concepts liés à la capacité d’un logiciel à s’adapter à une région donnée. C’est principalement la traduction des textes mais il y a aussi le formatage des dates, des nombres, des devises, et de tout ce qui peut être spécifique à une région.

Nos applications sont disponibles dans plusieurs régions, donc dans plusieurs langues. Et selon l’application et la configuration de celle-ci, la liste des langues disponibles n’est pas toujours la même.

Notre librairie doit donc être capable de fournir ses composants dans la locale désirée. Le soucis, c’est qu’elle ne peut pas anticiper la totalité des locales qui lui seront demandées.

Nos besoins sont les suivants :

• L’application doit pouvoir spécifier la langue à utiliser
• L’application doit pouvoir fournir toutes les informations d’une locale si celle-ci n’est pas supportée par la lib, et pouvoir surcharger certaines valeurs selon ses besoins
• Les composants de la lib doivent respecter la locale spécifiée par l’application

Les problématiques à solutionner sont les suivantes :

• Comment éviter de dupliquer la dépendance du gestionnaire i18n ?
• Qui porte la responsabilité de l’internationalisation (dépendance + initialisation) ?
• Comment fusionner les locales de la librairie et de l’application ?
• Comment permettre à l’app d’ajouter ou changer des valeurs dans les locales ?

Un gestionnaire d’internationalisation commun

Pour éviter la duplication de dépendance et partager un format commun pour les locales, la solution la plus simple est de se mettre d’accord sur le choix du gestionnaire d’internationalisation.

Les applications utilisent déjà toutes la même librairie : i18n-js. L’idéal serait donc de fusionner les locales entre l’application et la librairie puis d’initialiser le composant d’i18n qu’une seule fois.

Qui porte la responsabilité ?

Comme pour la gestion du thème, la dépendance sera apportée par l’application et déclarée en peerDependencies dans la librairie.

L’application passera la locale courante ainsi que les locales à ajouter / modifier à la librairie via les props de son Provider.

C’est la librairie qui s’occupe d’initialiser le gestionnaire d’internationalisation avec les données de locales fusionnées entre celles de la lib et celles de l’application.

Voici la nouvelle version de notre Provider avec la gestion de l’internationalisation :

Composant Provider de la lib

import i18n from 'i18n-js'
import { merge } from 'lodash'
import { FC, useLayoutEffect } from 'react'
import { Provider as PaperProvider } from 'react-native-paper'
import { ConfigContextProvider } from '../contexts/ConfigContext'
import { LyraTheme } from '../styles/LyraTheme'
import { translations as internalTranslations } from '../i18n'
 
interface Props {
  locale?: string
  mode?: 'TEST' | 'PRODUCTION'
  theme?: ReactNativePaper.Theme
  translations?: Record<string, object> // { 'fr-FR': {...}, 'en-GB': {...} }
}
 
export const Provider: FC<Props> = ({
  locale = 'fr-FR',
  mode = 'PRODUCTION',
  theme = LyraTheme,
  translations,
  children,
}) => {
  // useLayoutEffect pour éviter un flash de contenu non traduit
  useLayoutEffect(() => {
    i18n.fallbacks = true
    i18n.defaultLocale = 'fr-FR'
    i18n.translations = merge({}, internalTranslations, translations)
    i18n.locale = locale
  }, [locale, translations])
 
  return (
    <PaperProvider theme={theme}>
      <ConfigContextProvider locale={locale} mode={mode}>
        {children}
      </ConfigContextProvider>
    </PaperProvider>
  ) 
}

À noter que i18n-js n’utilise pas de Provider, il faut initialiser les champs de son instance globale.

Pour la partie relative à l’internationalisation, les problématiques sont résolues :

✅ Une seule dépendance et une seule initialisation pour le gestionnaire d’internationalisation.

✅ Les traductions de la lib et de l’app sont fusionnées ce qui laisse la liberté aux apps d’ajouter ou remplacer les traductions de la lib.

❗ Le seul point qui ne reste pas optimal est que les apps doivent connaitre les clés de traduction exactes dans la lib pour pouvoir les surcharger.

Les paramètres utilisateur

Dernière partie de cet article assez touffu… nous allons aborder les paramètres utilisateur.

L’intégration de la librairie dans les applications doit être totalement transparente pour l’utilisateur.

Les applications et la librairie gèrent en interne leurs propres paramètres pour leurs composants, mais il ne faut proposer à l’utilisateur qu’un seul écran de paramétrage qui permette de régler tous de paramètres.

Nos besoins

• Pouvoir intégrer les paramètres de la librairie dans l’écran de paramétrage de l’application
• L’utilisateur doit pouvoir modifier des paramètres d’app ou de lib de manière transparente

Les problématiques

• Comment passer des paramètres utilisateur à la librairie ?
• Comment intégrer des paramètres spécifiques aux composants de la librairie dans l’écran de paramétrage de l’application ?

Passage de paramètres de l’application vers la librairie

Avec notre système de Provider déjà en place, il est facile de passer des paramètres à la librairie.

Ces paramètres sont synchronisés dans un contexte côté librairie et donc accessibles partout dans la librairie.

Voir l’exemple de code du Provider un peu plus haut, les paramètres locale et mode sont des paramètres utilisateurs qui sont gérés au niveau de la librairie.

Intégration des paramètres spécifiques à la librairie

Le comportement de certains composants de la librairie est paramétrable.

Pour que ces paramètres soient parfaitement intégrées, la librairie expose un composant qui se fond parfaitement dans les paramètres de l’application. En effet, ce composant utilise les même composant RNP qui est lui-même correctement configuré au niveau du thème.

La valeur de ces paramètres est stocké dans un contexte interne à la librairie.

L’utilisateur peut donc personnaliser ses paramètres, sans savoir si ceux-ci sont gérés par l’application ou la librairie.

Le screenshot ci-dessous présente l’écran des paramètres de l’application Lyra Collect, le bloc encadré en rouge provient de notre librairie :

✅ L’intégration est donc parfaitement transparente pour l’utilisateur.

✅ L’application peut passer des paramètres personnalisés à la librairie.

✅ La librairie est capable de gérer ses propres paramètres.

L’environnement de développement, l’intégration continue et le déploiement

Dans l’article précédent, nous avons configuré les outils pour la compilation et le packaging de la librairie. Nous allons maintenant voir comment configurer l’environnement de développement, l’intégration continue et le déploiement.

En effet, une des priorités de cette librairie est de proposer une expérience de développement agréable : un développeur doit pouvoir modifier la librairie et la tester sans délai dans son application mobile..

Enfin, nous verrons comment configurer l’intégration continue pour s’assurer de la qualité des développements, éviter les régressions et automatiser les publications.

Nos besoins

Nous pouvons résumer nos besoins comme suit :

• Simplicité d’utilisation et bonne expérience de développement (cf. ci-dessus)
• Intégration continue avec Bitrise, notre plateforme de CI mobile
• Déploiement de la librairie sur notre registry npm interne

Les problématiques

Pour atteindre ces objectifs, plusieurs points restent à éclaircir :

• Comment permettre au développeur de développer sans différence notable au sein de la librairie et de son application ?
• Comment configurer notre plateforme d’intégration continue pour tester la librairie en isolation ?
• S’assurer que la publication de la librairie sur notre registry npm privé fonctionne depuis Bitrise.

L’environnement de développement

La qualité de l’expérience de développement est un point très important à Lyra : il ne faut donc pas que la mise en place de cette librairie ajoute trop de complexité à l’environnement de développement, ou pénalise la productivité des développeurs.

Du coup, le développement de l’application et de la librairie doit continuer de bénéficier des comportement classiques : refresh de composant à chaud, debugger, inspecteur d’éléments etc.

De même, depuis l’application, on doit pouvoir basculer facilement entre une version publiée de la librairie (version officielle) et une version locale (en cours de modification par le développeur), afin de ne pas être obliger de publier une version juste pour la tester dans l’application finale. Il faut donc pouvoir dire au gestionnaire de paquet d’utiliser la version locale de la librairie, et non pas la version publiée disponible sur un registry.

Linking local de notre librairie

Premier essai : yarn link

Généralement lorsque l’on veut « lier » une librairie en local, on utilise yarn/npm link :

cd /path/to/lib    # nom du package = @lyra/shared-components
yarn link
cd /path/to/app
yarn link @lyra/shared-components

Malheureusement, dans notre cas, c’est un échec. C’est un problème connu (issue #1) mais Metro ne supporte pas les liens symboliques (symlinks) dans les dépendances ! Il a donc fallu trouver une autre solution …

Deuxième essai : yalc

Une solution alternative est d’utiliser yalc.

Yalc est un utilitaire qui utilise un dépôt local dans lequel on peut venir pousser des modules. A chaque mise à jour d’un module, il le copie automatiquement dans les répertoires « node_modules » de tous les projets « abonnés ».

Il n’utilise donc pas de lien symbolique mais une copie directe des fichiers au bon emplacement dans les node_modules.

npm install --global yalc
cd /path/to/lib     # nom du package = @lyra/shared-components
yalc push
cd /path/to/app
yalc add @lyra/shared-components

Et ça fonctionne plutôt bien ! L’application démarre et ne se rend compte de rien. A chaque nouvelle commande ‘yalc push’, les sources sont copiées dans les node_modules de l’application cible.

Et cerise sur le gâteau, le watcher de Metro surveille aussi les node_modules, ce qui veut dire qu’à chaque yalc push, Metro déclenche un refresh des composants modifiés. C’est exactement le fonctionnement désiré.

Synchronisation automatique des mises à jour

Nous savons maintenant linker notre librairie en local. Cependant, à chaque modification du code, nous sommes obligés de lancer manuellement un build TypeScript puis la commande ‘yalc push’ pour mettre à jour les sources dans les node_modules de l’application. On peut encore améliorer ça.

Il nous faudrait une sorte de watcher qui nous permette de déclencher automatiquement, à chaque modification, un build TypeScript puis un yalc push.

Or, un utilitaire fait exactement cela : tsc-watch !

Une fois lancé, l’utilitaire déclenche automatiquement un build TypeScript dès qu’il détecte une modification dans le code source. Nouvelle cerise sur le gâteau, on peut lui passer des commandes après chaque build avec l’option –onSuccess → c’est l’endroit idéal pour placer notre yalc push.

On configure donc un script npm côté librairie pour lancer tsc-watch.

package.json

{
  "scripts": {
    ...
    "prewatch": "rimraf dist",
    "watch": "tsc-watch -p tsconfig.json --onSuccess \"yalc push\"",
  }
}

Ainsi, à chaque modification sur un fichier de la librairie, un build TypeScript est déclenché, suivi d’un yalc push. L’application recharge les composants modifiés comme si nous développions directement dans l’application !

La configuration côté application

Côté application, il suffit de deux scripts npm pour lier ou délier la librairie locale :

package.json

{
  "scripts": {
    ...
    "lib:link": "yalc add @lyra-network/shared-components && yarn install",
    "lib:unlink": "yalc remove @lyra-network/shared-components && yarn install",
  }
}

Le yarn install après chaque commande est important dans le cas où les dépendances dans la librairie sont différentes entre la version locale et la version publiée dans nos repositories.

Pour résumer, quand un développeur veut faire une évolution dans la librairie, il est opérationnel en deux commandes : yarn watch depuis la lib et yarn lib:link dans son application.

Ensuite qu’il développe dans son application ou dans la librairie, le comportement est identique ! Il peut continuer à tester ses changements directement dans son application comme avant.

Attention à ne pas publier la configuration locale !

Nous utilisons une plateforme d’intégration continue ainsi que la plateforme d’Expo pour publier nos applications. Nous reviendrons en détail sur ces sujets juste après.

Cependant, dans ce contexte, si la librairie est linkée localement au moment de la publication, ça ne peut pas fonctionner. En effet, quand l’application sera compilée sur les serveurs d’Expo, les références locales ne peuvent pas être résolues.

Il faut donc être vigilant et s’assurer qu’au moment de publier, la librairie ne soit pas configuré en mode « local ».

Pour être sûr de ne jamais se rater (une erreur est si vite arrivée…), nous avons mis en place un hook git pre-push au niveau de chaque application qui vérifie qu’il n’y a pas de package linké localement avant de pousser le code sur la branche ‘main’.

Pour nos hooks git, nous utilisons l’utilitaire husky. La commande yalc check nous permet de vérifier qu’aucun package n’est linké localement dans le projet courant. Exemple de notre fichier de hook pre-push :

.husky/pre-push

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
 
git_branch="$(git rev-parse --abbrev-ref HEAD)"
 
if [ "$git_branch" = "main" ]; then
  npx yalc check
fi

yalc check retourne une erreur si un package est linké localement et que nous sommes sur la branche ‘main’, ce qui empêche ainsi le push sur le serveur git.

C’est terminé pour la partie environnement de développement. Les outils mis en place nous permettent de garder une bonne expérience développeur. Le client Expo fonctionne comme avant et ne se rend même pas compte du changement. Le développeur peut donc travailler sur la librairie en testant les modifications directement depuis son application.

Intégration continue et publication de la librairie

Grâce à la plateforme d’intégration continue Bitrise, tout changement de code dans la librairie est testé pour éviter les régressions. La publication de la librairie est également gérée avec Bitrise. 

Non-régression

La librairie contient ses propres tests avec Jest, ainsi que sa propre configuration ESLint et Prettier.

A chaque nouveau push, quelque soit la branche, un build est lancé dans Bitrise. Notre workflow contient les étapes suivantes :

1. yarn install → installation des dépendances
2. yarn lint → vérification de la syntaxe avec ESLint
3. yarn test → exécute les tests unitaires et d’intégration avec Jest
4. yarn build → compile la librairie avec TypeScript

Si une étape échoue, nous sommes notifiés directement par messagerie instantanée.

Ces tests nous permettent de nous assurer que les branches restent stables, surtout la branche ‘main’.

Publication de la librairie

Pour la publication, nous souhaitons que la librairie reste privée mais tout de même accessible depuis l’extérieur, justement pour permettre à Bitrise et Expo d’y accéder au moment des tests et builds de nos applications.

A Lyra, nous avons déjà un registry npm privé (accessible depuis l’extérieur via une authentification forte). C’est donc sur celui-ci que nous allons publier notre librairie.

Après avoir configuré l’authentification dans Bitrise, nous avons créé un nouveau job dans Bitrise qui s’occupe de publier notre librairie. Ce job est déclenché à chaque nouveau tag git.

Ainsi, quand nous voulons publier une nouvelle version de la librairie, il suffit de pousser un tag git. Le job se déclenche alors automatiquement, il effectue tous les tests nécessaires puis publie la librairie.

Ci-dessous une impression d’écran des différents builds de notre librairie sur Bitrise :

Conclusion

  L’expérience développeur reste très bonne malgré l’introduction de la librairie.

  Les développements en local sont quasi transparents grâce à l’outillage de notre environnement de développement.

  Le développeur continue de tester son application, qu’il travail sur la librairie ou sur son application.

  La qualité de la librairie reste maitrisée grâce à l’intégration continue.

  La librairie reste privée mais tout de même accessible depuis l’extérieur via une authentification.

Gestion des dépendances, des assets et du packaging de la librairie

Les premières problématiques que nous avons abordées lors de l’étude de faisabilité sont en rapport avec la gestion des dépendances et le packaging de la librairie.

Théoriquement, la création et l’utilisation d’une librairie JavaScript est une tâche assez courante et plutôt simple. Mais qu’en est-il dans le cadre d’un projet React Native ?

Le contexte technique

Nos applications utilisent les outils suivants :

	TypeScript, JavaScript avec du typage fort TypeScript ajoute une syntaxe supplémentaire de typage fort à JavaScript permettant de capturer les erreurs au plus tôt. Le compilateur TypeScript permet de sortir du code JavaScript standard.
	React Native, création d’applications native en React React Native permet de créer des applications mobiles natives écrites en JavaScript. Une seule base de code pour plusieurs applications.
	Expo, framework ET plateforme pour React Native Expo est un ensemble d’outils et de services qui facilite et améliore le développement d’application en React Native. Il propose des API supplémentaires et une plateforme qui permet de builder et déployer des applications facilement.
	Metro, le bundler JavaScript pour React Native Metro est un bundler, c’est-à-dire qu’il prend tous les fichiers sources du projet et les compile en un seul fichier de sortie, le « bundle ». Il est capable d’appliquer des étapes de transformation du code ainsi que des conversions d’assets (images par exemple) pour les rendre utilisables dans le code.

Nos besoins

La librairie devra donc répondre aux besoins suivants :

• Export des types TypeScript
• Éviter au maximum la duplication de dépendance pour ne pas alourdir l’application finale
• La librairie doit pouvoir embarquer ses propres assets (images, fonts, etc.)
• La compilation de la librairie doit rester simple et rapide

Les problématiques

Dès le début du développement, plusieurs questions sont apparues :

• Comment va se comporte Metro, le bundler de React Native, avec notre librairie en dépendance ?
• Quelle syntaxe est-il capable de gérer dans le contexte Expo ? ES5 ? ES20xx ? ESNext ? TypeScript ??
• Est-ce que les assets de la librairie seront embarqués correctement dans l’application finale ?
• Comment permettre le partage de dépendances entre l’application et la librairie ?

Gestion des dépendances

À noter que nous utilisons le gestionnaire de paquet Yarn classic (v1). Les autres gestionnaires de paquet comme npm v7+ ou Yarn 2+ peuvent avoir des comportements différents, notamment avec les peerDependencies.

Dans l’environnement node, il existe plusieurs types de dépendances que nous pouvons déclarer dans notre package.json, nous allons nous concentrer sur les trois suivantes :

• dependencies : dépendances directes de notre projet, nécessaire au fonctionnement du programme final
• devDependencies : dépendances seulement nécessaires au développement : outillage de build, de test, de typage, de qualité de code etc.
• peerDependencies : dépendances qui ne sont pas ajoutées par la librairie mais qui doivent être présentes dans le projet cible

Pour rappel, notre problématique ici est que nous souhaitons que l’intégration de notre librairie ne vienne pas alourdir l’application. Il faut que ce soit quasiment transparent en terme de poids et de performance.

Pour ce faire, il faut que la librairie déclare correctement ses dépendances, sinon elles risquent de se retrouver en double dans les modules de l’application finale.

De toute façon, certaines dépendances dites « principales » (par exemple react, react-native ou expo) ne peuvent pas être présentes en double dans les modules, l’application ne pourrait pas fonctionner.

Pour les dépendances dites « utilitaires » (par exemple axios ou date-fns), l’application peut fonctionner avec plusieurs instances de ces dépendances mais elle serait alourdi, ce qu’on nous souhaitons justement éviter.

Pour mieux visualiser la problématique, voici une image qui illustre une mauvaise déclaration de dépendances de la librairie hypothétique « lib-shared-components » :

Les dépendances principales (ici react-native et expo) sont dupliquées, l’application ne pourra probablement pas fonctionner. Et en plus, cette librairie fait exploser le poids total des dépendances.

Maintenant imaginons que la librairie déclare correctement ses dépendances, c’est-à-dire en mettant react-native et expo en peerDependencies, voici le résultat :

La librairie utilisera ainsi les packages react-native et expo déjà présents dans les modules de l’application. Donc pas de problème de duplication ni d’incompatibilité de version.

Plus concrètement, voici à quoi ressemble le package.json de notre librairie :

{
  ...
  "dependencies": {
    "color": "^x.x.x",
    ...
  },
  "peerDependencies": {
    "axios": "^x.x.x",
    "date-fns": "^x.x.x",
    "expo": "^x.x.x",
    "react": "~x.x.x",
    "react-native": "x.x.x",
    "react-native-paper": "^x.x.x",
     ...
  }
}

La dépendance color est un utilitaire utilisé seulement dans la librairie, nous pouvons la laisser dans les dependencies.

Dans les peerDependencies, on a spécifié tous les modules dont la librairie a besoin, ainsi que leur version compatible. La librairie utilisera ainsi les modules déjà en place et ne viendra pas les dupliquer.

Si nous avons tout de même besoin de ces dépendances en mode développement, pour les tests ou pour travailler en isolation par exemple, nous pouvons très bien ajouter ces dépendances dans les devDependencies. Ce type de dépendance ne sera pas ajouté lors de l’installation de la lib par le projet « hôte » et ne risque donc pas de polluer les dépendances de l’application finale.

Maintenant que tout cela est en place, restait à s’assurer que ça fonctionne avec Metro, ce que nous allons voir dans la partie suivante sur le packaging de la librairie.

Packaging de la librairie

Lorsque Metro construit une application React Native, il prend un fichier d’entrée et des options, et sort un seul fichier JavaScript qui contient tout le code et les dépendances. Ce processus contient trois grandes étapes :

• Résolution : construction d’un graphe de tous les modules qui sont requis depuis le point d’entrée.
• Transformation : tous les modules passent par un « transformer », qui est responsable de convertir (transpiler) un module dans un format compréhensible par la plateforme cible (React Native).
• Serialization : fusion de tous les modules transformés dans un seul fichier JavaScript, le bundle.

Habituellement pour des raisons de performance, on ne transforme pas les modules dans le dossier node_modules. Il a donc fallu s’assurer qu’il était possible de configurer les chemins à transformer ou ignorer. Si ce n’est pas possible, la lib devrait être publié dans un format compréhensible par React Native.

Après quelques essais, il se trouve que par défaut, Metro transforme tous les modules. Donc même si notre librairie était publiée en TypeScript directement, l’étape de transformation serait appliquée sur notre module et la compilation se passerait sans problème.

Attention, cela fonctionne car nos applications cibles sont toutes en Expo TypeScript. Si la librairie avait vocation a être distribué plus largement, il faudrait proposer plusieurs formats (ES5, ES2015, TypeScript) pour être compatible avec toutes les configurations.

Notre librairie pourrait donc exposer directement les sources TypeScript, sans étape de build. Mais pour avoir un résultat plus propre et dans les règles de l’art, une étape de build est quand même utile pour effectuer certaines tâches :

• Vérification du typage
• Ne pas exposer les fichiers de test
• Transformer le code TypeScript en JavaScript, ce qui permet d’extraire le typage dans des fichiers séparés

Le compilateur TypeScript (tsc) est capable d’effectuer toutes ces tâches, nous choisissons donc d’utiliser seulement tsc. Pas besoin de se compliquer la vie avec un bundler type Babel ou autre.

Voici à quoi ressemble notre fichier de configuration (tsconfig.json) utilisé pour le build de la librairie :

{
  "compilerOptions": {
    "lib": ["ESNext"],
    "target": "ESNext",
    "moduleResolution": "Node",
    "jsx": "react-jsx",
    "strict": true,
    "declaration": true,
    "outDir": "./dist",
    ...
  },
  "include": ["src/**/*", "assets/**/*"],
  "exclude": ["src/**/__tests__", "src/**/*.test.*"]
}

Avec le fichier de configuration ci-dessus, le compilateur TypeScript se comportera comme ceci :

• il parcours les dossiers src et assets à la recherche de fichiers TypeScript (*.ts et *.tsx)
• il ignore tous les autres types de fichier ainsi que ceux qui matchent les patterns spécifiés dans le champs exclude (tous les fichiers de test dans notre cas)
• pour chaque fichier ts / tsx trouvé, il sort deux fichiers : un fichier JavaScript (.js) dans la syntaxe spécifiée (ESNext) et un fichier de typage (.d.ts)
• les fichiers de sortie sont envoyés dans le dossier dist

DOSSIER SRC		DOSSIER DIST
	COMPILATION

Gestion des assets

Un asset est un fichier qui vit à côté du code source de votre application dont l’application a besoin au moment de l’exécution. Les assets peuvent être des images, des policesdes fichiers audio, etc.

Notre librairie embarque ses propres assets, principalement des images. Ce sont toutes les images que l’on peut retrouver dans l’application finale : des logos, des icônes etc.

Par exemple dans le screenshot ci-dessous, tous les logos de moyen de paiement (encadrés en rouge) sont des images embarquées en tant qu’asset :

La première question est de savoir si Metro sait résoudre correctement nos assets sachant qu’ils se trouvent dans les node_modules, dossier qui peut parfois être exclu de la résolution des assets ?
Après un test, on a pu confirmer que cela ne pose pas de problème, Metro résout par défaut tous les assets quel que soit leur emplacement.

La seconde question est de savoir si Metro va réussir à résoudre nos assets dans la compilation de l’application finale ?
Lorsque nous développons, ce sont les sources du dossier src qui sont utilisées. Par contre en mode production, lorsque la librairie est publiée, seuls les fichiers du dossier dist sont exposés.

Il faut savoir que le compilateur tsc ignore complètement les fichiers qui ne sont pas en TypeScript. Donc si des assets sont présents dans le dossier src, ils ne seront pas copiés dans le dossier de sortie dist.

Une solution serait donc de copier manuellement nos assets dans le dossier dist juste après l’étape de compilation. Cela pourrait être automatisé mais ça reste une étape supplémentaire (qu’on souhaite éviter).

Une seconde solution serait de penser notre structure de dossier pour que la résolution d’asset fonctionne aussi bien depuis le dossier src que depuis le dossier dist, en mettant le dossier assets au même niveau que les dossiers src et dist, comme dans cet exemple :

Comme le montre les deux flèches rouges, qu’on se trouve dans le dossier src ou dans le dossier dist, le chemin relatif vers notre asset « logo.png » est valide donc l’import sera correctement résolu.

Avec cette structure, on peut donc importer des assets de manière relative qui fonctionneront aussi bien en mode développement qu’en mode production. Et cela sans étape supplémentaire au moment de la compilation.

Après quelques tests, nous avons pu confirmer que cette solution fonctionne. La problématique des assets est donc résolue !

Conclusion

• Notre librairie est écrite en TypeScript à 100 % et elle expose le typage de tous ses composants.
• Le partage des dépendances fonctionne entre l’application et la librairie : pas de duplication de dépendance donc pas de surcharge de l’application finale.
• La compilation de la librairie reste simple et rapide (1 seule étape) vu qu’on utilise seulement le compilateur TypeScript.
• Grâce à notre structure de dossier, la gestion des assets dans la librairie ne pose pas de problème. Cela fonctionne aussi bien en mode développement qu’en mode production.

Mise en place d’une librairie de composants métier en React Native – [Introduction]

PayZen

PayZen, c’est la plateforme technique de paiement e-commerce du groupe Lyra. Elle peut gérer plusieurs types de paiement (standard, récurrent, fractionné…) et de nombreux moyens de paiement.

Avec PayZen, le marchand bénéficie d’un accès à un back-office complet qui lui permet de gérer ses transactions, ses boutiques, son paramétrage, etc.

Il a également accès à une application mobile qui lui permet de générer et transmettre des liens de paiement. Ces liens sont envoyés aux acheteurs via de nombreux canaux (mail, SMS, WhatsApp…) pour régler leur achat sur une page de paiement sécurisée.

C’est de cette application mobile qu’il sera question tout au long de ces articles. Application téléchargeable sur App Store et Google Play.

Lyra Collect

Lyra Collect, c’est l’offre « tout-en-un » incluant un contrat d’acceptation (VADS) et une plateforme technique de paiement. Cette offre s’appuie sur un statut d’Établissement de Paiement (EP) certifié par l’ACPR.

Comme sur PayZen, avec Lyra Collect le client bénéficie d’un back-office complet qui lui permet de suivre ses activités.

Il a également accès à une application mobile qui lui permet de consulter les informations essentielles de ses activités depuis n’importe où. C’est de cette application mobile qu’il sera question tout au long de ces articles. Téléchargeable sur App Store et Google Play.

Glossaire

Dans cette série d’articles, je vais utiliser certains termes ou abréviations à de nombreuses reprises :

• librairie ou lib : la librairie de composants
• application ou app : l’application finale, celle qui utilise la librairie
• i18n : internationalisation
• RN : React Native
• RNP : React Native Paper
• ODP : Ordre de paiement (aussi appelé « lien de paiement »)

Petit historique

Des applications web en React

Depuis 2015, Lyra développe toutes ses nouvelles applications web avec React.

Plusieurs back-offices ont ainsi vu le jour dans plusieurs projets. Les techniques, les outils et les méthodes ont évolué, mais React reste aujourd’hui le framework de prédilection pour le développement web à Lyra.

Un effort particulier a été apporté pour le développement du back-office Lyra Collect, avec l’intervention d’un ergonome et d’un designer pour proposer à nos clients un back-office moderne et intuitif.

Des applications mobiles en React Native

En 2019, dans la continuité de cette dynamique, nous avons développé une version simple et intuitive du back-office Lyra Collect sous la forme d’une application mobile.

Après étude des solutions et au vu du besoin, des délais de livraison et des compétences disponibles, il a été décidé de développer l’application avec React Native.

En moins d’un an, l’application a été développée et est disponible sur les stores Apple et Google. Le résultat est positif, autant en termes de rendu final que d’expérience de développement.

En 2020, PayZen souhaite proposer une application mobile à destination des marchands pour leur permettre de générer et partager des liens de paiement.

Logiquement, nous avons décidé de développer cette nouvelle application en React Native pour bénéficier de l’expérience acquise avec l’application Lyra Collect.

Même si le contenu est différent, la structure de cette appli est très proche de celle de Lyra Collect. Beaucoup de composants doivent pouvoir être récupérés.

Le besoin d’une librairie commune

Suite au succès de l’appli PayZen, Lyra a souhaité intégrer la fonctionnalité des liens de paiement dans l’appli Lyra Collect.

Malheureusement, bien que ces applications partagent la même base technique, rien n’était prévu pour partager des composants ou des écrans entiers entre les 2 applications (et non, le copier/coller n’est pas une solution envisageable à l’échelle industrielle  ).

L’idée d’une librairie commune a donc commencé à émerger, mais de nombreuses problématiques restaient à résoudre.

En effet, ces applications sont gérées par des équipes distinctes et communiquent avec leur propre backend, qui ont des URLs et une authentification différente. Le thème aussi est différent, ainsi que les langues supportées.

En résumé, le besoin d’une librairie de composants existait bel et bien, mais plusieurs problématiques devaient d’abord être résolues pour s’assurer de la faisabilité d’une telle librairie. 📚

Dans cette série d’articles, nous allons parcourir les problématiques et présenter les solutions que nous avons apportées.

Objectifs

Le développement d’une librairie commune répondait à deux objectifs principaux :

• Réduire le coût des évolutions et de la maintenance en évitant d’avoir à reporter les modifications dans chacune des applications
• Réduire la duplication de code entre les applications

La particularité de cette librairie est de devoir embarquer de la logique métier. C’est-à-dire que ce n’est pas seulement un ensemble de composants graphiques, c’est une librairie qui pourra fournir des écrans complets, voire même des enchainements d’écrans. Cela implique une plus grande « responsabilité » de la librairie, avec une gestion de navigation, de l’internationalisation, des appels serveurs, etc.  

Problématiques

Aussi, avant même de démarrer ce projet, nous avions plusieurs problématiques à régler pour nous assurer de la faisabilité d’une telle librairie.

Gestion des dépendances dans le contexte React Native / Expo

La librairie embarque de la logique métier, cela veut dire qu’elle sera capable d’afficher des écrans complets, des formulaires, gérer des interactions, etc.

Toutes ces responsabilités nécessitent des dépendances, qui pour la plupart, existent déjà dans les applications existantes.

• Comment gérer les dépendances pour éviter les duplications et ainsi surcharger l’application finale ?
• Comment gérer les versions de ces dépendances et éviter des incompatibilités entre les applis et la librairie ?
• Comment va se comporter le bundler React Native avec notre librairie ? Quel type de packaging mettre en place ?
• Est-ce que le bundler React Native saura résoudre correctement les assets de la lib (des images dans notre cas) ?

L’environnement de développement, l’intégration continue et le déploiement

Enfin, ce que nous souhaitons avant tout, c’est que la mise en place de cette librairie ne dégrade pas l’expérience de développement.

Il faut pouvoir travailler sur son application ou sur la librairie de manière transparente, sans procédure complexe de mise à jour, ou des délais trop longs.

• Comment travailler sur la librairie facilement, sans avoir à déployer tout un environnement d’application ?
• Comment permettre aux développeurs des applications mobiles de continuer à pouvoir développer efficacement, sans ajouter des procédures lourdes et compliquées ?
• Comment et où publier la librairie ?
• Comment gérer l’intégration continue de la librairie et celle des applications qui en dépendent ?

Gestion des personnalisations : le thème, l’internationalisation et les paramètres utilisateur

La librairie doit pouvoir s’adapter aux personnalisations des applications, que ce soit au niveau du thème, de la locale ou à n’importe qu’elle paramétrage spécifique à notre métier.

• Les apps n’ont pas la même charte graphique : comment faire pour que les composants de la librairie respectent le thème de l’application cible ?
• Les apps ne gèrent pas les mêmes langues : comment faire pour que les composants de la librairie supportent toutes les langues possibles ?
• Certains composants de la librairie sont paramétrables : comment intégrer ces paramètres spécifiques à l’écran de paramètres de l’application hôte ?

Gestion des appels serveur et de l’authentification

Comme évoqué précédemment, chaque application communique avec son propre back-end, qui en plus n’utilisent pas les mêmes méthodes d’authentification.

Or, pour certains composants comme la création d’un lien de paiement, la librairie doit effectuer des requêtes serveur.

• Comment savoir sur quelle URL la librairie doit faire ses appels pour communiquer avec les services back-end correspondant ?
• Comment gérer les différentes méthodes d’authentification de manière transparente ?
• Comment respecter les spécifications OpenAPI générées par le back-end ?

Quand on a su que près de 80% de la génération Z écoutait des musiques urbaines créées en France, on s’est immédiatement douté que Best Of Both Worlds aurait plein de choses à nous dire. Le fabricant n°1 de merchandising pour les artistes urbains en France est venu dans nos locaux toulousains lors de notre premier atelier de focus client.

Pour l’anecdote, Best Of Both Worlds c’est le nom d’un album entre 2 artistes qui mélange deux mondes : le RnB et le rap. Le parfait équilibre et le meilleur des 2 mondes. C’est exactement ce que nous allons découvrir à travers l’histoire de cette société et la collaboration qu’ils ont décidé de mener avec Lyra.

Un coup de cœur humain qui restera gravé dans la roche

Best Of Both Worlds c’est une histoire atypique, une relation hors du commun et des compétences spécifiques. Augmentez le son et accélérez le beat,  car c’est le genre d’histoire qu’on entend qu’une seule fois !

Aurélien CONIGLIO, ancien rappeur qu’on pouvait entendre crier sur toutes les  scènes « pose avec le mic, le mic est devenu ma tenue de combat » a décidé de raccrocher le micro pour une autre forme d’expression : créer sa propre marque de vêtement « Woodlife ». Véritable concept à part entière, cette marque de vêtement signe le début de l’histoire de Best Of Both Worlds. En effet, les vêtements imaginés par Aurélien étaient produits et fabriqués dans l’ancienne société de Jérémy JAOUI. Immédiatement, la relation professionnelle entre eux deux se transforme en idylle amicale au point de souhaiter poursuivre l’aventure ensemble.

L’un plutôt créatif et l’autre porté sur la fabrication et la logistique, l’évidence apparaît car l’un cherchait ce que l’autre avait : créons des lignes de vêtements pour les artistes urbains !

Rapidement les commandes défilent à toute vitesse, jusqu’au jour où un artiste leur propose de gérer sa marque de vêtement : c’est là que tout commence vraiment.

1 artiste, puis 2, puis 3… puis le premier artiste d’une longue liste qui va leur proposer de gérer les ventes des précommandes de son album. Best Of Both Worlds rejoint définitivement la cour des grands avec ce contrat. À partir de ce moment, ce n’est plus à eux d’aller démarcher les artistes sur Instagram, mais bel et bien les labels qui prennent contact avec eux pour gérer le merch de plusieurs artistes renommés. Ils sont aujourd’hui une équipe de plus de 15 talents qui œuvrent chaque jour pour faire connaître les artistes d’aujourd’hui et de demain : ligne de vêtement, goodies, site internet… tout est bon pour les mettre en avant.

Une solution de paiement à leur image : réactive et flexible

Dès le début, le besoin d’une solution de paiement s’est fait ressentir. Ils se sont, dans un premier temps, tournés vers des petites solutions qui pouvaient répondre à leur besoin de base. Au fur et à mesure des années, quand Best Of Both Worlds a commencé à prendre de l’ampleur, ils ont alors compris l’importance d’avoir une solution de paiement stable et qui serait en mesure de les accompagner dans leur réussite. Ils se sont alors tournés vers Lyra.

Au-delà d’une histoire et d’une activité atypique, Best Of Both Worlds c’est aussi une organisation pointilleuse et de la rigueur à toute épreuve. En effet, ils ont fait le choix d’une stratégie « print on demand », c’est-à-dire qu’ils ne lancent la production de vêtement que lorsque l’achat a été effectué. Il est donc essentiel pour eux d’avoir un suivi constant et détaillé des commandes et des paiements. Grâce au back office de Lyra Collect, ils peuvent voir en temps réel l’état des paiements (effectués, en cours, refusés) et y mener des actions si besoin. Enfin, les dashboards mis à disposition sur le back office leur permettent d’avoir une vision à 360° de chaque activité.

Au-delà d’une solution de paiement classique, une solution flexible était nécessaire. Proposant un site internet pour chaque lancement d’artiste ou d’album, la quantité de boutiques à gérer s’est multiplié au même rythme que leur succès : rapidement !

Avec plus d’une centaine de boutiques, Lyra a su les convaincre grâce à une gestion intuitive et ultra simplifiée des boutiques. Peu importe le nombre, la solution Lyra leur permet d’avoir une vue globale de chaque boutique tout en pouvant mener des actions spécifiques. Cette flexibilité leur permet de pouvoir jouer avec les tendances et les besoins marché tout en proposant des sites internet et promotionnels ultra rapidement, avec une large palette de moyens de paiement adaptée à leurs cibles.

« Lyra a su s’adapter à notre activité assez atypique et travailler ensemble c’est top. Avoir un relationnel comme celui-ci avec vous et pouvoir vous rencontrer, ça fait vraiment la différence. »

Aurélien CONIGLIO, Directeur Artistique et co-fondateur de Best Of Both Worlds.

De plus, Best Of Both Worlds a l’habitude de travailler avec des pics d’activité : lors de la sortie d’un album ou d’une prévente, l’afflux de visiteurs et les achats se font en masse. La nécessité d’avoir une solution de paiement stable, robuste et réactive devient donc essentielle à leur business. Pour savoir comment bien préparer ses ventes flash ou ses pics d’activité, nous vous invitons à lire nos conseils en cliquant ICI.

Enfin, les 2 co-fondateurs ont eu à cœur d’avoir une solution 100% française, comme leur entreprise, et d’avoir une relation de proximité avec leur solution de paiement pour pouvoir être accompagné comme il se doit.