Jeter les bases : l’architecture du système de conception de TELUS

Points clés à retenir

• Pour desservir une grande équipe, il faut se doter d’un système de conception géré par des ressources attitrées.

•  Le système de conception de TELUS aide les développeurs à bâtir des sites web avec rapidité et uniformité, en accordant une place importante à l’accessibilité.

• L’art de trouver les outils appropriés pour créer un système de conception évolue constamment; de nombreuses versions et améliorations sont inévitables.

• Pour mettre à niveau un système, il est essentiel de former une communauté de développeurs et de concepteurs.
  

TELUS compte sur une équipe grandissante de plus de 1 000 développeurs, concepteurs et rédacteurs. Nos équipes sont réparties aux quatre coins du pays et de la planète, dans plusieurs bureaux et fuseaux horaires.

Depuis 2016, TELUS Digital travaille sur une suite évolutive d’outils, de cadres, de pratiques, de stratégies et de modèles réutilisables. Cette « plateforme numérique », doublée d’une ^{architecture de référence}, a grandement aidé les équipes de produits à livrer des solutions des efficaces et durables. Un des défis posés par la création et la maintenance d’une telle plateforme consiste à permettre aux équipes d’adopter et d’améliorer le système rapidement, sans friction et de manière asynchrone.

Le système de conception de TELUS (SCT) est l’un des produits de notre plateforme numérique. Autour du monde, des entreprises et autres organisations de toutes tailles bâtissent, utilisent et mettent à jour des systèmes de conception pour offrir une expérience utilisateur uniforme lorsque de nouveaux projets voient le jour. Les utilisateurs du SCT profitent de ces avantages grâce à des composants programmés et à notre bibliothèque de composants pour Sketch qui vous est présentée dans un autre article intitulé « Au-delà des guides stylistiques : leçons tirées de la conception évolutive à TELUS[KG1]  ».

Le SCT aide les équipes à créer des expériences accessibles en évitant les répétitions et en respectant la marque.

Équipe principale et valeurs centrales

Comme TELUS produit rapidement des sites web de grande envergure, et que de nouveaux concepts sont mis en production plusieurs fois par jour, le SCT est mis à rude épreuve. TELUS a pour mission de concevoir des solutions formidables en misant sur une équipe tout aussi remarquable.

À titre de produit, le SCT est soutenu par une équipe formée de quatre développeurs, deux concepteurs et un responsable de produits. Grâce à cette équipe chargée de déterminer les besoins des utilisateurs, puis d’élaborer et d’exécuter des solutions novatrices, les résultats souhaités sont toujours à portée de main.

L’aspect humain est un facteur essentiel du développement de logiciels. Les principaux problèmes sont réglés au fur et à mesure au sein de l’équipe principale pour éviter les distractions et motiver tous les membres de l’équipe :

• Nous veillons à ce que chacun suive la feuille de route en tout temps.

• Même si nous préférons habituellement travailler de façon indépendante, nous prenons toujours le temps de nous entraider.

• Toutes les deux semaines, nous faisons le point avec l’équipe et discutons du bien-être et de la satisfaction de chacun.

• Nous rédigeons des récits d’utilisation pour tout le travail effectué, peu importe l’envergure, de façon à ce que les tâches ponctuelles ne s’accumulent pas dans les cahiers de notes des membres de l’équipe.
  

Lorsqu’une équipe dispose techniquement et mentalement des philosophies et des outils requis pour rehausser le rendement, il est possible d’établir les pratiques appropriées et de les intégrer au produit. Ces pratiques influent directement sur les décisions liées au code et à l’architecture.

Architecture des composants centraux

Le système de conception de TELUS propose une gamme de composants programmés conçus pour faciliter la découverte de contenu, l’utilisation et la maintenance à long terme. Lorsqu’un concepteur termine une page dans Sketch, il peut désigner les parties provenant du système de conception (par leur nom). Ainsi, ses collègues peuvent lancer une recherche à la page ^{https://tds.telus.com/}et utiliser le composant dans leurs propres applications. Puisque TELUS adhère au concept de l’^{Inner Source}, chaque personne peut suggérer des changements à même le code.

En août 2017, toute l’équipe a choisi un ensemble d’outils et de cadres pour créer un code de base favorisant le développement rapide des composants les plus utilisés. Comme pour tous les autres projets logiciels à TELUS, nous avons d’abord basé nos décisions sur l’^{architecture de référence}. Voici quelques exemples de ces décisions de
base :

• Bâtir les composants à l’aide de React : Puisque chaque application de TELUS doit être conçue avec React, notre bibliothèque de composants serait principalement consommée par des applications React.

• Effectuer les déploiements au moyen de Red Hat OpenShift.

Une fois ces décisions prises, nous avons pu choisir les outils avec lesquels nous avons bâti la bibliothèque de composants React. En programmant avec React (une bibliothèque JavaScript qui encourage le développement de composants réutilisables), nous avons gardé à l’esprit quelques besoins à combler :

1. Certains de nos sites web (vieux ou récents) offraient des expériences inégales basées librement sur des pratiques établies. En bâtissant des composants centrés sur la conception avec une variation limitée, nous pouvons plus facilement discuter avec les équipes lorsque le système de conception ne fonctionne pas comme prévu.

2. Le SCT doit offrir des interfaces robustes et simples, avec une quantité appropriée de variations, pour convaincre les équipes de développement de l’utiliser à répétition. Ces interfaces accélèrent le développement, rehaussent la satisfaction envers la plateforme numérique, et produisent des expériences utilisateur uniformes à l’échelle de nos nombreux milieux de travail.
   

Composants centrés sur la conception

Un des principaux objectifs du SCT consiste à offrir des composants programmés selon des conceptions approuvées. Prenez l’exemple de ce bouton :

Auparavant, alors que le SCT était formé de feuilles de style en cascade (CSS, en anglais) basées sur des classes, ce bouton pouvait être programmé de la façon suivante :

<button class=”button
button--primary”>Find out how (découvrez comment)</button>

Cet exemple de base ne nécessite que deux classes : « button » et « button--primary ». Même lorsqu’elle est documentée correctement, la programmation ouvre la voie à l’expérimentation humaine. Pour s’afficher dans l’esthétique désirée, les boutons doivent absolument contenir la bonne combinaison de classes, mais qu’advient-il lorsqu’un bouton plus gros est requis? Rien n’empêche un concepteur ou un développeur de programmer ceci :

<button class=”button
button--primary” style=”font-size: 2rem;”>Find out how (découvrez
comment)</button>

TELUS a plus de 1 000 pages web bâties et maintenues par des dizaines d’équipes. En mettant à l’essai le nouveau système de conception basé principalement sur React, nous avons immédiatement déterminé qu’une approche centrée uniquement sur le langage CSS ne serait pas viable à long terme puisque le risque d’erreurs est trop élevé et qu’il est impossible d’effectuer un audit exhaustif. Même si nous pouvions vérifier chaque page manuellement, la tâche serait ardue et purement réactive.

À TELUS, l’approbation des nouvelles conceptions commence par une conversation dirigée par un ou plusieurs concepteurs. Dès que la nouvelle conception a été présentée au responsable, ce dernier la fait approuver par les directeurs de la conception. Les conceptions ainsi approuvées sont consommées et programmées par l’équipe SCT une seule fois. Les équipes de développement peuvent ensuite les utiliser à leur guise, sans avoir à les programmer à nouveau. Ce processus peut sembler bureaucratique, mais n’oubliez pas qu’il est difficile de tenir chaque concepteur au courant des expériences toujours changeantes qui représentent la marque TELUS.

Nous voulions promouvoir un développement axé sur la conception : une fois les conceptions approuvées et en cours de production, les modifications et les nouveaux modèles doivent être approuvés à nouveau par les dirigeants de la conception. Pour veiller à ce que les programmeurs respectent cette consigne, nous avons limité l’utilisation des composants « className » et « style » de React.

Ainsi, seules les variations approuvées du bouton peuvent être programmées, et les développeurs profitent par le fait même d’une interface fiable et simple.

<Button>Find out how (découvrez comment)</Button>
<Button variant="secondary">Submit (soumettre)</Button>

Dans le code React ci-dessus, on remarque que la couleur verte « primary » (principale) s’affiche par défaut et que la variation « secondary » (secondaire) peut être sélectionnée. Au lieu d’avoir à choisir parmi une combinaison de quatre classes CSS, le consommateur n’a qu’à préciser s’il préfère la variation « secondary » (secondaire), « inverted » (inversée), ou « primary » (principale), choisie par défaut. Toutes ces options sont documentées en détail dans le ^{catalogue de composants SCT}.

À cette étape, un ensemble de conceptions atomiques devient un composant : un cas d’utilisation programmé qui ne comporte que des variations approuvées intégrant toutes les mesures d’accessibilités et les fonctionnalités requises, mais dont certaines parties peuvent être personnalisées.

Grâce à ces styles limités, les équipes peuvent être informées des dernières tendances créées par les directeurs de la conception. Par exemple, si un développeur ou un concepteur est insatisfait de l’apparence ou du fonctionnement d’un composant SCT (comme un bouton incapable d’afficher du texte de grande taille), nous pouvons en discuter avec lui au début de la phase de développement, peaufiner la documentation ou les composants, et aider les équipes à améliorer la conception.

Interfaces de composants simples

Les choses simples doivent rester simples, mais les choses complexes doivent être possibles. - Alan Kay

Une interface est simplifiée lorsqu’on peut représenter un groupe de composants complexes au moyen de petites quantités de code tenant compte des mesures d’accessibilité requises, des variations de style et des cas d’utilisation courants. Certains composants comportent des exigences plutôt complexes qui nécessitent parfois plusieurs lignes de code devant être répétées avec précision à l’échelle de nos centaines de pages web. Cette situation ouvre la voie aux erreurs, à une implantation incorrecte ou à des expériences utilisateur inégales.

Prenez par exemple le composant Input (saisie) du système deconception de TELUS. Habituellement, un composant Input avec signalement des erreurs serait programmé de la façon suivante :

<div class=”field field--error”>

<label for=”omitted-field”>

First name (prénom)</label>

<div class=”helper helper--error” id=”omitted-field-error”> <strong>

First name is required. (le prénom est requis)</strong> </div>

<div class=”field__control”> <input type=”text” id=”omitted-field” placeholder=”First name” (prénom) aria describedb=”omitted-field-error” aria-invalid=”true”> </div>

</div>

Si un développeur avait à reproduire ce flux de saisie à l’aide d’une bibliothèque CSS, il serait chargé des propriétés « label », de la position et de l’état du message d’erreur, et des attributs « aria-* ». Une grande quantité de code devrait être reproduite dans des centaines de pages web, ce qui pourrait compromettre la marque et l’expérience utilisateur. Chacun de ces composants peut être intégré à un composant React :

<Input label=”First name”
(prénom) error=”First name is required” (le prénom est requis) />

En une seule ligne de code, un développeur peut configurer les propriétés « label » et le message d’erreur pour composer un composant Input avec l’état et les attributs d’accessibilité appropriés. La propriété « label » est aussi obligatoire, ce qui reflète l’approche axée sur la conception que nous adoptons pour créer des interfaces de composants simples.

Avec une interface de composants simple, les erreurs sont moins fréquentes, les détails de l’implantation sont confiés à l’équipe SCT, le processus de développement est plus rapide et les expériences utilisateur sont uniformes. Des fonctionnalités d’accessibilité sont aussi intégrées aux composants SCT. Les visiteurs peuvent ainsi utiliser des lecteurs d’écran, des claviers ou d’autres interfaces homme-ordinateur pour optimiser leur expérience de navigation. Autre avantage : les développeurs peuvent mettre à niveau les divers composants (comme Input) pratiquement sans avoir à réécrire le code.

Évolution de l’architecture

En août 2017, nous avons commencé à bâtir de nouveaux composants SCT basés sur React, c’est-à-dire un paquet npm contenant des composants hautement réutilisables pour les sites web destinés aux clients. Nous avons initialement encouragé les équipes à utiliser ces nouveaux composants React et à abandonner l’ancienne bibliothèque CSS dès que possible pour bâtir des sites web plus facilement et uniformément. À chaque version du SCT, nous avons lancé un nouveau composant React, puis déprécié toutes les classes CSS connexes en les supprimant quelques versions plus tard. Ainsi, les équipes souhaitant faire une mise à niveau doivent revoir les classes CSS utilisées à intervalle de quelques versions.

Avec une nouvelle version lancée toutes les deux semaines, nous avons continuellement ajouté de nouveaux composants React et apporté de temps à autre des modifications avec rupture à l’ancienne bibliothèque CSS. Après quelques mois, nous avons recueilli les commentaires des responsables de la technologie et des développeurs de TELUS Digital qui consommaient des composants du SCT. Le modèle de modification avec rupture aux deux semaines a été critiqué :

1. La plupart des équipes n’avaient pas toujours le temps d’effectuer les nombreuses mises à niveau du SCT.

2. Les correctifs apportés aux composants dans le cadre d’une version précédente étaient plus difficiles à consommer puisqu’il fallait parfois refactorer du contenu en raison d’autres changements avec rupture.

3. Les équipes voulaient contribuer au SCT, mais l’équipe principale ne leur accordait pas suffisamment de temps pour réviser les conceptions ou le code.
   

Certains logiciels notoires tels que React ont établi des pratiques acceptables au sujet de la cadence des versions. Par exemple, React lance une nouvelle version majeure environ tous les ans. Si React apportait des changements avec rupture toutes les deux semaines, des milliers de développeurs seraient incapables de garder le fil, et abandonneraient peut-être l’outil. Cette leçon s’applique aussi aux systèmes de conception d’une grande équipe : les utilisateurs doivent disposer d’un délai raisonnable pour effectuer la mise à niveau, et être prévenus lorsque des modifications avec rupture sont prévues.

Au fil de toutes les versions lancées dans le SCT, des défauts ont été repérés par les utilisateurs. Ces défauts ont été corrigés dans des versions subséquentes du SCT, mais ces nouvelles versions comportaient elles-mêmes des modifications avec rupture. Jetez un coup d’œil à cet extrait du journal des changements survenus entre les versions v0.20.0 et v0.28.2 :

• 0.20.0 : fonction (14 août 2017) lancement du nouveau composant Button (bouton)

• 0.21.1 : fonction ajout de la variation « inverted » (inversé) au bouton

• 0.25.0 : modification avec rupture suppression de l’ancien bouton CSS

• 0.26.0 : modification avec rupture suppression des propriétés de nom de classe et de styles dans le composant Card (carte)

• 0.27.0 : modification avec rupture suppression de l’ancien lien CSS

• 0.28.0 : modification avec rupture suppression de l’ancienne typographie CSS

• 0.28.1 : correctif correction de l’alignement horizontal du bouton dans Safari

• 0.28.2 : correctif (6 novembre 2017) ajout d’une espace manquante au bouton

Lorsqu’une équipe adoptait la version v0.20.0 du SCT, mais qu’elle n’effectuait aucune mise à niveau jusqu’à la version v0.28.2, elle se retrouvait avec plusieurs modifications avec rupture non liée au composant du bouton. Au cours de ce cycle de vie, il était impossible de recevoir des correctifs pour des composants précis sans produire un effet sur les autres, ce qui est devenu une embûche importante pour notre paquet SCT monolithique.

Même si les modifications avec rupture étaient communiquées correctement au moyen d’avertissements dans le code et d’annonces, les équipes ne pouvaient pas toujours accorder la priorité au SCT. À l’inverse, si les équipes avaient adopté chaque version du SCT dès le lancement, elles auraient eu à refactorer beaucoup de contenu toutes les deux semaines, et auraient manqué de temps pour effectuer toutes leurs autres tâches.

Adopter une cadence acceptable

Après avoir digéré les commentaires de chacun, nous avons décidé de reporter toutes les modifications avec rupture apportées à la bibliothèque CSS jusqu’au lancement de la version v1.0.0. La version 1.0.0 comportait un paquet monolithique de 36 composants « centraux » et aucune des classes CSS globales des versions précédentes. Nous avons lancé le ^{SCT v1.0.0} le 30 janvier 2018 et les équipes ont pu effectuer la mise à niveau en sachant qu’elles ne feraient face à aucune modification avec rupture jusqu’à que nous séparions les composants en paquets indépendants.

Enfin, les équipes souhaitaient ajouter davantage de composants au SCT puisqu’elles trouvaient utile d’avoir accès à un dépôt de composants réutilisables. L’équipe principale ne pouvait pas gérer des centaines de composants à elle seule. Nous avons donc créé une bibliothèque de composants communautaire dont nous discuterons vers la fin de cet article.

État actuel de l’architecture des composants centraux du SCT

Le 8 mars 2018, nous avons lancé les composants « ^Split » (indépendants), une collection de modules npm (Node Package Manager) sous l’espace de nom @tds/core-*. Les composants indépendants sont une réponse directe à l’embûche créée par un paquet monolithique : les équipes étaient incapables de gérer la mise à niveau de composants individuels sans nuire à d’autres composants par mégarde. Avec des composants indépendants, les développeurs peuvent mettre à niveau leurs composants un à la fois, sans toucher les autres composants de leur application.

Nous avons commencé à développer des composants avec React en août 2017. Depuis, nous avons utilisé les outils ci-dessous pour bâtir un code de base efficace, un catalogue de composants comportant des propriétés autodocumentées, des guides rédigés à la main et du code CSS reflétant la portée. En plus de lancer les composants indépendants, nous avons adopté Lerna.

• ^Styleguidist : Un environnement isolé de développement de composants avec un guide stylistique dynamique.

• ^Rollup : Un outil de mise en lot de modules JavaScript (semblable à webpack), conçu pour les modules ES2015 et optimisé pour les bibliothèques.

• ^ES2015+ : Nous rédigeons tout le code JavaScript sous forme de modules ES2015 (en suivant habituellement les guides stylistiques exhaustifs d’AirBnb sur JavaScript et React), puis nous le transpilons avec Babel pour les navigateurs.

• ^Jest et ^Enzyme : Nous utilisons Jest à titre de gestionnaire des essais, et Enzyme pour mettre à l’essai les composants React.

• Linters et Prettier : Normalisation du style et du format du code.

• ^{CSS Modules} : Cet outil facilite l’accumulation des composants CSS visés tout en conservant l’interface familière de Sass.

• ^Yarn : Nous avons choisi Yarn comme gestionnaire de paquets en raison de sa rapidité et de sa fonction approfondie de verrouillage des dépendances des versions.

• ^Openshift et ^Docker : Le flux d’intégration continue est largement basé sur la trousse de démarrage isomorphe, et nous utilisons Docker à titre d’artéfact.

• ^Lerna : Un outil utilisé pour gérer des projets JavaScript comportant plusieurs paquets.

Avantages et inconvénients des outils dignes de mention

En août 2017, nous avons choisi React Styleguidist comme générateur de documentation en raison de ses configurations riches en fonctions. Nous pouvons ainsi transformer la documentation rédigée dans Markdown avec nos propres composants typographiques pour lui donner l’esthétique de la marque TELUS. Il est particulièrement utile de documenter PropTypes à l’aide de JSDoc à même les composants du code source, et de générer les tableaux Prop avec Styleguidist automatiquement. De cette façon, nous pouvons utiliser le code à titre de documentation et éviter les doublons et les oublis potentiels.

En tant qu’outil de catalogage, Styleguidist est formidable puisqu’il présente tous nos composants dans une seule page. Il peut aussi interpréter les commentaires dans le code pour produire des tableaux d’utilisation relatifs à chaque composant. Ainsi, nous n’avons qu’à documenter le code une seule fois pour qu’il s’affiche dans le catalogue final. Toutefois, puisque le nombre de composants ne cesse d’augmenter et qu’il est de plus en plus important de communiquer leur qualité, nous chercherons éventuellement d’autres solutions de catalogage mieux adaptées à nos besoins. Par exemple, nos développeurs doivent être en mesure de revenir à la documentation des anciennes versions d’un composant, les concepteurs doivent avoir accès aux éléments Sketch, et chacun doit comprendre les mesures entreprises pour veiller à ce que les composants soient performants, accessibles et approuvés par la direction.

Rollup a été adopté au début du processus en raison de sa fonction d’optimisation du code importé qui nous aide à réduire la taille des composants. L’équipe principale s’efforce toujours d’optimiser le rendement et de chercher des façons de créer des composants plus compacts et plus performants.

Les modules CSS se sont avérés très utiles lorsque nous avons abandonné les styles Sass préexistants. Quand un composant importe des styles à partir d’un module CSS, il génère un nom de classe visé. Par exemple, lorsque le composant Button importe le nom de classe « primary » (principal), il génère un nom de classe unique : « TDS_BaseButton-modules__primary__2lxya ». Dans une page web donnée, les noms de classe générés sont injectés dans le code, mais l’ordre dans lequel ils apparaissent est indéterminé. Par conséquent, lorsque nous créons des composants de plus haut niveau tels que FlexGrid, il n’existe aucune façon simple de modifier les styles d’un composant « enveloppé » (wrapped).

Nous évaluons actuellement des solutions « CSS dans JSDoc » pour déterminer s’il est possible d’insérer du langage CSS dans les composants tout en réduisant le volume du langage CSS inclus dans les paquets de composants sans compromettre le rendement de la page.

Enfin, Lerna nous aide à orchestrer le versionnage, la rédaction des journaux de changements, la gestion des dépendances des pairs et le processus de déploiement de notre collection grandissante de composants React. Il s’agit d’un outil très puissant, mais sa courbe d’apprentissage est ardue. À l’aide de^{Commits Conventionnels}, nous avons pu insérer un commit dans les modifications avec rupture, les fonctions ou les correctifs. Lerna s’est ensuite chargé d’analyser ces commits pour repérer les sauts de version. Pour y arriver, nous avons dû faire preuve d’un peu de discipline et faire appel à ^Commitlint. Nous avons suivi les règles suivantes :

1. Insérer des commits dans les fichiers d’une seule portée. Si un commit comprend des changements apportés au composant Button, il ne doit inclure aucun changement touchant d’autres composants.

2. Définir la portée de façon à ce qu’elle soit comprise par Lerna. Par exemple, un commit de fonction qui change la couleur d’un paquet intitulé « @tds/core-button » doit respecter le format : feat(core-button): change colour.

3. Effectuer des demandes d’extraction et révéler quels composants seront modifiés et à quelle version. Pour ce faire, nous avons créé un script générant les sauts de version repérés par Lerna.
   

Grâce à ces règles, nous pouvons aisément modifier des composants individuels et nous attendre à ce qu’ils exécutent la publication et les sauts de version de façon prévisible. Le commit cité en exemple dans les règles ci-dessus générerait le saut de version suivant (si la version actuelle du composant Button est v.1.1.1) :

Changements : - @tds/core-button: 1.1.1 => 1.2.0

N’hésitez pas à jeter un coup d’œil à notre code de base à la page ^{tds-core dans GitHub}.

Composants communautaires, architecture partagée et prochaines étapes

Avec des composants versionnés de façon indépendante, les équipes peuvent désormais séparer les préoccupations liées à chaque composant et faire des mises à niveau à leur guise. Même si les composants centraux sont employés dans toutes les applications frontales de TELUS, bon nombre d’équipes utilisent leurs propres composants spécialisés et modérément réutilisables. Ces composants spécialisés sont appelés « composants communautaires », et ils sont gouvernés librement par une guilde : les ambassadeurs de la plateforme numérique. Jack traitera bientôt de ce sujet en détail dans un article de blogue intitulé « Système de conception de TELUS : bâtir une communauté ». Les composants communautaires du SCT sont appuyés par un modèle de gouvernance distribuée où des représentants à l’extérieur de l’équipe principale peuvent approuver la modification des composants. Cette décision a été prise parce que l’équipe principale n’avait pas le temps de veiller à la maintenance de tous ces composants.

Les composants communautaires sont bâtis et versionnés dans un monodépôt avec les outils utilisés dans tds-core. À l’aide de Lerna, les composants communautaires sont publiés dans npm sous le nom d’espace @tds/community-*. L’ensemble des discussions, des feuilles de route et du code source est hébergé dans un dépôt centralisé. De cette façon, nous pouvons répliquer ces changements dans ^{tds community} lorsque l’architecture de tds-core évolue.

Notre prochain objectif consiste à relever les défis d’évolutivité majeurs auxquels le système de conception fait face :

• Rehausser le rendement des composants en minimisant les ensembles javascript et en optimisant l’utilisation du langage CSS. Puisque les composants sont utilisés dans des centaines de pages, même une économie de quelques millisecondes peut se traduire par une réduction de plusieurs heures par jour. Ces efforts sont essentiels pour offrir des pages plus rapides aux clients et réduire les dépenses de TELUS associées aux serveurs.

• Les équipes d’assurance de la qualité utilisent la dernière version des composants en automatisant les avis de mise à niveau et en développant des outils de refactorage au besoin. Pour produire des expériences uniformes, les équipes doivent toujours utiliser la dernière version du SCT – et nous sommes en voie de simplifier ce processus.

• Réconcilier l’écart entre les composants des concepteurs et ceux de React en les combinant pour créer une seule et véritable source sur le plan des variations et des dimensions. En réduisant le temps requis pour passer de la conception à la programmation, nous pourrons créer des versions plus uniformes.

• Mettre en cache les composants dans tous les sites web de TELUS, de façon à ce que les visiteurs n’aient qu’à les télécharger une seule fois lorsqu’ils naviguent d’une page à l’autre. Même si ce sujet touche le rendement des pages, il est essentiel de bien gérer les widgets des sites qui consomment également le SCT. Quand ces widgets sont utilisés, leurs styles peuvent produire des effets indésirables sur le reste d’une page en raison des dérogations au style, et nous devons tout faire pour éviter de telles situations.

Nous sommes ravis de continuer de faire progresser l’architecture du système de conception de TELUS dans le but de faciliter l’adoption, d’accélérer le développement et de créer des expériences clients uniformes et plaisantes.