ReactJS best practices for 2016 (première partie)

2015 fut l’année de React avec des tonnes de nouvelles releases et conférences dédiées au sujet partout dans le monde. Pour une liste détaillée des dates clés de l’année dernière, jetez un coup d’oeil au React 2015 Wrap Up.

La question la plus intéressante de 2016 : Comment coder une application et quelles sont les librairies recommandées ?

En tant que dévelopeur travaillant depuis longtemps avec React.js, j’ai ma petite idée et mes best practices mais il est possible que vous ne soyez pas d’accord avec moi alors dans ce cas, n’hésitez à déposer un commentaire afin d’ouvrir la discussion.

react_best_practices-1453211146748

Si vous débutez avec React.js, regardez ce tutoriel React.js ou le React howto de Peter Hunt.

Gérer la data

Manipuler les données est à la fois facile et stimulant. C’est parce qu’il existe plusieurs façons de passer une propriété à un composant React afin de construire l’arbre de rendu, ceci dit, il n’est pas toujours évident de savoir comment mettre à jour la vue.

2015 a commencé avec la sortie de plusieurs librairies de Flux et continué avec des solutions plus fonctionnelles et plus réactives.

Regardons où nous en sommes aujourd’hui.

Flux

D’après notre expérience, Flux est souvent sur-utilisé (c’est à dire utilisé alors qu’il n’y en a pas vraiment besoin).

Flux propose une façon propre de stocker et mettre à jour le state (l’état) de l’application et de déclencher le rendu à la demande.

Il est utile pour gérer les état globaux de l’application comme : la gestion des utilisateurs connectés, l’état d’un routeur ou d’un compte actif, mais ça peut devenir assez vite pénible si vous commencez à gérer des données temporaires ou locales.

Nous ne recommandons pas d’utiliser Flux pour gérer des informations liées au routing comme items/:itemId. A la place, il est préférable de charger et stocker dans le “state” (état) du composant. De cette façon, ce sera détruit quand le composant disparaitra.

Pour plus d’info sur Flux The Evolution of Flux Framework est un excellent article.

Use redux

Redux est un container à état prévisible pour apps Javascript.

Si vous pensez avoir besoin de Flux ou une solution similaire, vous devriez regarder Redux et le cours de Dan Abramov : Getting started with redux pour monter rapidement en compétence.

Redux est construit autours des idées de Flux mais évite la complexité en s’inspirant de l’ELM.

Gardez les State plats

Les API retournent généralement des ressources imbriquées. Ce qui peut-être difficile à gérer dans une architecture basée sur Flux ou Redux. Nous recommandons de les aplatir avec une librairie comme normalizr et de garder vos states aussi plats que possible.

Astuce pour les pros:

const data = normalize(response, arrayOf(schema.user))
state = _.merge(state, data.entities)

(nous utilisons isomorphic-fetch pour communiquer avec l’APIs)

Utiliser des States (états) immutables

« les states mutables partagés sont la source du mal »Pete Hunt, React.js Conf 2015

immutable_logo_for_react_js_best_practices-1453211749818

Un objet immutable est un objet dont l’état ne peut pas être modifié après avoir été créé.

Les objets immutables peuvent nous économiser bien des maux de tête et améliorer les performances de rendu avec leur vérification d’égalité au niveau référence. Comme dans le shouldComponentUpdate :

shouldComponentUpdate(nexProps) {
   // au lieu d'une comparaison profonde
   return this.props.immutableFoo !== nexProps.immutableFoo
}

Comment parvenir à l’immutabilité dans javascript ?

La façon difficile, c’est de faire très attention et d’écrire du code comme dans l’exemple ci dessous, que vous devriez toujours tester unitairement avec du deep-freeze-node (freezer avant la mutation et vérifier le résultat après).

return {
  ...state,
  foo
}
return arr1.concat(arr2)

Et croyez moi, ça c’était les exemples faciles.

La façon plus simple, mais aussi la moins naturelle est d’utiliser Immutable.js.

import { fromJS } from 'immutable'
const state = fromJS({ bar: 'biz' })
const newState = foo.set('bar', 'baz')

Immutable.js est rapide, et l’idée est élégante. Je vous recommande de regarder la vidéo Immutable Data and React video par Lee Byron même si vous ne voulez par l’utiliser. Cela vous permettra de comprendre comment cela fonctionne en profondeur.

Solutions observables et reactives

Si vous n’aimez pas Flux/Redux ou si vous souhaitez que le service soit plus réatif, ne vous inquiétez pas !  Il y a d’autres solutions pour gérer vos données. Voici une liste de librairie qui correspond à ce que vous cherchez :

  • cycle.js (« Une librairie fonctionnelle et un framework JavaScript réactif pour un code plus propre”)
  • rx-flux (« L’architecture Flux avec RxJS”)
  • redux-rx (« des utilitaires RxJS pour Redux.”)
  • mobservable (« Des données observables. Des fonctions reactives. Du code simple.”)

Routing

Presque toutes les applications clientes utilisent le routing. Si vous utilisez React.js dans un navigateur, à un moment ou un autre, vous devrez utiliser une librairie. Nous avons choisi react-router par l’excellente communauté Rackt. Rackt produit toujours des ressources de qualité pour les amoureux de React.js.

Pour intégrer react-router, jetez un coup d’oeil à leur documentation, mais le plus important est que si vous utilisez Flux/Redux, nous vous recommandons de garder le state de votre routeur synchro avec votre state store/global.

Les router-states synchronisés vous aideront à contrôler les comportement des routeurs par les actions Flux/Redux et lire les states et paramètres des routeurs dans vos composants.

Les utilisateurs de Redux peuvent faire ça simplement avec la librairie redux-simple-router.

Code splitting, lazy loading

Très peu d’utilisateurs de webpack savent qu’il est possible de séparer le code de votre application afin de découper l’output du bundler en plusieurs chunk JavaScript :

require.ensure([], () => {
  const Profile = require('./Profile.js')
  this.setState({
    currentComponent: Profile
  })
})

C’est très utile dans les longues applications car le browser de l’utilisateur n’a pas à télécharger le code qui est rarement utilisé comme la page profile après chaque déploiement.

Plus de chunk signifie plus de requêtes HTTP mais ça n’est pas un problème avec HTTP/2 multiplexed.

Vous pouvez aussi combiner avec du chunk hashing afin d’optimiser votre cache hit ratio après les changements de code…

La prochaine version de react-router apportera beaucoup en terme de code splitting.

Pour comprendre le futur de react-router, regardez cet article de blog de Ryan Florence: Welcome to Future of Web Application Delivery.

La suite de l’article

Article original de Péter Márton RisingStack traduit par l’équipe JS-Republic

[separator type=”” size=”” icon=”star”] [actionbox color=”default” title=”” description=”JS-REPUBLIC est une société de services spécialisée dans le développement JavaScript. Nous sommes centre de formation agréé. Retrouvez toutes nos formations techniques sur notre site partenaire dédié au Training” btn_label=”Nos formations” btn_link=”http://training.ux-republic.com” btn_color=”primary” btn_size=”big” btn_icon=”star” btn_external=”1″]