JoliCode blog - derniers articles au sujet de "react"

React Advanced London (depuis nos canapés)

2022-11-15T13:42:00+01:00

Nous avons eu la chance de pouvoir assister à la conférence React Advanced London en remote, voici ce que nous en avons retenu de ces deux jours intenses !

React internals

C’était le slogan de la conférence cette année : "We will be diving deep" et nous n’avons pas été déçues. Plusieurs conférenciers nous ont parlé de ce qui se passe réellement sous le capot quand on utilise React.

"Understanding React’s Fiber Architecture" - Tejas Kumar

Tejas Kumar nous a expliqué en plongeant dans le code le fonctionnement de React Fiber, le nouvel algorithme de réconciliation, introduit dans React 16 pour rendre notre librairie préférée plus rapide et performante. Résumé grossièrement, les Fiber sont une sorte de structure de données, que React conserve pour garder une trace de ce qui se passe dans nos applications. Elles ont donc une durée de vie longue par opposition aux Element qui eux sont éphémères. Fiber Reconcilier, l’algorithme de réconciliation, maintient en permanence deux arbres, le courant et le "work in progress", boucle sur tous nos composants en partant du haut pour détecter ce qui a changé, ajoute des flags sur ce qui doit être mis à jour, ce qui changé, etc. puis bascule sur le deuxième arbre qui devient alors la nouvelle source de vérité. Il réconcilie ensuite cet arbre avec l’environnement hôte (navigateur, application mobile) pour mettre à jour l’UI. Cette nouvelle architecture permet ainsi un rendu incrémentiel de nos applications.

Ainsi décortiqué, le fonctionnement interne de React ne semble plus si complexe. Une plongée passionnante à voir dès qu’elle sera disponible. En attendant nous vous recommandons sa conférence Deconstructing React si vous n’avez pas encore eu l’occasion de la voir).

Deep diving on concurrent React - Matheus Albuquerque

Durant l’exécution de certaines tâches trop longues, le thread principal de JavaScript se retrouve bloqué. Ces blocages sont gênants, d’autant plus pour les utilisateurs sur mobile pour qui ils peuvent durer 7 à 12 fois plus longtemps. Il s’agit d’un problème réel, qui en plus d’être désagréable pour vos utilisateurs a également un fort impact sur le taux de conversion de vos applications. Pour éviter de bloquer le thread principal, il existe trois stratégies principales : le parallélisme, l’exécution concurrente et le scheduling (planification).

React 18 introduit des nouveautés intéressantes sur le sujet. Nous pourrons par exemple traiter plus efficacement les gros volumes de données en priorisant les render (grâce à l’API startTransition), limiter les renders inutiles avec le hook useSyncExternalStore, prioriser le chargement des zones d’interaction pour diminuer le first input delay (hydration sélective) ou encore monitorer les performances des applications grâce au profiler qui sera capable d’indiquer quelles opérations trop gourmandes pourraient bénéficier de startTransition.

Matheus a conclu avec quelques mises en garde, le scheduling n’implique pas forcément de meilleures performances et il n’y a pas de solution miracle. Il faut identifier les métriques qui sont fondamentales pour nos applications et partir de là. Enfin il a brièvement évoqué le futur de React : un composant built-in <Cache> pour la récupération de données, à utiliser avec <Suspense>.

Composition

Code Crimes For Good Component API - Siddharth Kshetrapal

Quelles sont les qualités d'une bonne interface utilisateur ? Elle doit être intuitive, accessible et cohérente. Il en va de même pour l’API de nos composants. Siddharth Kshetrapal nous a expliqué à travers plusieurs exemples comment il fait en sorte, quitte à utiliser quelques hacks, que ses APIs de composants respectent ce contrat.

La leçon que nous en retenons est le fil rouge de la conférence :

Ce qui donne en français : les hacks qui rendent le code plus facile à lire et à modifier, et qui aident les développeurs à faire du bon travail rapidement, en respectant des contraintes raisonnables du système, sont ok.

React Slots: a New Way of Composition - Neo Nie

Qui ne s’est pas retrouvé un jour à devoir maintenir un composant TextInput avec plus d’une quinzaine de props, ou un composant Message qui gère une dizaine de cas d’usages différents ? Neo Nie a fait un état des lieux des problèmes inhérents à la composition avec React que nous avons tous rencontrés au moins une fois dans notre carrière.

Ces différents problèmes l’ont amené à s’intéresser aux différents patterns de composition qui existent, et notamment à l’utilisation dans React du pattern Slots.

Ce pattern permet de définir des sortes de placeholder, identifiés par un attribut unique, dans un template et qui peuvent être utilisés ensuite pour définir n’importe quel contenu. Vous avez probablement déjà utilisé ce pattern sans même le savoir, à chaque fois que vous utilisez des props nommées pour rendre des parties d’un composant.

const TextInput = ({ name, error, label }) => (
<div className="form-group">
	<span className="form-label">{label}</>
<input type="text" name={name} />
{error && <span className="form-error">{error}</span>}
</div>

Ici, error et label sont des slots. Pour mettre en place les slots dans ses projets, Neo a créé la librairie create-slots qui s’utilise en définissant des slots et des hosts (un composant qui a un layout formé de plusieurs slots).

La librairie est encore relativement jeune mais le concept semble prometteur. À suivre !

Accessibilité

Creating an Accessible Web Together in 5 Simple Steps - Shruti Kapoor

Shruti Kapoor nous a présenté ses astuces pour un Web plus accessible. Après avoir rappelé l’importance de l’accessibilité, elle nous offre un moyen mnémotechnique avec l’acronyme STARK pour se souvenir de 5 choses à toujours garder en mémoire :

S pour Semantic HTML : utiliser les balises qui correspondent à ce que vous en faites (button pour des actions, a pour des liens, mais aussi nav, header, main…) et bien les utiliser (une balise a a toujours un href, img a un alt, ne pas créer de "faux" titres en CSS). Les lecteurs d’écrans risqueraient autrement de donner la mauvaise information à leurs utilisateurs. Utiliser les balises natives à bon escient vous offre donc une accessibilité à bas coût.

T pour tabindex : Il est important de définir un tab order logique. Par ailleurs Shruti rappelle que le tabindex ne doit pas être supérieur à 0, pour ne pas perdre les lecteurs d’écran. Il est possible de débugger son tab order avec Firefox par exemple.

A pour Aria tags : label, aria-described-by, checked, expanded, haserrormessage, aria-hidden… Nous ne les présentons plus et pourtant nous ne pensons pas toujours à les utiliser. Chez JoliCode, nous aimons aussi les utiliser dans notre CSS, ce qui permet de ne pas les oublier et de faire d’une pierre deux coups !

R pour Role : attribut à utiliser dès lors que nous ne pouvons pas utiliser les balises natives qui correspondent à notre besoin

Enfin K pour Keyboard navigation & screen readers : il faut toujours s’assurer par exemple que le focus est visible à l'écran. Shruti recommande de tester soi-même en utilisant seulement tab, la barre d’espace, Enter et Echap.

Elle nous recommande ensuite quelques outils pour faire nos tests, les extensions navigateurs aXe et Wave, les outils intégrés à Firefox ou à Chrome, les outils au build comme axe-core ou jsx-a11y, ou encore l’outil de CI accesslint pour identifier les soucis d'accessibilité directement dans les PRs GitHub.

N’hésitez pas également à tester la navigation clavier, les lecteurs d’écran, et les tests automatisés. Enfin rien ne vaut un test avec des utilisateurs réels.

Nous pouvons même aller plus loin en proposant des raccourcis clavier pratiques pour l’édition, ou encore des focus trap dans certaines zones de l’application.

Tips et bonnes pratiques

The Weird Things About React - Nik Graf

Cette conférence est l’occasion de souligner certaines bizarreries de React, connues ou moins connues, à commencer par les versions de React, passées brutalement de 0.14.7 à 15.0.0 (pour l’explication c’est par ici), mais aussi de nous donner quelques protips pour utiliser React. Saviez-vous par exemple qu’il est possible d’utiliser la prop key pour forcer un composant à être remonté ? On y apprend aussi qu’on peut utiliser la fonction flushSync pour re-rendre de manière synchrone lorsque nous recevons une mise à jour de données (pas encore documenté mais discuté par exemple ici), que React 18 autorise nos composants à renvoyer undefined ou encore que les hooks peuvent être utilisés conditionnellement, à condition d’ignorer le warning de React (mais c’est mal, ne faites pas ça chez vous). Il est également possible de tricher pour utiliser un export nommé avec React.lazy().

Le type React.FunctionComponent (et son alias React.FC) souvent décrié par les développeurs TypeScript pour sa prop children implicite, perd cette prop en React 18, ce qui veut dire que nous pouvons maintenant l’utiliser avec une prop children obligatoire.

En conclusion de sa conférence, Nik nous a présenté react-reduce-stress, une petite librairie qu’il a développé et qui permet de masquer certains warnings et erreurs de React comme le fameux warning sur l’ordre des hooks ou encore celui du mode strict de React 18 qui nous informe que les useEffect seront exécutés 2 fois au premier rendu d’un composant. Nous ne pouvons que vous conseiller au passage de tester le mode strict de React 18 pour détecter les composants qui ne sont pas à jour et les effets de bord.

Using useEffect Effectively - David Khourshid

Dans cette très bonne conférence, David Khourshid nous réapprend à utiliser useEffect, ou plutôt ce que nous devrions utiliser à la place et dans quelles situations :

Nous n’avons pas besoin de useEffect pour transformer de la donnée. Il vaut mieux utiliser un useMemo ou mieux, n’utiliser aucun hook et passer à useMemo seulement en cas de problème de performance avéré ;
Pas de useEffect non plus pour communiquer avec le parent. Dans ce cas mieux vaut exécuter notre effet directement dans la gestion de l’évènement ;
Pas de useEffect pour souscrire à un store externe. L’injustement méconnu useSyncExternalStore est là pour ça ;
Pas besoin de useEffect pour fetcher de la donnée. La librairie react-query dispose de hooks terriblement efficaces pour ça, avec Next.js on peut également utiliser useSWR() ou simplement use() avec du cache ;
Initialiser un singleton global (configurer un client Axios, s’authentifier sur un store externe, etc) sera plus efficace sans useEffect, en-dehors du composant ;
Enfin, n’utilisez pas useEffect pour gérer les actions de l’utilisateur. Il vaut bien mieux exécuter les effets dans les event handler directement. Nous pouvons par exemple utiliser une state machine :

De manière générale, useEffect doit être utilisé pour les effets "d’activité", pour la synchronisation. Pour les effets "d’action" il est plus adapté (et souvent plus simple) de les mettre au plus près des événements qui les causent, ce qui implique souvent de ne pas utiliser useEffect.

Treat Your Users Right with Segmented Rendering - Eric Burel

Toutes nos applications rencontrent un jour des problématiques de personnalisation ou segmentation, que ce soit pour les adapter à différentes langues, à différents types d’utilisateurs (payants ou non), pour mettre en place de l’A/B testing, etc. C’est pourquoi il est nécessaire de pouvoir rendre du contenu adapté à l’utilisateur actuel. La plupart de nos frameworks JavaScript actuels proposent différents modes de rendu plus ou moins statiques pour améliorer les performances. Comment en tirer profit tout en évitant d’avoir des invités riches et des clients pauvres (bonnes performances seulement pour les utilisateurs non payants qui ne nécessitent pas de personnalisation) ? Eric Burel nous propose une solution simple et facile à mettre en place. Dans l’exemple de Next.js, le contenu peut être rendu côté serveur, côté client ou dans un mode intermédiaire "static site generation". Les deux premiers modes sont dynamiques mais lents, alors que le dernier est très performant, mais comme son nom l’indique il est statique.

Une solution possible est d’utiliser des URLs avec des paramètres différents pour chaque segment mais cela pose de nombreux autres problèmes, le paramètre est visible par les utilisateurs, les URLs peuvent être changées à la main et elles peuvent vite devenir très longues.

La deuxième solution est d’utiliser un serveur proxy qui lit un cookie (ou un header par exemple) et réécrit l’url. La réécriture n’étant pas une redirection, l’utilisateur ne peut ni voir ni modifier l’URL. Avec Next.js, le serveur proxy est un simple middleware.

Une bonne astuce à garder en mémoire pour tous vos problèmes de personnalisation.

Performances

Automated Performance Regression Testing with Reassure - Michał Pierzchała

Michał part d’un constat auquel nous avons tous dû faire face un jour : les performances de nos applications tendent naturellement à se dégrader avec le temps et les développements successifs. Il est donc important de mettre en place des tests de non-régression des performances, au moins sur les parties qui risquent le plus d’impacter nos utilisateurs.

En analysant la fréquence de chacune des principales causes des problèmes de performance, il lui est apparu assez clairement que la plupart des problèmes sont liés à JavaScript plutôt qu’à React ou à React Native.

Ne trouvant pas de librairie de test adaptée à son besoin assez spécifique, Michał a choisi de créer sa propre librairie : reassur. Celle-ci a donc été conçue pour s’intégrer avec les librairies de tests existantes afin de tester les performances des render, en mesurant leur durée et leur nombre. Elle permet aussi de générer des rapports, et s'intègre avec les CI les plus connues. Les tests de performance sont lancés sur la branche courante et sur la branche principale et les résultats sont comparés en utilisant l’analyse statistique.

Écrire les tests est relativement simple, il suffit de copier un test fonctionnel et d’y ajouter quelques lignes de code.

La présentation de la librairie était très convaincante, nous avons hâte de la tester chez nous !

TypeScript

TypeScript and React: Secrets of a Happy Marriage - Matt Pocock

Cette conférence nous a particulièrement intéressées. Matt Pocock expose certains des problèmes que tout utilisateur de TypeScript rencontre un jour et nous en donne une solution élégante. En voici quelques uns :

Le typing dynamique, qui consiste à avoir une variable pouvant être soit un type A soit un type B, peut poser des problèmes lorsque l’on cherche à accéder à une propriété spécifique à un des deux types :

La solution est d’utiliser l’opérateur in, par exemple if (‘href’ in props) , TypeScript saura grâce à ce test que nos props sont d’un certain type.

Deux props qui dépendent toutes les deux du même type, que nous ne pouvons pas connaître à l’avance, par exemple row: unknow[] et renderRow: (row: unknow) => React.ReactNode. La solution ici est d’utiliser les types génériques. En plus, lorsque nous ne spécifions pas le type TRow, celui-ci sera inféré automatiquement par TypeScript.

Nous pouvons aussi utiliser extends pour forcer certaines propriétés :

Les types de React sont écrits et maintenus en dehors de la lib, dans @types/react et ils peuvent parfois présenter de légères différences qui peuvent être ennuyantes. Par ailleurs certaines fonctions comme les hooks useState et useRef ont différents overloads, c’est-à-dire qu’ils ont plusieurs signatures et les types inférés par TypeScript dépendent de l’overload utilisé :

Par ailleurs certains de ces comportements peuvent paraître incohérents, par exemple, ne pas fournir de valeur initiale pour useRef va inférer un type number | undefined. Pour ne pas être perdu face à ces différences, la meilleure solution reste de bien comprendre le fonctionnement de ces fonctions, n’hésitez donc pas à aller jeter un oeil aux types !

L’expérience du remote

Regarder des conférences depuis le confort de son canapé est certes appréciable, mais plusieurs aspects des conférences live nous ont toutefois un peu manqué. Assister à des conférences c’est aussi l’occasion de discuter avec d’autres développeurs de tous horizons, et même si les organisateurs avaient fait de leur mieux pour nous proposer différentes plateformes et réseaux, il reste plus difficile d’aller vers les autres en remote qu’en live.

Concernant les conférences elles-mêmes, celles-ci étaient retransmises en décalé par rapport à la programmation live, du début d’après-midi jusqu’à assez tard dans la soirée, un point vraiment négatif pour les spectateurs qui ont des contraintes familiales par exemple. Il aurait probablement été plus judicieux de faire plusieurs streams en horaires décalés pour permettre à la majorité des timezones de suivre toutes les conférences. Heureusement, l’ensemble des conférences ainsi que les workshops gratuits devraient être rendus disponibles en vidéo.

Une timeline en temps réel très pratique était mise à disposition sur le site de React Advanced, avec les streams des deux tracks de conférence. C’était également appréciable de pouvoir mettre une conférence en pause ou revenir un peu en arrière pour mieux comprendre un point spécifique. En revanche nous avons toutes deux trouvé qu’il était assez difficile de se concentrer, à cause des distractions inévitables de l’ordinateur mais aussi du "bruit" présent dans les streams eux-mêmes. Les vidéos contenaient beaucoup d’informations sur les conférences à venir, les tweets en rapport avec l’évènement, etc. qui venaient un peu polluer l’expérience.

Dernier point regrettable, pas de vélotypie sur les streams, ce qui aurait pourtant été un gros plus en termes d’accessibilité, ainsi que pour ceux dont l’anglais n’est pas la langue maternelle.

Conclusion

Une grosse partie des conférences était dédiée à React Native mais, étant toutes deux plutôt tournées développement Web, nous avons préféré assister aux conférences qui nous concernaient le plus.

Des ateliers gratuits en remote sur des demi-journées étaient proposés aux participants sur des thèmes comme TypeScript ou React-Query.

Dans l’ensemble ces deux jours de conférence ont été riches en enseignements, on espère pouvoir y assister à nouveau l’année prochaine et pourquoi pas vous y croiser !

Nos meetups d'automne en Suisse 🏔️🇨🇭

2018-11-23T13:49:00+01:00

Depuis notre installation à Lausanne en février dernier, nous avons noué des liens avec plusieurs acteurs du Web en Suisse Romande. L'occasion pour nous de partager nos expériences lors de meetups, comme nous le faisons déjà en France depuis la création de JoliCode.

Après Grégoire et Damien en juin dernier, c'était au tour de Vincent et Mathieu de partager leurs connaissances. Revenons ensemble sur ces 2 événements !

31 octobre - Les animations avec Lottie par Vincent

Voir cette publication sur Instagram

Nous sommes aujourd’hui à l’@epflcampus pour animer le brown bag lunch d’Halloween 🎃. Merci à l’équipe de #laforge pour votre accueil ! Si vous souhaitez construire de super animations dans vos projets Web et mobiles, envoyez-nous un petit mot 👋🏼 #lottie #react #javascript #lausanne

Une publication partagée par JoliCode (@jolicode) le 31 Oct. 2018 à 4 :55 PDT

Ce talk fut un retour d’expérience de Vincent (frontend & React-Native Developer) sur Lottie, un outil créé par Airbnb. Cette librairie open source permet d’inclure et d’exploiter des animations After Effects au format json. Elle offre un contrôle total sur celles-ci et la possibilité de les intégrer facilement dans une interface. Si vous souhaitez construire rapidement de super animations dans vos projets Web et mobiles, n’hésitez pas à consulter les slides de la conférence : vous y trouverez notamment des exemples et quelques mots sur LottieFiles.

Une présentation pour deux éditions : celle du midi s’est déroulée au Brownbag lunch Halloween organisée à La Forge, EPFL Innovation Park. Merci Marine Favre pour l’organisation ! Le soir, cela se passait du côté du meetup Frontend Romandie, organisé par Kévin Wenger et hébergé par Antistatique. Merci à eux !

🗒 Slides

21 novembre - Traduire efficacement une application Web par Mathieu

C’est dans le grand espace Gotham Gare que se déroulait le Meetup. Mathieu y présentait son retour d'expérience sur la traduction d'une application PHP.

La traduction est une étape cruciale de la réalisation d'un projet Web. Elle l'est d'autant plus en Suisse, où près de 90% des créations Web nécessitent d'être localisées dans au moins deux langues. Cependant, sa mise en place est souvent douloureuse et reste compliquée tout au long de la vie de l'application. Un nouveau type d'intervenant entre en jeu, en plus des développeurs, chefs de projets, designers, voici maintenant les traducteurs.

Fort de son expérience pendant le projet Ouibus, Mathieu nous a fait part des problèmes rencontrés couramment lors de la traduction d'un projet web, mais surtout des solutions que l'on peut mettre en place pour contrer ces problèmes. Parmi elles, nous trouvons notamment l'importance d'outiller correctement son projet et surtout de trouver le bon outil pour le bon intervenant ; un traducteur n'a pas envie de mettre les mains dans un fichier XML contenant les clés de traduction, il préférera avoir un outil pourvu d'une interface graphique, facile à appréhender.

Après la présentation, un quiz était proposé au public avec 8 questions portant sur les points les plus importants abordés précédemment. Le gagnant est reparti avec le livre de Bastien sur la Dette Technique !

🗒 Slides

En 2019 : fusion des meetups PHP User Groupe Romand et Frontend Romandie

Grande nouveauté ! Kévin Wenger a annoncé la future fusion de ces deux entités en une seule : les Webmardi. L’objectif est d’unir les forces de ces deux communautés pour proposer des événements toujours de plus grande qualité, qui favorisent l’échange d’expertises et le partage. Une nouvelle identité graphique, un cycle de 11 rendez-vous et un nouveau format (open mic, stream live, kahoot! game, etc.) sont attendus.

Merci encore aux organisateurs pour ces événements ! On ne peut que vous inviter à rejoindre le traditionnel Webmardi de fin d’année qui aura lieu le 4 décembre, et qui se terminera par une fondue à l'Évêché #legrascestlavie 🧀 . 2019 est bientôt là, nous avons hâte de discuter avec vous de PHP, Symfony ainsi que de JavaScript, React / React Native, Docker, Elasticsearch, RabbitMQ ou bien encore Go, nos thèmes de prédilection ❤️.

N’hésitez pas à venir nous rencontrer dans nos bureaux Lausannois, nous nous ferons un plaisir de partager un café avec vous !

Bye bye ! 👋

Retours de React Europe 2018

2018-06-11T13:42:00+02:00

Il y a 5 ans, Facebook ajouta sa contribution à l’écosystème JavaScript en publiant la première version de React. Depuis cette dernière s’est hissée au rang des incontournables, dépassant son simple rôle de librairie.

React ❤️

React est aujourd’hui un vrai écosystème à part entière : nouveaux paradigmes, révolution de l’expérience de développement. Un écosystème qui s’est étendu jusqu’au développement mobile avec React Native. Il fédère une communauté éclectique et passionnée : développeurs back / front, designers, développeurs mobiles, apportant chaque jour de nouvelles contributions.

Nous étions présents à la 4ème édition de React Europe à Paris pour rencontrer, écouter, discuter avec cette belle communauté dont nous faisons partie depuis maintenant deux ans.

Les conférences

Bonne nouvelle, l’ensemble des conférences a été filmé et diffusé en direct 🔴, vous pouvez retrouver l’intégralité des talks sur les playlists suivantes :

Aucune excuse donc pour ne pas être au courant des dernières nouveautés, pour les plus pressés, voici un résumé de quelques talks qui nous ont plu.

Keynote : New hotness in React

🐦https://twitter.com/ken_wheeler 🍿https://www.youtube.com/watch?v=QFk6YwMz8nc

La conférence s’est ouverte sur la keynote énergisante de Ken Wheeler (à la tête de FormidableLabs, qui a entre autre développé Spectacle) passant en revue les dernières nouveautés de React.

Au menu, une piqûre de rappel sur la nouvelle Context API, nouveaux événements de composants (dépréciation de componentWillReceiveProps en faveur de getDerivedStateFromProps), mise en pratique de la fameuse API Suspense. Cette dernière, présentée par Dan Abramov lors de la JSConf Iceland a été mergée dans la branche master, hold your horses ! Pour rappel, Suspense permet de mettre en pause le rendu de composant lors d’appels asynchrones et gérer plus finement les états de chargement et mise en cache.

The Case for Whimsy

🐦https://twitter.com/joshwcomeau 🍿https://www.youtube.com/watch?v=Z2d9rw9RwyE

Joshua est un nostalgique de l’internet des années 90 où les pages arboraient leurs plus beaux wordart et GIFs. Il souhaite revenir à un internet fun mais qui a du sens sans délaisser l’accessibilité.

Son talk montre l’exploration effectuée pour trouver des animations performantes et satisfaisante pour l’utilisateur. Le premier cas est une animation canvas pour créer des confettis lors du succès d’un quizz Khan Academy dont il est l'un des développeurs. Il détaille particulièrement l’implémentation utilisant les lifecycles des composants ainsi que la synchronisation du rendu de React avec les « animations frames ».

Le deuxième exemple consiste en une animation lancée par l’utilisateur (action driven) du DOM pour un client mail via la manipulation du DOM avec React et du CSS. L’API qui en résulte est claire et abstraite, ce qui permet à ces animations d’être appliquées facilement à n’importe quels composants.

Josh finalise son talk sur les améliorations à venir quant aux animations CSS avec Firefox Web Render. Celui-ci utilise l’accélération matérielle pour toutes les propriétés ! Enfin, il recentre notre attention sur l’accessibilité et l’utilisation d’animations avec parcimonie. Celles-ci doivent ajouter une réelle plus-value.

Declarative future of gestures and animations in React Native

🐦https://twitter.com/joshwcomeau 🍿https://youtu.be/kdq4z2708VM

L'animation avec React Native est un sujet fréquent, de nombreuses publications pour reproduire des interfaces connues comme l’application Tinder ou encore Uber existent.

Krzysztof Magiera (co-créateur de React Native) nous explique la manière dont sont implémentées les animations. Souvent synonyme de mauvaises performances car définies dans notre code JS, certaines ne peuvent pas être liées directement à des propriétés natives, ce qui force des aller/retour sur le bridge React Native. Le moniteur de performance nous permet de suivre les frames par seconde de chaque thread et ainsi voir l’impact d’une animation sur les performances.

Ceci devient encore plus complexe quand l’on veut synchroniser des gestes avec un effet d’animation. Par exemple au scroll d’une ListView. Pour pallier ces différents problèmes, Krzysztof a créé le module react-native-gesture-handler qui est maintenant disponible automatiquement dans Expo. En plus de proposer une API simple autour du driver natif d’animation, plusieurs composants sont implémentés pour créer un comportement « Swipeable » ou une navigation de type « drawer ».

A Journey through React Apollo

🐦https://twitter.com/peggyrayzis 🍿https://www.youtube.com/watch?v=fCXYA3lZTbo

Apollo manages updating your data just like React manages updating your UI

GraphQL fut à l’honneur pendant ces deux journées de conférences, notamment par l’intermédiaire de Peggy Rayzis, core team d’Apollo. Celle-ci nous a présenté les dernières fonctionnalités en rappelant les promesses du produit :

Plus besoin de Redux pour vos données serveur ;
Plus besoin de normalisation via Normalizr ;
Plus besoin de typage / PropType.

Elle a conclu son talk en présentant le futur d’Apollo avec sa version 3. Les nouveautés résident principalement sur l’intégration de la nouvelle API Suspense.

Replicated Redux

🐦https://twitter.com/jimpurbrick 🍿https://youtu.be/Fr3vp0C22H0

Jim Purbrick nous a livré un talk inspirant, sortant des usages traditionnels de React : l’intégration de Redux dans une architecture multi-clients. En effet, Redux, de par son architecture, est idéal pour répliquer les actions au travers de différents clients en les dispatchant. Jim, lead-developpeur de ReactVR nous a montré comment répondre aux problématiques de synchronisation, anticipation, concepts que l’on retrouve dans le Netcode.

Beyond React

🐦https://twitter.com/dvnabbott 🍿https://youtu.be/HVwLOcllTfI

Cette conférence nous fait réfléchir à l’approche composant et à notre manière de travailler avec ceux-ci. En effet la plupart du temps une équipe dédiée au design va travailler avec des outils spécifiques comme Sketch ou Illustrator puis, d’autres personnes vont créer des composants React. Hélas il n’y a pas de piliers communs entre ces deux équipes. C’est la problématique que cherche à résoudre Lona, l’outil présenté dans ce talk. Doté d’un UI builder, d’un format standard et d’un compilateur vers du code React/JSX, il devient possible de compiler des UIs en composants React. Nous avons hâte d’essayer sur un petit projet pour renforcer la liaison entre nos équipes.

Bridging React Native Back to its Roots

🥇Prix de la meilleur démo 2018 🐦https://twitter.com/dvnabbott 🍿https://youtu.be/aOWIJ4Mgb2k

La conférence la plus impressionnante de cette édition, était celle de Vincent. Ce dernier est revenu sur les différences d’implémentation entre React et React Native (navigation, layout…) avant de proposer son postulat : pourquoi ne pourrait-on pas fusionner ces deux implémentations ? Une application React Native serait compatible web « out of the box ».

C'est déjà la promesse de react-native-web, mais pour Vincent, celle-ci a ses limites :

Implémentation du layout (via flex) différente ;
react-native-web est "web first" ;
Différents systèmes de build ;
Une grosse partie de l'API de RN manquante.

Pour pallier ces limites, Vincent a développé un portage de React Native pour le web. Introducing react-native-dom ✨. La promesse est un support à 100% de l'API avec le même système de build (metro). La librairie n'est pas encore exploitable en production mais tient de très belles promesses. Vous pouvez suivre l'évolution du support de l'API de React Native ici : https://rntester.now.sh/.

L'organisation

Comme son nom l’indique, React Europe est le plus gros événement européen React qui par chance a lieu depuis son lancement à Paris. C’est une très belle occasion de rencontrer la communauté et faire le plein de motivation.

Les conférences de 30 minutes suivent un bon rythme (environ 4 le matin et 6 l’après-midi), le tout ponctué de quelques pauses cerveau/café, rendent l’ensemble dynamique et sans temps morts. Comme d’habitude les petits-déjeuner, déjeuner (et même diner pour le jeudi soir) sont excellents, attention tout de même aux verres de vin / bières en trop le midi, effet sieste garanti 🍷.

Et ensuite ?

Les différentes conférences de cette édition 2018, remontent quelques tendances :

La volonté de convergence entre React et React Native ;
Améliorer l'expérience développeur ;
GraphQL comme nouveau standard pour les APIs ;
L'insoutenable attente de l'API Suspense. 🙌

De nouveaux enjeux et défis donc pour la communauté React qui n'a cessé d'en relever ! À l'année prochaine ! 👋

Handling dependencies conflict and locking in React Native

2018-01-10T09:42:00+01:00

UPDATE 08/2018 : This article is deprecated, you can now handle this very easily with native dependency locking with Gradle >= 4.8.

Developing React Native apps is fast and enjoyable because we rarely have to deal with the native part of the application thanks to all the native modules available. Sadly, sometimes we encounter issues very close to the iOS or Android native development side. Recently, we came across a module conflict and locking issue on Android.

The problem

The app we were working on is dependent on many native modules and specifically these two:

🗂 /app/android/app/build.gradle

dependencies {
	...
    compile project(':react-native-firebase-analytics')
    compile project(':react-native-onesignal')

Which gives us, after trying to build… 💥

:app:transformClassesWithJarMergingForDebug FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:transformClassesWithJarMergingForDebug'.
> com.android.build.api.transform.TransformException: java.util.zip.ZipException: duplicate entry: com/google/android/gms/common/api/internal/zzcc.class

After some googling and browsing some stackoverflow issues, it seems that this is linked to a conflicting library, sadly not much more information is available about where to look.

Gradle has a nice command to display the dependency tree that might help us.

$ ./gradlew app:dependencies
+--- project :react-native-firebase-analytics
|    +--- com.facebook.react:react-native:+ -> 0.48.4 (*)
|    +--- com.google.firebase:firebase-core:+ -> 11.4.0
|    |    \--- com.google.firebase:firebase-analytics:11.4.0
|    |         +--- com.google.firebase:firebase-common:11.4.0
|    |         |    +--- com.google.android.gms:play-services-basement:11.4.0
...
|    \--- com.google.firebase:firebase-analytics:+ -> 11.4.0 (*)
+--- project :react-native-onesignal
|    +--- com.facebook.react:react-native:+ -> 0.48.4 (*)
|    +--- com.onesignal:OneSignal:3.+ -> 3.6.5
|    +--- com.google.android.gms:play-services-gcm:+ -> 11.0.2
|    |    +--- com.google.android.gms:play-services-base:11.0.2
|    |    |    +--- com.google.android.gms:play-services-basement:11.0.2 (*)

We can see that both react-native-firebase-analytics and react-native-onesignal depends on com.google.android.gms:play-services-basement but with different versions.

The solution

Via Gradle, we can exclude the conflicting module com.google.android.gm from both our dependencies like so and then ask for a specific version. This also prevents including too many libs from Google play services in our APK (less bundled code, yeah!).

dependencies {
    compile(project(':react-native-firebase-analytics')) {
        exclude group: 'com.google.android.gms'
    }
    compile(project(':react-native-onesignal')) {
        exclude group: 'com.google.android.gms'
    }
    compile 'com.google.android.gms:play-services-gcm:11.4.0'
    compile 'com.google.android.gms:play-services-basement:11.4.0'

Locking Android dependencies

After solving the conflict and trying to compile again a few weeks later, we got the same issue back without any native code modification of our app! 💥

This time the Gradle command showed us this:

+--- project :react-native-onesignal
|    +--- com.facebook.react:react-native:+ -> 0.48.4 (*)
|    \--- com.onesignal:OneSignal:3.+ -> 3.6.5
+--- project :react-native-firebase-analytics
|    +--- com.facebook.react:react-native:+ -> 0.48.4 (*)
|    +--- com.google.firebase:firebase-core:+ -> 11.6.0
|    |    \--- com.google.firebase:firebase-analytics:11.6.0
|    |         +--- com.google.firebase:firebase-common:11.6.0
|    |         |    +--- com.google.android.gms:play-services-basement:11.6.0
+--- com.google.android.gms:play-services-basement:11.4.0 -> 11.6.0 (*)

react-native-onesignal still got the dependency excluded but com.google.firebase:firebase-core now requires the 11.6.0 version. Since the dependency is not explicitly locked by the module, gradle resolves it with the latest version available.

Changing these two lines to require the latest version fixed the issue, but just until the next release of the firebase module...

compile 'com.google.android.gms:play-services-gcm:11.4.0'
    compile 'com.google.android.gms:play-services-basement:11.4.0'

On a JavaScript project, we usually go with yarn or npm to manage dependencies. Thankfully, since yarn came out, we got a nice yarn.lock file to lock our dependencies and the npm equivalent package-lock.json. Gradle has no built-in system for this but Netflix solved it with a nice plugin.

To use this plugin, add this at the top of your android/app/build.gradle:

apply plugin: 'nebula.dependency-lock'

and this to android/build.gradle:

dependencies {
    classpath 'com.netflix.nebula:gradle-dependency-lock-plugin:4.+'

then the command cd android && ./gradlew generateLock saveLock will generate a nice android/app/dependencies.lock that you can add to git to be sure to always have the same dependencies on every installation.

Native knowledges are always nice to have while working on a React Native project, those tips will improve the stability of your project with strict reproducible builds. We are glad to only had this problem on Android since it seems way more complicated on iOS.

Resources

Marier React et Symfony

2017-08-02T14:30:00+02:00

Cet article fait suite à notre conférence "Comment marier Symfony et React ?" présentée au PHP Tour 2017.

On ne présente plus React, framework JavaScript bien connu et à la pointe de la mode depuis 2 ans déjà. Les tutoriels / articles pour créer votre projet en React ne manquent pas sur les Internets : on crée une API, puis un front full React pour la consommer. Ce n’est donc pas cette approche que nous vous proposons de discuter ici mais plutôt comment utiliser React dans un projet Symfony existant, sans nécessairement découpler les deux.

Pour ce faire, nous retenons deux solutions :

utiliser React directement ;
utiliser LimeniusReactBundle.

Les deux méthodes sont similaires sur beaucoup d’aspects, la qualité principale de LimeniusReactBundle sera de vous permettre de mettre facilement en place le rendu serveur de vos composants, ainsi que d’avoir accès à des extensions Twig pour faciliter l’intégration de React dans vos templates.

Mais commençons par le commencement. React, on ne le présente plus certes, mais chacun n’est pas familier pour autant avec ses concepts de base. Ceux-ci peuvent se résumer (grosso modo) en trois points :

des composants écrits en JSX ;
qui ont des props et un state ;
un algorithme de réconciliation.

Si vous connaissez déjà React, aller directement à la partie React et Symfony.

Pour la suite de cet article, nous allons choisir un exemple simple : la réalisation d’une todo list. Les spécifications sont les suivantes : afficher une liste de choses à faire ; pouvoir marquer un élément de la liste comme "fait" afin qu’il disparaisse de la liste ; le tout dans une page déjà écrite avec Twig ; avec des données (éléments de la liste) provenant d’un contrôleur Symfony.

React en bref

Grands principes : réconciliation et DOM virtuel

Pour agir sur l’affichage dans le navigateur, React utilise un système de DOM virtuel, combiné à un algorithme de différenciation : la réconciliation. Concrètement, chaque élément du DOM ainsi que son état dans le DOM physique du navigateur est répercuté dans un DOM virtuel construit par React. Voici un schéma explicatif :

Quand une modification survient, du côté du navigateur (l’utilisateur clique sur un bouton (1)) cela déclenche un événement (2) que React écoute et utilise son algorithme pour calculer la différence entre le DOM physique et le DOM virtuel (3). Il génère ainsi un certain nombre d’opérations à effectuer pour réconcilier ces deux états, les synchroniser, puis applique (4) ces modifications grâce à l’API DOM du navigateur.

Une modification peut survenir directement du côté de React (un appel à une API renvoie une liste d’éléments qui sera affichée), dans ce cas on est directement dans l’étape (3).

À savoir : Alors que l’algorithme de réconciliation est partie intégrante de la librairie React, le DOM virtuel ne provient pas à proprement parler de React mais de ReactDOM. Dans le cas de React Native, on utilise d’autres méthodes pour appliquer les modifications générées par l’algo, puisqu’une application mobile ne fonctionne pas grâce à un DOM. Le principe reste cependant le même.

Les composants

Une application React peut être représentée par un ensemble de composants imbriqués les uns dans les autres. L’intérêt majeur de cette architecture est qu’elle permet d’avoir des "morceaux de code" réutilisables. On va donc écrire nos composants en se basant sur un postulat simple : une responsabilité (même mineure) = un composant.

Reprenons notre exemple, on veut afficher une liste de choses à faire, avec un bouton permettant de marquer un élément comme fait. On aura donc trois composants :

le composant parent qui représente la liste de choses à faire (TodoList) ;
le composant qui représente une chose à faire (Todo) ;
le composant qui représente le bouton d’action (TodoButton).

Chacun de ces composants implémente la méthode render() qui définit le rendu de ce composant. Ce rendu peut-être constitué de code HTML (ou plutôt pseudo-HTML, grâce à JSX) et/ou d’autres composants imbriqués.

class TodoList extends Component {
  render() {
    return (
      <div className="well">
        {/* code du rendu */}
      </div>
    );
  }
}

Le rendu d’un composant à un instant t dépend de deux sources de données : les props et le state.

Les props et le state

On peut comparer un composant à une fonction, qui reçoit des paramètres (les props) et manipule également des variables locales (le state).

Les props sont passées à un composant soit par le composant appelant (<Todo item="Acheter du lait" done={false} />), soit par des décorateurs (injectIntl par exemple, proposé par react-intl et qui permet d’injecter la prop intl, de manière à gérer des traductions, dans un composant). On parle ici de flux de données unidirectionnel : les props sont toujours transmises du parent vers l’enfant et jamais en sens inverse.

Le state quant-à-lui représente l’état d’un composant, il est défini à l’intérieur du composant lui-même, qui en a alors la responsabilité.

class Todo extends Component {
  constructor() {
	super();

  	this.state = {
      visible: true,
  	};
  }

  markAsDone() {
    this.setState({
	  visible: false,
    });
  }

  render() {
    if (!this.state.visible) {
	  return null;
	}

	return (
	  <li>
	    <span>{this.props.item}</span>
		<button onClick={this.markAsDone.bind(this)}>
			Fait
		</button>
	  </li>
	);
  }
}

Cette introduction à React est volontairement concise, et nous vous invitons pour aller plus loin à vous référer à la documentation existante, très bien fournie. Une liste de références intéressantes est à votre disposition à la fin de l’article.

React et Symfony

De plus en plus de projets utilisent conjointement React et Symfony. Il existe deux manières principales de marier ces deux technologies, que nous allons étudier ensemble.

React se nourrit de votre API

Si vous disposez d’une API existante, c’est certainement la solution la plus adaptée, peu importe d’ailleurs que votre API utilise Symfony ou non.

Comme dit plus haut, nous ne détaillerons pas ici la mise en place de cette architecture. Vous trouverez plusieurs liens vers des articles détaillant cette architecture et sa mise en place à la fin de l’article, si c’est cette solution qui vous intéresse.

En revanche, nous avons jugé intéressant de mettre l’accent sur quelques détails d’implémentations, basés sur notre expérience personnelle.

Logique métier

Dans des projets avec une logique métier forte, séparez au maximum les responsabilités pour éviter d’avoir à dupliquer la logique métier.

Dans le cas d’un site d’e-commerce avec workflow de commandes complexes par exemple, vous pouvez pour chaque commande, passer dans votre API son état et les transitions possibles. Ainsi, côté React vous aurez juste à créer des boutons permettant d’appliquer ces transitions, sans vous soucier de leur signification, et donc sans dupliquer la logique métier.

De la même manière, évitez de redéfinir des énumérations ou des listes de constantes, il est très rapide de mettre en place une méthode d’API qui retourne la liste de chacune des constantes, d’appeler cette méthode à chaque premier chargement de votre site React, puis de stocker ces valeurs dans un store global grâce à redux par exemple. Vous y aurez ainsi accès n’importe où dans vos composants et cela vous permettra d’avoir un code plus facilement maintenable.

Ce principe ne vaut pas pour tous les cas évidemment, la validation d’un formulaire, même si elle est complexe, devra quand même être implémentée des deux côtés (du moins si vous souhaitez des formulaires agréables à utiliser).

Internationalisation

Dans le cas d’un site multi-langues, il existe deux stratégies principales :

Tout traduire côté API

Vos messages quels qu’ils soient sont renvoyés traduits dans toutes les langues supportées et prêts à être affichés. Dans les faits cela peut poser problème puisqu’il devient impossible de changer le wording côté React. On peut également mettre en place un mécanisme pour préciser à l’API la langue souhaitée (avec un header Accept-Language dans vos requêtes par exemple), afin de récupérer seulement les traductions dans la ou les langues souhaitées.

Passer des clés de traductions via l’API, et traduire côté React

Simple à mettre en place côté API, il faudra cependant faire attention aux exceptions et aux erreurs de validations qui peuvent avoir des messages par défaut. Côté React, il faudra également implémenter un mécanisme pour réaliser ces traductions (par exemple en utilisant react-intl), et déporter tout le catalogue de message côté React, ce qui peut s’avérer plus gourmand en ressources. Il est possible (de la même manière que pour les constantes), de conserver le catalogue de messages côté API, et de le récupérer via un appel HTTP, mais on retrouvera alors les mêmes problèmes que pour la solution précédente.

Aucune de ces solutions n’est meilleure que l’autre, il faudra juste choisir la plus adaptée à votre cas et surtout vous y tenir sur tous les aspects du projet (messages d’erreur, erreurs de validation, etc...).

Librairies existantes

Si vous souhaitez réaliser un back-office avec cette architecture (un cas très fréquent et bien documenté), il existe de nombreuses technologies "clé en main" qui permettent de réaliser un back-office en React avec une API Symfony.

Parmi celles-ci on peut citer admin-on-rest, qui permet de réaliser très rapidement une interface d’administration basée sur une API existante et quel que soit le format utilisé par cette API. Il vous faudra simplement créer un "client", qui prend en paramètre le type d’action que vous souhaitez effectuer (GET_ONE, GET_LIST, CREATE...), la ressource (article, commentaire…), et un ensemble de paramètres (une représentation json d’un objet à créer par exemple) et qui exécute la requête adéquate et retourne une promesse. restClient(GET_ONE, 'posts', { id: 123 }) Il est également possible très facilement de personnaliser votre back-office.

Si vous utilisez api-platform pour votre API, vous pouvez également mettre en place un back-office en utilisant api-platform-admin. Cette librairie, basée sur admin-on-rest, permet de créer très rapidement le back-office correspondant à votre API (en parsant la documentation de l’API pour déterminer seul les routes existantes). La librairie a l’avantage d’être extrêmement rapide à mettre en place et on a la possibilité de le personnaliser complètement.

React embarqué dans Symfony

Si vous souhaitez utiliser React sur une partie de votre site seulement, il est possible d’intégrer vos composants React directement dans Twig.

Reprenons notre exemple de la Todo List, nous avons donc nos répertoires components contenant nos composants et js contenant nos autres scripts et nos composants principaux dont le composant TodoList. Lors du build, webpack (ou un autre task runner) va récupérer uniquement les composants enfants nécessaires (compris dans TodoList) ainsi que index.js (on va y revenir un peu plus loin) et les compiler en un seul fichier : todolist.js. On peut le résumer avec le schéma suivant :

Ce fichier js compilé va ensuite être inclus dans notre template twig avec la balise <script> habituelle :

{# layout.html.twig #}
{% block body %}
    <div
        id="todolist"
        data-items="{{ items|json_encode }}"
    ></div>
{% endblock %}

{% block javascripts %}
    <script type="text/javascript" src="{{ asset('todo-list.js') }}"></script>
{% endblock %}

Vous noterez la présence de la div #todolist et l’attribut de données data-items contenant la donnée items encodée en json (passée par le Controller).

Revenons sur le fichier index.js, dans celui-ci nous allons créer notre Composant TodoList en lui passant la props items qu'on a récupéré de la data-items avec la fonction getData. Enfin, on injecte ce composant au niveau de notre div #todolist.

// index.js

import React from 'react';
import ReactDOM from 'react-dom';

import TodoList from './TodoList.jsx';

const TodoListElement = document.querySelector('#todo-list');
const getData = (name, json = true) => {
    const value = TodoListElement.getAttribute(`data-${name}`);
    return json ? JSON.parse(value) : value;
};

const element = React.createElement(TodoList, {
    items: getData(items),
});

ReactDOM.render(element, document.getElementById('todo-list'));

Nous avons donc notre composant React dans notre fichier Twig.

On part donc du postulat que le client de votre API (ici le navigateur) est capable d’interpréter du JavaScript, de manière fiable et performante, ce qui n’est pas toujours le cas ! On peut prendre l’exemple des crawlers qui parcourent vos pages Web pour indexer leur contenu dans les moteurs de recherche. Certains d’entre eux sont (encore à l’heure actuelle) incapable de comprendre votre code JavaScript et ne verront donc que des pages vides. Cas de figure plus fréquent, les utilisateurs qui consultent votre site via des appareils très peu puissants (smartphones de premières générations, ou même le vieil ordinateur de bureau de votre grand-mère), risquent de voir les performances du site fortement dégradés.

Exemple de site vu par un robot qui n’indexe pas du javascript :

Avec JavaScript

Sans JavaScript

C’est là que le rendu serveur intervient.

Le rendu serveur

Avant de détailler notre dernière solution, il convient de parler un peu rendu serveur.

Kesako ?

Le rendu serveur, c’est donner à votre site la faculté de rendre les composants React… côté serveur. Concrètement, dans une application React classique, le serveur envoie à votre navigateur votre code React (transpilé en JavaScript et souvent compilé en un fichier), et c’est le navigateur qui va interpréter ce code, exécuter React, rendre vos composants, réagir aux actions de l’utilisateur, etc.

Le rendu serveur vise donc à pallier les problèmes de référencement, de performance et d’affichage de contenu pour tous les utilisateurs. Au lieu de renvoyer au navigateur votre code React, et de le laisser se débrouiller avec, le serveur génère lui-même le rendu HTML de vos composants et le renvoie au navigateur.

Plusieurs technologies existent pour faire du rendu serveur :

un serveur node externe ;
l’extension PHP V8JS ;

Nous avons aussi la librairie PhpExecJS qui détecte automatiquement le moyen à utiliser pour exécuter le JS (V8JS ou Node). Pour en savoir plus sur ces technologies, nous vous renvoyons aux slides de notre conférence.

Rendu client, serveur ou les deux

Le problème de ce type de rendu est que votre code React devient invisible pour votre navigateur. Celui-ci n'exécute aucun code JavaScript, et vous perdrez toute l’interactivité et la fluidité offerte par React. Le bouton qui faisait apparaître votre beau formulaire ne fonctionnera plus, de même que les filtres et les tris dans vos listes. Il faudra donc mettre en place des mécanismes alternatifs.

Le mécanisme le plus souvent utilisé est de remplacer chaque interaction de votre code React par un lien, permettant de charger une nouvelle page avec les informations à jour. Le bouton "Ajouter" qui ouvrait votre formulaire devient un lien vers une page de création, le bouton "Trier par date" un lien avec la même URL que votre page courante, mais avec un paramètre précisant le tri souhaité, et ainsi de suite. Cette solution vous permet de conserver une certaine interactivité avec un rendu full-serveur.

Comment ça full-server ? On peut faire du half-server ?

Eh bien oui, c’est possible, on pourrait donc profiter de tous les avantages du rendu serveur (premier affichage plus rapide, page lisible par les robots, affichage de contenu pour tous, même sans JavaScript…) tout en conservant le dynamisme offert par React côte client. Il est donc extrêmement puissant sur le papier, mais pas forcément évident à mettre en place, et c’est là qu’intervient Limenius ReactBundle.

LimeniusReactBundle

La dernière solution que nous vous proposons est donc d’utiliser un bundle. Il en existe plusieurs à l’heure où nous écrivons, mais le seul à vraiment sortir du lot est Limenius ReactBundle.

Basé sur React-on-Rails, ce bundle permet d’appeler vos composants React directement dans Twig, en exposant une extension Twig react_component. Il utilise PhpExecJS pour détecter l’environnement JavaScript installé sur vos serveurs (entre V8JS et Node) et utilise celui-ci. Il définit également une extension permettant de gérer un store pour les projets utilisant redux. Enfin, il permet de préciser, via un simple paramètre, si vous souhaitez du rendu client uniquement, serveur uniquement ou les deux.

{{ react_component('HomePage', {'rendering': 'server_side'}) }}
{{ react_component('HomePage', {'rendering': 'client_side'}) }}
{{ react_component('HomePage', {'rendering': 'both'}) }}

On a donc :

server_side : rendu du composant uniquement côté serveur.
client_side : rendu du composant uniquement côté client.
both : rendu du composant client ET serveur.

Pour ce dernier choix, nous pouvons imaginer une page qui fonctionne de la manière suivante :

Le navigateur appelle votre serveur et lui demande d’afficher une liste d’utilisateurs.
Le serveur interprète le code React et renvoie au client le HTML généré ET le code React.
Le navigateur affiche le code HTML sans se poser de question puis commence à interpréter le code JavaScript.
React, grâce à une variable JavaScript que le serveur a gentiment glissée dans le code généré, reconnaît le code HTML présent comme issu de vos composants.
Il reconstruit un DOM virtuel basé sur ce que vous voyez à l’écran, sans toucher au HTML, et se "réapproprie" le code.
React ayant repris la main sur l’affichage, vos boutons, filtres et autres joyeusetés reprennent le fonctionnement attendu.

Ce bundle nous permet donc d’écrire librement nos composants et d’appliquer un rendu serveur (ou non) uniquement sur les composants nécessaires. Le rendu serveur est utile mais assez coûteux niveau performance, l’ajout d’une feature-flag pour désactiver le rendu serveur peut être utile lors de très fortes affluences sur le site.

Vous pouvez voir les slides et la vidéo de notre conférence.

Références et bibliographie

Vous trouverez ici de la documentation et des articles intéressants pour approfondir sur ce sujet :

Baywatch : d'Angular à React, avec une dose de ReactNative

2017-02-14T12:00:00+01:00

Je n'ai pas pu résister longtemps à l'envie de réécrire l'application Baywatch en React, notre application (et la vôtre) de partage de veille. La première version Angular, développée il y a 3 ans, était un petit sac de nœuds mélangeant plusieurs paradigmes d'Angular: événement, factory, contrôleur, directives…

Quelques semaines plus tard (~5), la refonte est terminée. Baywatch, tout beau tout neuf, tourne sur la triptyque huppée du moment : Webpack, React & Redux 💕.

TL;DR

Pourquoi une refonte ?

Cette refonte, purement technique, concerne uniquement l'application Web (et non l'API), sans ajouter, ni supprimer de fonctionnalités et tout en gardant le même design/markup. Le but était donc de remplacer Angular par React pour moderniser la stack et avoir une base de code attractive et maintenable.

Je ne parle pas ici de migration car je n’ai réutilisé aucun code. Mais il est tout à fait possible de faire co-exister du code Angular et React, pour entreprendre une migration progressive. Celle-ci peut commencer par les feuilles de l’arbre applicatif puis remonter vers le tronc (le routeur en général), l'article "Our journey migrating 100k lines of code from AngularJS to React (Chapter 1)" détaille ce point-ci.

Baywatch fonctionnait bien, mais l'ajout de nouvelles fonctionnalités était compliqué avec Angular :

Base de code difficile et complexe ;
Manque de motivation relatif à Angular ;
Frustration.

La courbe d'apprentissage d'Angular est assez élevée, notamment à cause de ses nombreux concepts : directives, services, factory, digest, filter et j'en passe. Angular est un framework (contrairement à React qui est une librairie) et implique une compréhension de tous ces concepts.

Voici ma “rage curve” pleine de mauvaise foi pour illustrer mon ressenti 🙃 :

J'ai découvert entre temps React et Redux, enterrant toute motivation de maintenir du code Angular. La courbe d'apprentissage de React est plus légère. On assimile vite les quelques concepts inhérents à React : composants, state, props & JSX. Son API publique est simple et abstrait la complexité interne.

Ce qui peut s'avérer plus compliqué est l'application des bonnes pratiques et concepts d'architecture avancée (High order component, Redux, containers… ). Mais cet apprentissage se fait progressivement, contrairement à un Angular plus monolithique. Pour ceux qui voudraient commencer sur React, je conseille l’excellent create-react-app permettant d’abstraire webpack/babel et se focaliser uniquement sur le code React.

On dépoussière la stack: Yarn, Webpack & Babel

Yarn https://yarnpkg.com/

L’ensemble des dépendances est géré par Yarn (et donc npm en coulisses). En plus du gain de vitesse lors de la résolution des dépendances, Yarn verrouille automatiquement les dépendances (byebye npm shrinkwrap). Plus besoin également d’ajouter le --save afin d'ajouter la dépendance au package.json. À noter quelques difficultés avec des dépendances Github (référence de commit, non taguées, fork).

Webpack 2 https://webpack.js.org/

Webpack s’occupe du build de l’application. Sous ses airs compliqués, cet outil est assez simple à prendre en main. Pour Baywatch, nous avons deux bundles compilés : un pour le code userland et l’autre pour les vendors :

entry: {
 app: APP_MODULE,
 vendor: VENDOR_MODULES
},

Pensez à gérer dans votre config le build en mode production (UglifyJsPlugin, LoaderOptionPlugin…) et à utiliser la version prod de React, les performances n’en seront que meilleures et les petites connexions internet vous remercieront 🐢.

new webpack.DefinePlugin({
      'process.env.NODE_ENV': JSON.stringify('production'),
    }),

La migration vers la version 2 de Webpack n’est pas trop compliqué, la nouvelle documentation est assez claire sur ce sujet. Je n’ai pas eu de gros gain au niveau de la taille des mes bundles malgré la promesse du tree-shaking 😢.

Babel https://babeljs.io/

Babel permet de débloquer ✌ la syntaxe ES5/6 ✌ :

Cet ensemble de nouvelles syntaxes permet de livrer un code moins verbeux. Attention à ne pas trop en abuser, cela peux vite déboucher sur un code trop méta ("ES6 is great, but use it cautiously").

👉 Note sur Babel et Webpack 2

La version 1 de Webpack n’était pas capable de parser des modules ES6, c’est pourquoi Babel les convertit en module CommonJS. En effet lorsque vous renseignez dans votre .babelrc le preset es2015:

{
  "presets": [
    "es2015"
  ]
}

Celui-ci a pour défaut commonjs comme type de module (cf. la doc de Babel). Bonne nouvelle, Webpack 2 est maintenant capable de parser des modules ES6, il n’est donc plus utile de les convertir en CommonJS. Pour désactiver la conversion, il suffit de passer le flag modules à false :

{
  "presets": [
    ["es2015", { "modules": false }]
  ]
}

En plus du gain de vitesse lors du build, Webpack peut désormais détecter les blocs de code morts et les retirer de vos bundles (cf. tree-shaking).

React & co

Les raisons concernant le choix de React ont été évoquées plus haut, je vais détailler ici les librairies utilisées conjointement avec React. La première, indispensable, est la fameuse librairie Redux.

Redux

React est une librairie et non un framework. Sans autre outil que React, il est difficile de rendre une application maintenable et scalable. Dès que le nombre de composants augmente, on tombe vite dans les méandres des callbacks passés via les props, ou on commence à utiliser le context à tout va. Il en est de même pour les données applicatives, souvent éclatées au travers des composants.

Pour répondre à ce problème, Facebook a créé une spécification et son implémentation : Flux. J’utilise une des implémentations les plus connues : Redux. Il en existe d’autres, mais Redux s’est imposée (à juste titre) comme la référence. Cette librairie est pour moi indispensable dès qu'une application contient plus de 3-4 composants. Une fois maîtrisée (ce qui passe par beaucoup de veille technique), elle désamorce en grande partie la complexité d'une application : le workflow est clair, rodé, et satisfait 95% des cas d'utilisation.

Redux permet de mettre en place très facilement des patterns favorisant l’expérience utilisateur

Exploiter le LocalStorage

Redux apporte le concept du ✨ single source of truth ✨, vos données sont stockées dans un seul et même objet javascript. Baywatch utilise la librairie redux-persist permettant de synchroniser facilement une partie de votre store avec votre LocalStorage et ainsi d’améliorer la performance et l'expérience utilisateur.

const store = createStore(
  reducer,
  undefined,
  compose(
    applyMiddleware(...),
    autoRehydrate()
  )
)

// Begin periodically persisting the store
persistStore(store)

Undo/redo

Mettre en place un système de undo/redo est chose aisée grâce à l’architecture propre de Redux. Toutes les interactions passent par les reducers, et on peut ainsi garder facilement un historique de l’état du store pour naviguer dans le temps. La librairie redux-undo permet d’implémenter facilement ce pattern.

Optimistic UI

Grâce à Redux, on peut facilement mettre en place le pattern optimistic UI. Dans 95% des cas, notre API va retourner les données attendues. On peut donc mettre à jour notre UI pour signaler que l’opération s’est bien déroulée sans même attendre la réponse. Baywatch utilise ce pattern pour augmenter sensiblement la vitesse perçue par l’utilisateur.

Une action asynchrone permettant d’ajouter en favoris un bookmark se sépare en 3 états :

⏳ ADD_FAVORITE_PENDING
✅ ADD_FAVORITE_SUCCESS
🚫 ADD_FAVORITE_ERROR

On peut dès l’action ADD_FAVORITE_PENDING mettre à jour notre interface pour signaler l’ajout en favoris (passer l’étoile en jaune ⭐️ par exemple). Deux cas se présentent ensuite :

ADD_FAVORITE_SUCCESS: cas attendu, tout s’est bien passé on ne fait rien ✅ ;
ADD_FAVORITE_ERROR: pas de chance, on repasse l’étoile dans son état initial ☹️.

Communication avec son API

La complexité réside souvent dans le couplage avec l’API : comment récupérer les données, à quel niveau ? La bonne pratique est de créer un middleware Redux pour gérer les appels. Chaque appel asynchrone se divise en 3 actions élémentaires :

⏳ LOAD_BOOKMARKS_PENDING
✅ LOAD_BOOKMARKS_SUCCESS
🚫 LOAD_BOOKMARKS_ERROR

L'action PENDING envoie la requête vers le serveur puis selon la résolution de la promesse, les actions correspondantes sont lancées (SUCCESS ou ERROR).

La librairie redux-axios-middleware permet de faciliter la mise en place d’un tel mécanisme. J’utilise souvent le client HTTP Axios car il propose des fonctionnalités intéressantes telles que les intercepteurs ou l’annulation de requête (contrairement à fetch).

const client = axios.create({
  baseURL:'http://localhost:8080/api',
  responseType: 'json'
});

let store = createStore(
  reducers, //custom reducers
  applyMiddleware(
    ...
    axiosMiddleware(client),
    ...
  )
)

export function loadBookmarks() {
  return {
    types: [LOAD_BOOKMARK_PENDING, LOAD_BOOKMARK_SUCCESS, LOAD_BOOKMARK_FAIL],
    normalize: true,
    payload: {
      request:{
        url:'/bookmarks'
      }
    }
  }
}

Les intercepteurs permettent d’injecter la logique due à l’authentification (token JWT, erreurs 401, préfixe de l'API…) :

interceptors: {
    request: [({getState}, config) => {
       let { auth } = getState()
       if (auth.token) {
         config.params.access_token = auth.token
       }

       return config
     }],
   },
   onError: ({ error, next, action }, options) => {
     const {status} = error.response
     if (status === 401) {
       next(push('/login'))
       next(logoutUser())
     }

     return defaultOnError({action, next, error}, options)
   }

Attention tout de même : la dernière version comporte un bug lié aux intercepteurs, qui a été corrigé dans la PR de mon collègue Thibault.

Normalisation des données

Lors de la construction d’une application, l’erreur fréquente est de stocker les données d’API en l’état dans ses stores Redux. Or, leur schéma n’est généralement pas optimal pour l’utiliser dans React. Il est important de passer par une étape de normalisation afin d’avoir un state optimal et facilement exploitable. Si votre API retourne une liste de ressources telle que :

{
  "bookmarks": [
      {"id": 122, url: "http://link1.io"},
      {"id": 123, url: "http://link2.io"},
    ]
}

La recherche sera coûteuse. La bonne pratique est d'indiquer les identifiants des ressources en clé :

{
    "bookmarks": {
        "122": {"id": 122, url: "http://link1.io"},
        "123": {"id": 123, url: "http://link2.io"},
    }
}

Ainsi, vous pouvez accéder directement à l'élément sans le rechercher (complexité constante O(1) contre complexité linéaire O(n)).

✌🔥✨🔥✨🔥✨ much math ✨✨✨ many skill such WOW ✨🔥✨🔥✨🔥✌

Il est également important de ne pas dupliquer vos données dans votre state (c'est-à-dire stocker des identifiants plutôt que des entités dupliquées au travers des stores) et éviter les structures imbriquées :

// 👎
{
  "boookmarks": {
    "id": 123,
    "url": "https://joli.beer/",
    "author": {
      "uid": 37,
      "username": "shinework"
    }
  }
}

// 👍
{
  "boookmarks": {
    123: {
      "url": "https://joli.beer/",
      "authorUid": 37,
    }
  },
  "authors": {
    37: {
      "username": "shinework"
    }
  },
}

Pour gérer ces problématiques, j’ai utilisé la librairie Normalizr permettant de définir des schémas de normalisation. Je n’ai eu qu’à les utiliser dans l’intercepteur de mon client HTTP pour appliquer les transformations sur la réponse de mon API :

interceptors: {
   response: [({getAction}, response) => {
     const action = getAction()
     return (action.normalize && response.data) ? normalize(response.data, ApiSchema) : response
   }],

L'excellent article "Avoiding Accidental Complexity When Structuring Your App State" détaille cette problématique en quelques préceptes :

Éviter de modéliser votre state selon ce que retourne votre API ;
Éviter de modéliser votre state selon ce que qu’affichent vos composants ;
Préférer les maps aux tableaux ;
Ne pas dupliquer vos données dans votre state ;
Ne pas dériver des données (utiliser des sélecteurs) ;
Normaliser vos données.

Architecture

Architecture globale

├── src/
│   ├── actions/
│   ├── api/
│   ├── assets/
│   ├── components/
│   ├── constants/
│   ├── containers/
│   ├── models/
│   ├── reducers/
│   ├── store/
│   ├── translations/
│   └── utils/
│   ├── config.js
│   ├── routes.js
│   ├── shortcuts.js
│   ├── app.js
│.babelrc
│package.json
│webpack.config.js
│yarn.lock

C'est une architecture récurrente d’une application Redux. L'ensemble de la stack Redux se trouve dans les répertoires actions, reducers, store, constants.

Le répertoire api contient mes schémas propres à normalizr et mon instance du client http axios.

A noter qu’il existe une autre architecture orientée fonctionnalités (je ne l’ai personnellement pas encore testé). Celle-ci a pour avantage de regrouper les fichiers par fonctionnalités (composants, reducers, actions…) rendant la navigation plus aisée.

├── src/
│   ├── bookmarks/
│            ├── bookmarkReducer.js
│            ├── bookmarkActions.js
│            ├── bookmarksContainer.js

Je pense que cela à du sens, l’article “How to better organize your React applications” détaille cette architecture.

Dépendances de Baywatch (hors développement)

{
 "axios": "^0.15.2",
 "clipboard": "^1.5.16",
 "history": "^3.0.0",
 "immutable": "^3.8.1",
 "jwt-decode": "^2.1.0",
 "lodash": "^4.17.2",
 "moment": "^2.17.0",
 "normalizr": "^2.2.1",
 "notie": "^3.9.5",
 "react": "^15.4.2",
 "react-dom": "^15.4.2",
 "react-dropzone": "^3.8.0",
 "react-infinite-scroller": "^1.0.4",
 "react-redux": "^4.4.6",
 "react-router": "^3.0.0",
 "react-router-redux": "^4.0.7",
 "react-select": "^1.0.0-rc.2",
 "react-shortcuts": "^1.3.1",
 "react-translate": "^5.0.0",
 "redux": "^3.1.2",
 "redux-auth-wrapper": "^0.9.0",
 "redux-axios-middleware": "^0.3.0",
 "redux-persist": "^4.0.1",
 "redux-persist-transform-immutable": "^4.1.0",
 "redux-thunk": "^1.0.3"
}

Routing / firewall

Sans surprise, j’ai utilisé react-router pour gérer le routing. Mes routes n’exposent que des composants “containers” (cf. ci-dessous). Afin de gérer facilement le firewall au niveau de mes routes, j’ai utilisé la librairie redux-auth-wrapper. Celle-ci permet de définir des prédicats sous forme de HOC autorisant ou non l’accès aux routes :

const UserIsAuthenticated = UserAuthWrapper({
  authSelector: state => state.auth,
  predicate: auth => auth.token,
  wrapperDisplayName: 'UserIsAuthenticated',
  failureRedirectPath: '/login'
})

// Dans le routeur
<Route component={UserIsAuthenticated(AppContainer)}>

Elle permet aussi de gérer facilement le mécanisme de redirection sur la route initiale après la connexion:

https://team.baywatch.io/login?redirect=/all

Composants containers / présentations

L'architecture smart/dumb components permet de séparer la logique des composants en deux types:

Composants container constitués de la logique métier (ce que fait l’application 🔧):

Appel des actions / handler ;
Récupération des données ;
Connexion aux stores Redux ;
Composant "factory" ou "wrapper", pour factoriser des comportements.

Composants de présentation (ce qu’affiche l’application 🖼):

Composants applicatifs (“widgets”) ;
Composants “purs” ;
UI / Markup / CSS.

Ceci dans le but de séparer au mieux les concepts et de rendre les composants de présentation réutilisables avec des données variées.

En pratique avec Redux, les composants de types container se composent généralement d'un connect avec la définition des mapStateToProps et mapDispatchToProps:

import {connect} from 'react-redux'
import GroupHeader from './../components/GroupHeader'
import {joinGroup, leaveGroup, askGroupInvitation} from './../actions/groups'

const mapStateToProps = (state, props) => {
  return {
    group: props.group,
    isPending: state.groups.isPending,
  }
}

const mapDispatchToProps = {
  leaveGroup,
  joinGroup,
  askGroupInvitation,
}

export default connect(mapStateToProps, mapDispatchToProps)(GroupHeader)

Les fonctions passées à connect via l’objet mapDispatchToProps vont être automatiquement appelées avec la méthode dispatch (ex. dispatch(leaveGroup())). Ainsi les composants dumb pourront appeler ces fonctions depuis leurs props sans se soucier de la logique de Redux.

La fonction mapStateToProps va quant à elle lier le state avec mon composant. À chaque modification du state, mes composants vont donc être re-rendus.

À noter que la méthode connect va automatiquement vérifier si les propriétés passées en props ont changé et effectuer un rendu ou non :

[pure] (Boolean): If true, connect() will avoid re-renders and calls to mapStateToProps, mapDispatchToProps, and mergeProps if the relevant state/props objects remain equal based on their respective equality checks. Assumes that the wrapped component is a “pure” component and does not rely on any input or state other than its props and the selected Redux store’s state. Default value: true

Et le mobile ?

Nous avons commencé un POC d'une application mobile pour Baywatch avec React Native, le but étant de valider la possibilité de réutiliser la stack Redux utilisée dans la webapp, à savoir :

Les actions ;
Les reducers.

Et ce fut un succès : nous avons pu développer uniquement les composants propres à React Native et développer très rapidement les fonctionnalités de base ✌.

Partage de la stack Redux entre web & mobile

La principale difficulté était donc d'exposer les répertoires actions, reducers, constants à notre projet React Native.

Première hypothèse : mettre l'application mobile et Web dans le même répertoire afin qu'elles partagent le même package.json. Mais cette méthode semble difficilement maintenable : on souhaite pouvoir changer indépendamment la version de React (ou autres librairies) sur les deux applications, chose impossible avec un package.json commun.

├── apps/
│   ├── mobile/
│   ├── web/
│   ├── node_modules/
│   ├── package.json

Deuxième hypothèse : avoir deux package.json pour chaque projet, ce qui semble le plus propre :

├── webapp/
│   ├── src/
│   ├── node_modules/
│   ├── package.json
├── mobileapp/
│   ├── src/
│   ├── node_modules/
│   ├── index.ios.js
│   ├── index.android.js
│   ├── package.json

Cette architecture semble correcte mais apporte un nouveau problème : on ne peut pas importer de fichiers d'un répertoire plus bas dans l'arborescence que le fichier package.json. Ainsi, impossible depuis le code de l'application mobile d'appeler notre stack Redux présente dans le répertoire webapp :

import {loadBookmarks} from './../../webapp/src/'

La solution idéale serait donc de créer un package à part, dédié à la stack Redux, qu'on ajoute aux dépendances de nos deux applications :

import {loadBookmarks} from 'baywatch-core'

Mais cela rend notre développement un peu plus laborieux. Pour l’heure, nous avons donc fait le choix d’une solution intermédiaire, en copiant simplement le répertoire src de notre application web dans le répertoire node_modules de notre application mobile. React Native ne supportant pas encore les liens symboliques, nous avons utilisé un outil publié par Wix afin de palier à ce problème : https://github.com/wix/wml.

wml add ../webapp/src/ ./node_modules/baywatch
wml start

Ce qui nous permet bien d'importer nos actions :

import {loadBookmarks} from 'baywatch/actions/bookmarks'

On attend donc avec impatience le support des liens symboliques avec React Native pour éviter ce hack disgracieux 🤓.

Conclusion

Il y a encore beaucoup de sujets à aborder sur cette refonte et le développement d'application React :

L'utilisation de immutable.js avec Redux ;
L'utilisation de sélecteurs et la mémoïsation ;
Les leviers de performances avec l’optimisation des rendus ;
L'intégration avec une application Symfony ;
Les tests avec Jest, Enzyme, Ava….

De manière générale, cette refonte a clarifié la base de code en supprimant quelques 8 000 lignes de codes. Il est aujourd'hui plus facile de maintenir l'application grâce à la scalabilité apportée par React & Redux. En désamorçant la complexité, ces librairies permettent de mieux se concentrer sur le détail applicatif permettant de délivrer des applications plus raffinées.

N'hésitez pas à nous contacter pour échanger sur des détails d'architecture ou d'implémentation. Vous nous trouverez aussi aux meetups React 🍻. Enfin, si vous êtes soucieux de votre veille et voulez la partager avec le reste de vos collègues, n’hésitez pas à tester Baywatch. Tout feedback est le bienvenu.

❤️🏄

Starting a mobile application with React Native

2016-09-23T11:30:00+02:00

While preparing our next React Native training, I learnt a lot on the library and discovered an amazing community with a lot of packages. I felt the need to share the treasures I found.

How to start your project

There are already many ways to start your project, the simplest and official way is with react-native-cli.

react-native init AwesomeProject will generate all the project files needed to start with iOS and Android platforms (ex: Xcode and Gradle configurations).

What if you need more ? Lucky you, I found three starter kits to bootstrap your project! Here are some explanations on each one, to help you choose the right one for your need. Be careful, they come with technical choices and some boilerplate code that you may not need.

Snowflake

Highly focused on testing and CI, this one comes with nice video tutorials to guide you through. The author explains his choices and help you understand the redux architecture. I find this a really good template to begin with.

Pepperoni

Inspired from Snowflake with even more tools, like Auth0 integration, multi-environment configuration or Enzyme for testing. More advanced than Snowflake but also less accessible.

Ignite

This one comes with generators that can help you iterate more quickly. Again, it is more complex than the others, with libs included (ie. react-native-maps) and another test mechanism built with AVA. I recommend this one for advanced users.

Architecture and navigation

All the previous starter kits are using Redux, this is a nice choice with React and it helps a lot managing the state of your application. The new NavigatorExperimental merged in React Native is already using reducers to handle the navigation state.

But this is not mandatory and you could just build your app without it, for example just using smart and dumb components, with the stateful Navigator component.

I think the main difficulty when implementing the navigation is the number of choices available. To help you with that, I'll try to clarify each of the navigation options.

NavigatorIOS

The first option is a fully native one, only for iOS, sadly. It leverages the UIViewController to handle the navigation stack and the transition. This is the way to go if you are building only for iOS and you want to feel as close as possible to the system UI. Since the stack is handled natively, you could run into problems when trying to manage it on the JS side. It is also less customizable than the others.

Navigator

This navigation component is built only with JS and so is completely cross platform and customizable. Since all transitions are built in JS, opening a heavy page could lead to FPS drop and degrade the experience. The library proposes an InteractionManager to avoid doing work when transitioning with a method runAfterInteractions but keep in mind that this delays the render of your new scene. This component is also stateful, unlike the next one...

NavigationExperimental

As the name tells you, this one is experimental and varies across releases. Fortunately, @jlyman is keeping an updated repo after each release with the implementations.

NavigationExperimental relies on redux to handle the state and modify the navigation stack, this is the way to go if you want all your app to be managed by it. It needs more boilerplate code to start with but @jlyman and the official documentation will satisfy your copypasta addiction.

react-native-navigation

The last option is available as a module, and mentioned in the documentation page of NavigatorIOS. It provides a native navigation for both platforms and can be used with Redux! Since the navigation state is on the native side, the installation process involves editing the entry point and adding some boilerplate code in Objective-C and Java. The Android part is still a work in progress but I tried the examples and they all work really well. This is the way to go if you want to be as close as possible with the native UI and animation of the platforms.

Must have library

A lot of my research was into looking for the best components we could use to build our apps. Here is a tiny list of native and pure Javascript libraries for your development.

Javascript libraries

Since we are not in a browser context nor a nodejs context, library using window, document or node modules will not work. Here is a short list of the ones I find interesting:

MomentJS: fully featured date and time library
UnderscoreJS / lodash: toolkit to manipulate arrays, objects, strings...
ImmutableJS: immutable collections implementation
Redux thunk, redux saga: handling of asynchronous actions with Redux

React Native libraries

react-native-gifted-listview: list enhancement with pull to refresh and load more capability
react-native-gifted-form: many form widgets and customization
react-native-scrollable-tab-view: tabs navigation
redux devtools, reactotron: debug tools for Redux, time travel, logs and dispatching actions manually
react-native-drawer: drawer navigation built only with JS
react-native-elements: nice UI toolkit for faster development
Many many more… see js.coach

Test your app (or not)

Testing is at your discretion but the tooling is ready and waiting for you!

The official way seems to be Jest which provides mocks for React Native and a nice feature called Snapshot which allow developers to write fast tests to validate a component tree over time.

I saw other implementations using Enzyme and react-native-mock, closer to the ReactJS way. A good start is to look at the official implementation example by Airbnb.

import React, { View, Text, StyleSheet } from 'react-native';
import { shallow } from 'enzyme';
import MyComponent from '../src/MyComponent';
import { expect } from 'chai';

describe('<MyComponent />', () => {
  it('should render stuff', () => {
    const wrapper = shallow(<MyComponent />);
    expect(wrapper.length).to.equal(1);
    expect(wrapper.contains(<Text>I wonder if there will be any problems...</Text>)).to.equal(true);
  });
});

This covers up for unit testing in JS but you can also create functional tests, for this I tried Appium. This is an open source client-server software for manipulating simulator and device, the fun part is that the driver is implemented in many languages so you can write your tests also with JS and node. There is also a GUI to select manually the elements and generate boilerplate code.

Deployment

Assets

A tedious task when releasing an app is to create icons, images and splash screens for each device and platform. When using Titanium, we used Ticons which is a good cli library to integrate in your workflow and it also available as a website on http://ticons.fokkezb.nl/.

Ionic CLI has something similar that also supports PSD and AI files.

Both can be used with a React Native environment.

Building

The React Native documentation covers the basics for releasing your app. I suggest two services that will help you deliver faster.

CodePush is a SAAS service (by Microsoft) with a CLI and a native module to include in your app. It will allow to bypass the store release process for minor updates. It works by saving your JS code and assets on the server, your app check if updates are available and download it in background. The next app restart will have the updated version.

Another toolkit already used by many iOS and Android developers is Fastlane. This is an automation tool that will handle many repeated tasks like certification and profile generation or creating screenshots for each device size. It also lives versioned in a config file just next to your app, this is the ultimate time saving tool for mobile development.

Continuous integration

After setting up the tests in my app, I was looking for a CI supporting both iOS and Android. I looked at CircleCI which has a paid plan for OSX but instead I tried Bitrise which has also specific support for React Native and a free plan. After following the excellent tutorials from the Snowflake starter kit, I had a working build with jest tests, release bundle and release xcode build working! Below is the only file needed to make this work.

format_version: 1.1.0
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
app:
  envs:
  - BITRISE_PROJECT_PATH: ios/example.xcodeproj
    opts:
      is_expand: false
  - BITRISE_SCHEME: example
    opts:
      is_expand: false
trigger_map:
- pattern: master
  is_pull_request_allowed: true
  workflow: primary
workflows:
  primary:
    steps:
    - activate-ssh-key@3.1.1:
        title: Activate App SSH key
        inputs:
        - ssh_key_save_path: "$HOME/.ssh/steplib_ssh_step_id_rsa"
    - git-clone@3.3.3:
        inputs:
        - clone_depth: '1'
    - change-workdir@1.0.1:
        inputs:
        - path: example-react-native-app
        - is_create_path: 'false'
    - script@1.1.2:
        title: npm install
        inputs:
        - content: |-
            #!/bin/bash
            npm install
    - script@1.1.2:
        title: npm test
        inputs:
        - content: |-
            #!/bin/bash
            npm test
    - install-react-native@0.1.0: {}
    - react-native-bundle@0.2.0:
        inputs:
        - entry_file: "./index.ios.js"
        - out: ''

An amazing ecosystem

Building our training program was really awesome with all the amazing resources and people experimenting with the library. Developing a React Native app is not only writing JS code but also having the right toolkit to iterate quickly and have a first class app at the end.

If you want to know more and create an app from scratch during a three days session, head over to our React Native training.

Mon premier module Open Source pour React Native

2016-08-11T11:00:00+02:00

Souhaitant développer une application mobile pour une webradio avec comme cible Android et iOS, mon choix s'est porté sur React Native qui fait beaucoup parler de lui ses derniers temps et que nous souhaitons utiliser à la place de Titanium.

Ayant fait le tour des modules disponibles pour jouer un flux audio, je me suis aperçu qu'il n'y en avait aucun cross-platform. J'ai donc décidé de créer mon propre module React Native. Cet article retrace ce parcours et les problèmes rencontrés lors du développement du module react-native-audio-streaming.

Ci-dessous un aperçu de la première version du module réalisé.

Les recherches initiales

Le point de départ est bien souvent la question "Quelqu'un l'a-t-il déjà développé ?". C'est encore plus d'actualité sur un environnement aussi dynamique que React Native où de nombreuses librairies sont créées chaque jour.

Ce qui m'amène sur l'excellent dépôt de @jhabdas et ses slides sur la création d'une application iOS pour la webradio Lumpen.

iOS

La partie iOS du module est donc déjà bien avancée. L'ensemble du code est sous licence MIT, je peux donc le récupérer. Il manque par contre la gestion des metadatas envoyés par le protocole Shoutcast (logiciel open source utilisé par de nombreuses webradio).

Heureusement pour moi, une personne a déjà rajouté ce support dans son fork et je peux donc le récupérer.

Android

Pour cette plateforme, le module react-native-android-audio-streaming-aac dispose déjà des fonctionnalités avec le support des métadonnées Shoutcast. Il utilise la librairie aacDecoder qui ne semble plus maintenue mais l'implémentation était déjà réalisée et j'ai donc gardé cette librairie, une mise à jour la remplacera probablement par l'ExoPlayer.

Le module React Native

Trouver un nom

Ce module va permettre de faire du streaming audio, tous les modules étant préfixés par "react-native", je pars donc sur le nom "react-native-audio-streaming". Après une rapide recherche sur npm, déception, le nom est déjà pris 😢 (pour information, ce module n'existait pas encore lors de la réalisation de l'application radio, qui bénéficiera de ce module plus tard). Peut être est-il possible de contribuer à ce module au lieu de créer le mien ?

Le package npm ne possède pas de lien vers ses sources et aucune trace du dépôt dans ceux de l'auteur. Je le contacte donc pour en savoir plus sur l'état de son module.

Le développeur, Matteo Mazzarolo me répond qu'il ne souhaite plus le maintenir et qu'il a donc supprimé son module, tout en me proposant de transférer sa possession du package sur npm. Super !

Initialiser le projet

Ayant récupéré les différentes librairies et la possession du nom que je veux utiliser, il faut maintenant démarrer le développement du module.

La première chose à faire est de choisir une licence, pour ce faire les sites opensource.org et choosealicense.com permettent de se faire une idée rapidement. Je sélectionne donc la licence MIT qui possède le plus de liberté de partage du code.

Pour le code, je souhaite avoir une application d'exemple dans mon dépôt, après quelques recherches sur les bonnes manières d'initialiser un module, je trouve la commande officielle react-native new-library mais elle est peu documentée, ainsi qu'un autre outil en cli : react-native-create-library.

La commande officielle nécessite un projet déjà créé et inclut une version ancienne de React Native. Je choisis donc la deuxième qui me crée les 3 projets de librairies associés (iOS, Android et même Windows !).

$ react-native-create-library ReactNativeAudioStreaming
…
$ tree -d ./

├── android
│   └── src
│       └── main
│           └── java
│               └── com
│                   └── reactlibrary

├── ios
│   └── RNReactNativeAudioStreaming.xcodeproj

└── windows
    └── RNReactNativeAudioStreaming
        └── RNReactNativeAudioStreaming
            └── Properties

Ensuite, j'initialise le module et renseigne les informations de celui-ci :

npm init

Puis je créé l'application d'exemple et installe les dépendances :

mkdir Example && cd Example
react-native init
npm install ../

La suite consiste à lier notre application d'exemple avec notre package tout neuf, si l'on suit la manière de développement des packages NPM, cela consiste à utiliser npm link pour créer un lien symbolique vers notre module. Hélas, ils ne sont pas résolus par le packager de React Native (problème bientôt résolu), et je dois donc copier coller mes changements pour les garder synchronisés avec la librairie… Une alternative créé par la communauté est l'utilitaire wml, mais je ne l'ai pas testé.

Développement et uniformisation des APIs

Étant donné que la majeure partie du module est native, nous ne pouvons pas bénéficier du live/hot reload proposé par le compilateur, il faut donc relancer l'application à chaque modification via Xcode ou Android Studio. Toutefois, sur Android, nous pouvons profiter du build incrémental proposé par Gradle.

Je ne vais pas détailler le code nécessaire pour exposer les fonctions ou envoyer des événements au runtime JS car cela est déjà bien détaillé dans la documentation officielle :

La principale difficulté est de savoir se débrouiller avec les trois langages, l'Objective-C, le Java et le Javascript. Il vaut mieux s'isoler au maximum dans un environnement que de s'éparpiller à vouloir implémenter chaque fonctionnalité en parallèle.

De plus, il faut garder en tête les limitations de chaque plateforme. Par exemple, sur iOS, nous disposons des événements "Remote control" et de l'interface native lorsque l'application est en background, par contre sur Android, nous devons implémenter cette interface à la main avec une notification active.

Pour lier le code natif de notre module avec l'application d'exemple, nous devons les lier à la compilation avec la commande react-native link react-native-audio-streaming.

Publication

NPM

N'ayant jamais publié de package sur NPM avant, j'ai cherché le meilleur workflow disponible. La commande npm publish est simple d'utilisation mais il faut modifier la version à la main, créer la release et par conséquent il y a une forte probabilité d'erreur.

Le package np propose un workflow plus complet qui vérifie l'installation des dépendances, le code non commité, va lancer les tests et mettre à jour automatiquement la version dans le package.json.

Open source

Tous les projets nécessitent un minimum d'informations pour le démarrage ou l'installation. Le README est la première chose qu'un utilisateur va lire en arrivant sur votre librairie, il nécessite donc une attention particulière.

Le plus important est d'expliquer comment le module peut être installé et configuré. Pour React Native par exemple, cela revient à proposer la commande npm install avec le nom du module, puis à ajouter les éléments à modifier pour lier le code natif du module à l'application.

Comme introduction, personnellement j'apprécie une rapide liste des fonctionnalités de la librairie, avec, si nécessaire, plus de détails par la suite : notamment pour ce module, deux gifs montrant les différents comportement sur chaque plateforme (réalisé avec Giphy capture sur macOS).

N'hésitez pas à rajouter du code d'exemple pour guider le développeur sur l'utilisation de votre librairie. Dans mon cas, j'ai copié/collé le code principal de l'application d'exemple qui inclut le composant de la librairie.

L'autre partie importante est le suivi des mises à jour via un CHANGELOG qui permet de suivre l'évolution du projet mais surtout d'informer lors de dépréciations d'API. Je conseille fortement le site keepachangelog.com pour plus d'informations à ce sujet.

Conclusion

Je me suis aperçu que l'open source est un travail de tous les jours, je n'ai pour l'instant qu'un seul contributeur mais qui apporte sa vision et son code et il faut être prêt à en discuter et à prendre des décisions en commun. Je n'ose imaginer le temps nécessaire pour maintenir et faire évoluer des projets très populaires…

Excepté quelques ennuis pour gérer les dépendances natives, je trouve la création d'un module natif agréable et plus facile qu'avec Titanium (système de build plus complexe, SDK en global, peu de de documentations…). Les contributeurs sont aussi beaucoup plus nombreux avec plus de 2000 résultats sur snpm pour le mot clé "react-native" contre 1432 pour "titanium" (statistiques gitt.io) alors qu'il est plus ancien.

PS: Ce module a été utilisé dans l'application "La Cave Webradio" disponible pour Android et iOS !

Retour sur React Europe, la conférence hype du moment

2016-06-15T16:15:00+02:00

Nouveauté pour JoliCode, nous étions cette année sponsor et participants à la conférence ReactEurope qui s'est déroulée à Paris les 2 et 3 juin à l'espace Charenton. Pourquoi ?

Nous aimons PHP mais faisons, au fil de nos projets, de plus en plus de JavaScript. Nous utilisons déjà la librairie React sur de nombreux projets et cette conférence nous a paru incontournable. C’était l'occasion d'en apprendre les subtilités et d’entrevoir son avenir, auprès des meilleurs.

Mais React, plus qu’une librairie, c’est un écosystème. La conférence couvre donc aussi bien React Native que le paradigme "unidirectional data flow" implémenté par Redux, ou d’autres réalisations pour faciliter l’expérience de développement.

Les conférences techniques de cette édition gravitaient pour la plupart autour de trois thèmes principaux : React en profondeur, React Native, GraphQL.

React

Dan Abramov a lancé les hostilités en venant célébrer avec nous la première bougie de Redux dont il est à l'origine. Tel un Super Saïyen niveau 5, Redux a démonté les autres implémentations de Flux par son taux d'adoption par la communauté.

La conférence suivante, présentée par Lin Clark, développeuse chez Mozilla, qui travaille sur un nouveau navigateur utilisant React et Redux, est notre coup de coeur de ces deux journées.

Durant ce talk illustré par d'adorables cartoons faits maison, Lin nous a pris par la main pour nous emmener dans les profondeurs du fonctionnement interne de React, afin d'aboutir tout naturellement à quelques techniques simples pour améliorer les performances de nos applications. On retiendra entre autres ces quelques conseils :

utiliser la méthode shouldComponentUpdate dès que cela peut entraîner un gain de performances. On évite ainsi de re-render les composants inutilement à chaque infime changement du state ;
renseigner systématiquement la props key des composants rendus dans des boucles (vous savez, ce fameux warning qu'on ignore gentiment la plupart du temps). React utilise ces clés pour déterminer la position des éléments enfants et déterminer s'il doit effectivement les re-render ou simplement échanger leurs positions dans la liste par exemple ;
utiliser au maximum l'immutabilité, pour limiter le shouldComponentUpdate à une simple comparaison de références ;
définir le state des composants au plus bas niveau possible. Par exemple, un composant List devrait recevoir en props uniquement les id des items qu'il contient, et laisser la responsabilité de l'objet aux composants ListItem. De cette manière, si l'on modifie un des items, seul le composant enfant dont l'objet a changé sera re-rendered.

Max Stoiber & Nik Graf nous ont fait la présentation de leur outil carte blanche, qui permet de tester le rendu des composants dans toutes leurs variations possibles. On peut ainsi changer à la volée les props et le state des composants, grâce au hot loader intégré, ce qui permet de détecter simplement les edge cases et les problèmes de design éventuels. Ce type d’outil va certainement s’avérer très pratique pour les développeurs mais aussi pour les recettes.

Les autres conférences nous ont présenté Recompose, le fonctionnement interne de Flow ou encore la librairie Victory qui regroupe des composants de visualisation de données.

React Native

On ne présente plus React, mais certains d'entre vous n'ont peut-être pas encore eu l'occasion de se plonger dans l'univers de React Native. La techno était au coeur de nombreuses conférences, abordant principalement deux de ses aspects les plus délicats : les animations et la navigation.

Si React Native vous est inconnu, regardez la conférence de Bonnie Eiseman qui raconte l’histoire et l’évolution de React Native depuis sa première bêta. Elle revient sur les problèmes rencontrés par les early adopters (pas de support pour Android, API incomplète…). Elle décrit ainsi l'évolution très rapide de React Native et l’engouement massif qui a suivi la première release. Depuis, React Native supporte Android et le support de Windows Universal Apps a été annoncé lors de la conférence F8.

Improve React Native animations

Les animations natives présentent un certain nombre de limitations. En effet, même si elles permettent des performances optimales et un comportement spécifique aux plateformes à moindre coût, il n’existe qu’un nombre limité de composants disponibles, qu’il est de plus impossible de customiser. Krzysztof Magiera tente de répondre à ces problématiques via l’utilisation de la librairie Animated, intégrée à React Native. Celle-ci apporte la flexibilité qui manque aux animations natives et permet de définir des animations gestuelles avec des performances supérieures, à la condition toutefois de ne pas s’attaquer aux animations de layout. Pour ces dernières, il faudra utiliser des API complémentaires.

Navigation // Eric Vicenti

Eric nous a fait une démonstration du composant de navigation cross-platform (iOS, Android, Windows, NodeJS et les navigateurs) de React Native. Ce composant est encore expérimental mais déjà disponible. Il est d’ores et déjà utilisé en production.

GraphQL et Falcor, donner le pouvoir au client

Créé pour les besoins de Facebook et utilisé depuis 4 ans, GraphQL se veut être une alternative aux APIs (REST) afin de permettre aux clients d'accéder aux données en décrivant le format de réponse attendu. Le principe : décrire explicitement toutes les données dont ont besoin nos composants. Le tout est ensuite récupéré en une seule requête afin d’hydrater ces composants.

Exemple de requête GraphQL pour récupérer le nom des utilisateurs :

{
  user {
    name
  }
}

Dans la conférence sur le futur de GraphQL, présentée par Laney Kuenzel et Lee Byron, nous avons particulièrement apprécié la proposition expérimentale des annotations :

@defer, qui permet d’éviter de récupérer toutes les données d’un coup (ex: on affiche l’article, ensuite on affiche les commentaires) mais de différer la récupération des données secondaires ;
@live, sans doute la plus bluffante, qui permettrait de visualiser la donnée en temps réel ;
@stream, comme son nom l’indique, cette annotation permet de créer un flux, pour éviter un temps d’attente trop important pour visualiser une liste.

Les speakers nous ont détaillé comment le problème des données en temps réel était actuellement résolu sur Facebook, en utilisant les subscriptions GraphQL, une implémentation du pattern publisher/subscriber. Le principe est de faire une requête GraphQL indiquant l’action que l’on écoute, comme la liste des commentaires de notre publication récente. Puis, à chaque fois qu’un nouveau commentaire sera publié, notre client recevra ce nouveau commentaire.

En tout cas, si on pouvait être sceptique lors des premières annonces de GraphQL, les évolutions qu’on entrevoit dans son futur laissent présager de la résolution de problèmes communs à toutes les implémentations de clients et auxquels il n’existe pas actuellement de solution unique.

Jafar Husain de Netflix nous a présenté leur alternative à GraphQL : Falcor. Leur modèle de données étant relativement simple (moins d’une vingtaine d’entités), GraphQL était long à mettre en place et ne correspondait pas réellement à leurs besoins. Ils ont donc développé une alternative, Falcor, qui répond au même problème initial que GraphQL mais dont la mise en place sur un projet existant est plus rapide et qui est mieux adapté, selon eux, à un modèle de données plus léger.

Malgré les 800 développeurs présents dans la salle, nous avons également pu assister à des conférences moins techniques :

Being successful at open source

Dans cette conférence qui détonait par son aspect bien moins technique, Christophe Cheadeau, qui a travaillé à l'open sourcisation (oui oui) de React, React Native, Jest, et d'autres projets Facebook, nous a offert un retour d'expérience édifiant. Des points évoqués par Christophe, il ressort que la communication est la clé de voûte de ces réussites, de la propagation de l'information via les réseaux sociaux, les articles de blog, jusqu'à la création de tickets Github pour interroger la communauté sur les points faibles des libs et sur leurs réalisations. On en retient que le succès fulgurant de ces librairies n'est pas seulement dû au grand nom qui les porte, ni même peut-être aux librairies elles-mêmes, mais bien à un travail réfléchi et de chaque instant, et qu'il est aussi à notre portée !

On the spectrum of abstraction

Cheng Lou nous plonge dans les profondeurs de l'abstraction, et de tout ce que cette grande notion implique dans notre travail de tous les jours. Observer les lignes de code avec plus de recul permet de se rendre compte de la nécessité de travailler parfois à un niveau plus bas, plus concret, et en se concentrant d'abord sur les use-cases qui nous intéressent vraiment, plutôt que d'essayer de répondre à tous les cas possibles via des implémentations plus abstraites. Un talk rafraîchissant qui pose un regard nouveau, critique et réfléchi sur notre frénésie des frameworks.

Conclusion

React Europe est LA conférence pour rencontrer les rock stars de l'univers React. Une grande partie des conférenciers sont employés chez Facebook ; l’entreprise est à la fois moteur et travaille à la stabilité de React et des technologies liées en s’associant aux contributeurs principaux de l’écosystème. La conférence étant internationale, nous avons pu échanger avec des développeurs norvégiens, italiens, américains, polonais… Une particularité suffisamment rare dans les conférences parisiennes pour mériter d’être soulignée. Merci à l'organisation et aux speakers pour ce bel événement, dont vous pouvez retrouver toutes les conférences sur la chaîne Youtube de React Europe.

Crossing the native bridge to build apps with Javascript

2015-10-01T18:00:00+02:00

We are building cross-platform apps with Titanium since it came out in 2009, it was a great journey and we contributed to the platform, the builder and also created some widgets.

For now, we found no real free and open-source competitors to Titanium (sorry @xamarin), but there are new players in town, so let's see what they have to offer !

Hello NativeScript and React Native !

Why these two new libraries are coming out in 2015?

Well, the javascript ecosystem is evolving and we all know it (maybe too much). It is so popular that we try to build everything with it (website, server, IoT…) and mobile apps too ! Developers are looking for ways to share code across platforms or even between client and server, but it’s better if we can do it by using the same language and the same code !

Again, new tools? Seriously?

I know I know… but apart from Titanium, there was no competitors for building native apps with javascript and competition is always good, we will see what they come up to appeal the developers.

What is the challenge?

Nearly the same as building a mobile web app. Performance and UI. The rest is for the developer comfort.

Frameworks

Those three frameworks are SDK to build native apps for iOS, Android and Windows (only Titanium for now). They expose native api through the bridge that you can call via javascript. Your code is then interpreted at runtime via JSCore on iOS and V8 runtime on Android.

Titanium

Platforms: iOS, Android, Windows phone (beta)

Company: Appcelerator

Titanium is the oldest framework of this post, since july 2015, it partially supports windows. The SDK is written in Objective-C, Java and C++ and exposes it via classes called Proxies. A proxy is a native classe exposing properties and methods to the javascript context.

It is actively maintained by Appcelerator, it is mature, has an IDE and a MVC framework called Alloy.

We built many apps with it and wrote some blog posts.

NativeScript

Platforms: iOS, Android

Company: Telerik

Out since march 2015, NativeScript is an open source SDK and runtime. Build by Telerik, some paid solutions includes a web IDE or other service integration. SDK is written in javascript and the runtime is native.

Wait, what? SDK in Javascript? What kind of black magic is…

import enums = require("ui/enums");
import locationModule = require("location");
import common = require("location/location-common");

global.moduleMerge(common, exports);

class LocationListenerImpl extends NSObject implements CLLocationManagerDelegate {

    public static ObjCProtocols = [CLLocationManagerDelegate];
    static new(): LocationListenerImpl {
        return super.new();
    }

    private _onLocation: (location: locationModule.Location) => any;
    private _onError: (error: Error) => any

    ...

Oh okay, this is just some Typescript class extending an Objective-C class.

We saw in the previous code sample that a common module was imported and merged with the exports, this is the official API exposed by the SDK and available for both platforms.

Metadatas for all native APIs are generated when building the app and it allows to call native functions from JS files.

React Native

Platforms: iOS, Android

Company: Facebook

Also released open source in march 2015 (and buzzing since). Based on the javascript library of the same name, React Native allows to develop iOS and Android mobile apps with the power of components.

Facebook posted twice on their blog, once for the iOS release (mars) and once for the Android release (september). I recommend these posts, it helps understanding the history and progression of the library.

Development architecture

MVC

With Titanium, we can use a framework on top of the SDK called Alloy. Generally speaking, it provides three paradigms:

Models provide the business logic, containing the rules, data and state of the application;
Views provide the GUI components to the user, either presenting data or allowing the user to interact with the model data;
Controllers provide the glue between the model and view components in the form of application logic.

Behind the scene, it uses Backbone for the models, views are built in XML from Titanium UI components and controllers are extending Backbone.Events. They also expose view components with an id in the var $. For example if you want to update a label with the id "title" you can write in your controller:

$.title.text = ‘My title’;

Controllers are just modules and can be exported and created from other controllers, which is great to split your app into reusable components.

NativeScript uses nearly the same architecture but with raw models, although they use quite a lot of the observable pattern in the examples.

var observableArrayModule = require("data/observable-array");

module.exports = new observableArrayModule.ObservableArray([
	{ name : "Name 1"},
	{ name : "Name 2"},
]);

React + Flux

React does not force any architecture as it is just a view library with components. I think that Flux is the way to go (see comparison of other flux-based library). The unidirectional data flow is great for the declarative programming approach used in React (because we only declare views with it’s own data).

More recently, Facebook introduced Relay and GraphQL, which seems nice but force to have a GraphQL server side implementation. I prefer the approach of React Transmit with promises. Both these libraries remove the gap between the component and its data by including the query.

Here is a sample code of a list view populated with data from a json webservice.

var AwesomeProject = React.createClass({
  getInitialState: function() {
    return {
      dataSource: new ListView.DataSource({
        rowHasChanged: (row1, row2) => row1 !== row2,
      }),
      loaded: false,
    };
  },

  componentDidMount: function() {
    this.fetchData();
  },

  fetchData: function() {
    fetch(REQUEST_URL)
      .then((response) => response.json())
      .then((responseData) => {
        this.setState({
          dataSource: this.state.dataSource.cloneWithRows(responseData.movies),
          loaded: true,
        });
      })
      .done();
  },

  render: function() {
    if (!this.state.loaded) {
      return this.renderLoadingView();
    }

    return (
      <ListView
        dataSource={this.state.dataSource}
        renderRow={this.renderRow}
        style={styles.listView}
      />
    );
  }

  ...
});

Dev tools and debug

IDE

Titanium has an official IDE called Appcelerator Studio integrated with many Appcelerator services such as Cloud Services (database as a service).

For all the frameworks you can use the IDE or text editor of your choice since they always provide CLI tools to build the app.

Live reload

Titanium has an official live reload implementation called LiveView, there is also a community one called TiShadow that we use quite a lot.

The NativeScript one is called LiveSync, unfortunately these tools are not really just reloading the code but restarting the app after syncing it. The React one is more efficient and transparent, we can also force the reload with cmd+R.

Debug

The three frameworks have at least runtime logs and console.log to debug variables.

Appcelerator Studio has a nice debug mode and handles breakpoints.

NativeScript and ReactNative use the chrome debug tools with remote debugging.

The implementation is more advanced for React as you can debug components individually with the help of React Developer tools or use the built-in UI inspector in the simulator.

Styling

Titanium uses TSS (Titanium Style Sheet) which are file with a json like syntax. The property available are the properties of Titanium Object, for example if the view is a Button (Ti.UI.Button) with id login, you can set the styles like this:

"#login" {
  backgroundColor: red;
  width: 200;
  height: 50;
  title: "Login";
}

NativeScript try to be closer to CSS and handle a subset of rules that are next applied to the native object. A fancy feature is that we can import external files from a server.

Button {
	border-width: 1;
	border-style: solid;
	border-color: #034793;
	border-radius: 2;
}
TextField {
	background-color: #FAFAFA;
	border-width: 1;
	border-style: solid;
	border-color: #C7C7CC;
	border-radius: 2;
}

Same for React but implemented in plain javascript object (see the open source project css-layout). They choose to implement Flexbox for the layout, which is the future of layout in CSS. I struggled a bit with it but in the end it seems more powerful, and for @vdesdoigts our main designer, it was as easy as in CSS (see the doc on MDN).

StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#F5FCFF',
  },
  welcome: {
    fontSize: 20,
    textAlign: 'center',
    margin: 10,
  }
});

Conclusion

Write/learn once, deploy anywhere is valuable to a lot of people, it is valuable for us. There is no best solution and there is always tradeoffs, you have to find the one that fit the best to your needs. If you prefer stability, Titanium is the way to go, it is the first in place and has some great enterprise feature. If you value most the UI, React Native has already some awesome contributions since it’s mainly a view library adopted by developers and front end designers, it also has the biggest community right now. NativeScript is a nice alternative since Telerik is known to offer some great UI (but not for free), and if you plan to access a lot the bridge and connects to… native script :p.

Resources

Titanium
- http://www.tidev.io/
- http://gitt.io/
NativeScript
- https://www.nativescript.org/blog I did not find any content from the community... ¯\(ツ)/¯
ReactNative
- Impressions and app
- Playground https://rnplay.org/
- Components http://react.parts/native