Lyra a récemment interviewé Yaël, fondatrice des Babilleuses, une structure spécialisée dans la confection consciente et la commercialisation de coussins de maternité. Depuis son premier coussin réalisé en 2005, son entreprise n’a cessé de grandir jusqu’à s’adresser à une clientèle internationale. D’abord française, cette clientèle s’est révélée être particulièrement intéressée par la qualité, le confort et le large choix de ces coussins.

Proposer des moyens de paiement adaptés à différentes typologies de consommation est une solution optimale pour faire évoluer son commerce et Yael nous explique pourquoi.

Découvrons ensemble l’évolution des Babilleuses et l’impact qu’a eu Lyra en tant que solution de paiement.

Une histoire écrite du bout des doigts

Les Babilleuses a son histoire, l’histoire de toute une vie. Couturière de profession, puis maman, sa fondatrice réalise qu’on n’est finalement jamais mieux servi que par soi-même ! De quelques coussins à l’émergence d’un réel besoin dans son entourage, Yael se prend au jeu. Quelques calculs, un peu (beaucoup) d’organisation, et de précieux conseils donnés par des sage-femmes et ses premiers coussins voient le jour.

De fils en aiguilles, les coussins se perfectionnent, séduisent et la demande explose.

Un site internet devient essentiel pour faciliter la visibilité puis la commercialisation. Rapidement la question du paiement se pose. C’est au travers d’une conversation avec l’un de ses collaborateurs que Lyra ressort comme solution de paiement.

Quoi de mieux qu’une solution française et des valeurs en accord avec sa démarche ? Les Babilleuses choisit de faire confiance à Lyra pour ses paiements, et ça dure depuis 14 ans.

Un patchwork de moyens de paiement pour une clientèle internationale

« Avoir un bon produit n’est plus suffisant, il faut aussi avoir les bons moyens de paiement »

Yaël, fondatrice des Babilleuses

Future maman, futur papa, meilleure amie ou bientôt tatie… Difficile de choisir un coussin quand on n’y connaît rien. Face à ce constat, Les Babilleuses pense et conçoit une application mobile, avec un concept et un processus d’achat simplifié : on choisit un coussin parmi les best-of et l’achat se fait en quelques clics !

Après quelques temps, les nouveaux modes de consommation sonnent le besoin d’agrandir cet éventail de moyens de paiement : plus l’achat est rapide, mieux c’est et la réponse est très simple grâce à Apple Pay.

Fort de sa popularité, le site Les Babilleuses arrive jusqu’à chez nos voisins belges. L’international devient alors un nouveau cap.

En échange régulier avec l’Espagne et la Suisse. Les Babilleuses devrait encore élargir son expansion grâce à Bizum le moyen de paiement préféré des Espagnols, et Twint celui des Suisses, qui sont prévus chez Lyra d’ici peu…

L’automne est bien entamé et les besoins d’évasion se font déjà ressentir. Pour replonger dans une nouvelle vague à l’esprit de vacances, nous avons rencontré Julien, fondateur de Mon Fourgon Shop. Boutique en ligne d’équipements pour les particuliers qui aménagent des vans sur-mesure (isolation, électricité, fenêtres, collage etc.).
L’activité est récente et le catalogue de cesse de prendre de l’ampleur. La brique du paiement a été bien pensée par Julien puisqu’il a su considérer l’importance d’un parcours d’achat simple, efficace et sans rupture dès le début de son activité. Le meilleur moment pour déjà envisager le paiement de demain c’est bien dès le démarrage !

Un choix local pour une conso raisonnée

Locale et recommandée, 2 qualités premières pour Lyra qui ont su séduire le fondateur de cette société toulousaine. S’en suit un accompagnement commercial disponible et sur-mesure pour aider cette nouvelle société à prendre la route vers de nouveaux horizons.

Une fois bien engagé, il y a des objectifs à ne pas prendre à la légère. Comme la rapidité et la mobilité que ce soit du côté des clients que de l’aboutissement de la commande. Récemment, en intégrant Apple Pay et le prélèvement SEPA Julien et son équipe assurent à leurs clients de régler plus facilement tous les types de paniers pour être équipé en un temps record !

Avec Apple Pay, des résultats qui parlent d’eux-mêmes !

Des paniers inférieurs à 100€ pour la spontanéité, aux paniers plus élevés pour être rassuré, Apple Pay a su s’imposer.

Apple Pay représente déjà un beau pourcentage de nos paiements pour un moyen de paiement qu’on propose en plus à nos clients. Avec du recul, je sais que la conversion et le confort du client passent par les moyens de paiement qu’on peut proposer 

Julien SATGÉ, fondateur de Mon Fourgon Shop

Pour continuer sur cette belle lancée, Julien suit de très près toutes les évolutions Lyra. Notamment grâce à notre rendez-vous webinar L’instant Paiement et nos newsletters. Il sait que toutes les nouvelles fonctionnalités sont avant tout pensées et développées pour des structures qui en ont besoin avant les autres ! C’est ça de vouloir dépasser à vitesse grand V.

Pour conclure cette série d’articles, reprenons les objectifs et les différentes solutions apportées.

L’objectif principal est le développement d’une librairie de composants React Native, dans le but de mutualiser des composants de deux applications : PayZen et Lyra Collect.

La difficulté principale étant que certains composants peuvent être de haut niveau, quasiment des écrans entiers. C’est-à-dire qu’ils embarquent de la logique métier : des appels serveurs, de la navigation entre plusieurs écrans, des paramètres utilisateurs etc.

Reprenons les principales problématiques ainsi que les solutions apportées :

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

• L’utilisation des peerDependencies permet de mutualiser les dépendances
• On a pu démontrer une configuration qui fonctionne avec le bundler Metro (au niveau du code source et des assets)
• La librairie est écrite en TypeScript et tout le typage est bien exporté
• La compilation de la librairie est simple et rapide

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

• Bonne expérience de développement, tout l’outillage fonctionne comme avant (refresh de composant à chaud, debugger, inspecteur d’éléments etc.)
• Le développeur continue de tester son application, qu’il travail sur la librairie ou sur son application
• Linking de la librairie en local très facile
• Intégration continue et déploiement avec Bitrise

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

• Passage de paramètres et création d’un contexte grâce à un composant Provider
• Possibilité de personnaliser le thème, les traductions et la configuration de la librairie
• Les paramètres des composants de la lib peuvent être intégré dans l’écran des préférences de l’application

Gestion des appels serveur et de l’authentification

• Utilisation d’un client HTTP (Axios) qui permet d’embarquer la configuration des appels serveurs (URL de base, authentification etc.)
• La librairie est capable d’effectuer des appels serveurs avec des urls relatives
• La gestion des tokens d’authentification et de l’URL du back-end restent de la responsabilité des applications, la librairie ne s’en occupe pas
• Le déploiement de la brique « API Proxy » côté Lyra Collect permet d’accéder aux API de PayZen depuis l’app Lyra Collect
• Les appels REST sont validés par les specs OpenAPI fournies par le back-end

Les grands principes à retenir

• Librairie écrite en TypeScript
• Elle expose un composant Provider qui lui permet d’accepter des paramètres et d’initialiser les librairies utilitaires
  • React Native Paper pour le thème
  • I18n-js pour l’internationalisation
  • Axios pour les appels HTTP

L’objectif principal de cette librairie est d’apporter les fonctionnalités liées aux ordres de paiement de l’application PayZen dans l’application Lyra Collect. Mettre ces écrans dans une librairie nous permet de mutualiser le code et facilite la maintenance.

Les ordres (aussi appelés liens) de paiement, sont des liens générés par le marchand qu’ils peuvent envoyer à leur client pour se faire payer. Ces liens amènent vers la page de paiement PayZen du marchant avec toutes les informations de paiement pré-remplies.

Voici quelques exemples d’écrans pour les ordres de paiement (liste, détail, création) :

Dans les articles précédents, nous avons répondu aux problématiques liées aux dépendances, à l’environnement de développement et aux personnalisations.

Il nous reste un sujet à aborder, qui est spécifique aux écrans des ordres de paiement, ce sont les appels serveurs et l’authentification.

En effet, la librairie expose des composants de haut niveau qui peuvent être des écrans complets :

• PaymentOrderList : écran complet de la liste des ordres de paiement, avec ses propres appels serveur
• PaymentOrderDetail : écran complet du détail d’un ordre de paiement, avec ses propres appels serveur
• PaymentOrderCreation : enchainement d’écrans pour la création d’un ordre de paiement, avec ses propres appels serveur
• PaymentOrderSettings : section de paramètres des ordres de paiement

L’architecture de nos services

Nos deux applications communiquent avec leur back-end respectif (donc URL différentes) qui ont chacun leur méthode d’authentification spécifique.

• Côté PayZen, c’est une authentification à base de cookie et de tokens.
• Côté Lyra Collect, l’authentification s’appuie sur RH-SSO (Keycloak), à base de Bearer Token.

Ce qu’il faut savoir, c’est que la plateforme Lyra Collect se base sur la solution PayZen. Et les ordres de paiement sont une notion portée par PayZen.

Donc pour l’app PayZen, aucun problème avec les ordres de paiement : elle communique avec son back-end, et l’authentification est naturellement gérée.

Par contre pour l’application Lyra Collect, il faut communiquer directement avec le back-end PayZen (sauf à devoir dupliquer l’API des Ordres de Paiement sur Lyra Collect, ce que nous voulons justement éviter).Et bien entendu, il n’est pas souhaitable de gérer plusieurs authentifications sur l’application Lyra Collect (une pour les fonctionnalités des Ordres de Paiement, l’autre pour le reste de l’application).

En revanche, les systèmes d’information Lyra Collect et PayZen communiquent très bien entre eux car ils sont hébergés au sein de la plateforme Lyra.

L’idée est donc d’ajouter une brique de proxy d’API devant le back-end Lyra Collect qui aura les rôles suivant :

1. authentifier l’utilisateur Lyra Collect avec RH-SSO
2. transférer l’appel vers PayZen en lui adjoignant les paramètres d’authentification (PayZen) correspondant

Voici un schéma simplifié qui illustre l’architecture cible. En vert l’existant, en orange les nouveaux composants :

La gestion des appels serveurs dans la librairie

Une fois ces modules en place, la problématique suivante est : comment la librairie va pouvoir effectuer ses requêtes alors qu’elle ne connait ni l’URL du serveur ni la méthode d’authentification à configurer ?

En effet, elle est utilisée à la fois dans l’application Lyra Collect (qui communique avec le backend Lyra-Collect) et PayZen (qui communique… oui, avec le backend PayZen).

Et ce que nous voulons éviter, c’est qu’à chaque appel, la librairie fasse quelque chose comme :

Première hypothèse

Au début, nous avons imaginé que les applications passent des paramètres au niveau du Provider de la librairie :

• baseURL : l’URL de base à utiliser pour tous les appels
• mode : EP / VAD selon le mode d’authentification à utiliser
• token : le token d’authentification

Ce qui donnerait :

import Axios from 'axios'
 
// création de l'instance Axios
export const axios = Axios.create({
  baseURL: 'https://api.example.com',
})

import { useContext, useLayoutEffect, useRef } from 'react'
import { SessionContext } from '../contexts/SessionContext'
import { axios } from './axios'
 
export function useAuthInterceptor() {
  // on récupère le token depuis un contexte
  const { accessToken } = useContext(SessionContext)
  // stockage de l'identifiant de l'intercepteur dans une référence React
  const reqInterceptor = useRef<number>()
 
  useLayoutEffect(() => {
    // si l'interceptor existe déjà, on le libère
    if (reqInterceptor.current !== undefined) {
      axios.interceptors.request.eject(reqInterceptor.current)
    }
 
    // déclaration d'un nouvel intercepteur de requête, appelé avant chaque requête
    reqInterceptor.current = axios.interceptors.request.use((config) => {
      if (accessToken && config.headers) {
        // configuration du header Authorization de la requête
        config.headers.Authorization = `Bearer ${accessToken}`
      }
 
      // on retourne la config modifiée
      return config
    })
 
    return () => {
      // au nettoyage, on libère l'intercepteur
      if (reqInterceptor.current !== undefined) {
        axios.interceptors.request.eject(reqInterceptor.current)
      }
    }
  }, [accessToken])
}

import { Provider } from '@lyra/shared-components'
import { axios, useAuthInterceptor } from './rest'
import { Root } from './components/Root'
 
export const App = () => {
  // initialisation de notre intercepteur d'authentification
  useAuthInterceptor()
 
  return (
    <Provider axios={axios}>
      <Root />
    </Provider>
   )
}

import { useContext } from 'react'
import { ConfigContext } from '../contexts/ConfigContext'
 
export const FooComponent = () => {
  const { axios } = useContext(ConfigContext)
  const result = axios.get('/path/to/resource')
  ...
}

{
  "withSeparateModelsAndApi": true,
  "apiPackage": "api",
  "modelPackage": "model",
  "useSingleRequestParameter": true,
  "enumPropertyNaming": "UPPERCASE",
  "stringEnums": true
}

npx @openapitools/openapi-generator-cli generate -g typescript-axios -c openapi-generator.config.json -i payment-order.yaml -o src/openapi/payment-order

import { useContext } from 'react'
import { ConfigContext } from '../contexts/ConfigContext'
import { PaymentOrderApi, Configuration } from '../openapi/payment-order'
 
export const PaymentOrderList = () => {
  const { axios } = useContext(ConfigContext)
 
  // récupération du basePath depuis l'instance axios
  const basePath = axios.defaults.baseURL
 
  // création d'une configuration et d'un client d'API avec les objets générés
  const configuration = new Configuration({ basePath })
  const paymentOrderApi = new PaymentOrderApi(configuration, basePath, axios)
 
  // on peut maintenant utiliser notre API qui va effectuer les requêtes en utilisant l'instance axios passée en config
  const result = paymentOrderApi.findPaymentOrder({
    page: 1,
    perPage: 10,
    minAmount: 42,
  })
 
  ...
}

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.