ReactJS best practices pour 2016 (seconde partie)

Nous avions commencé la semaine dernière la traduction d’un article sur les bonnes pratiques en React.js en 2016. Voici la suite …

Composants

Beaucoup de personnes se plaignent de JSX. Avant tout, vous devez savoir qu’il est optionnel dans React.
Au bout du compte, JSX reste compilé en JavaScript avec Babel. Vous pouvez donc écrire du JavaScript à la place de JSX, même si cela semble plus naturel d’utiliser JSX tant que vous travaillez en HTML.
Ainsi, les profils moins techniques pourront continuer à comprendre et manipuler cette partie du Front front.

JSX est une extension syntaxique JavaScript qui ressemble à du XML. Vous pouvez utiliser un simple transformateur syntaxique avec React – JSX in depth

Si vous voulez en lire plus au sujet de JSX, jetez un oeil à l’article JSX Looks Like An Abomination – But it’s Good for You.

Utiliser des classes

React fonctionne bien avec les classes ES2015.

class HelloMessage extends React.Component {
    render() {
        return <div>Hello {this.props.name}</div>
    }
}

Nous préférons les composants de haut niveau plutôt que les mixins, ainsi, pour nous, abandonner le createClass  était plus une question de syntaxe qu’une problématique technique. Nous croyons qu’il n’y a rien de mal à utiliser createClass plutôt que React.Component  et vice-versa.

PropType

Si vous ne vérifiez toujours pas vos propriétés, vous devriez commencer à le faire en 2016. Cela peut vous économiser quelques heures, croyez-moi.

MyComponent.propTypes = {
    isLoading: PropTypes.bool.isRequired,
    items: ImmutablePropTypes.listOf(
            ImmutablePropTypes.contains({
                name: PropTypes.string.isRequired,
            })
    ).isRequired
}

Oui, il est possible de valider des propriétés Immutable.js grâce à react-immutable-proptypes.

Composants de haut niveau

Maintenant que les mixins sont mortes et plus supportées dans les classes ES6 de composant, nous avons cherché une nouvelle façon de faire.
Qu’est-ce qu’un composant de haut niveau ?

PassData({ foo: 'bar' })(MyComponent)

Simplement, vous composez un nouveau composant depuis un autre et étendez son comportement. Vous pouvez l’utiliser dans tout un tas de situations comme l’authentification requireAuth({ role: ‘admin’ })(MyComponent) (vérifie l’utilisateur dans le composant de haut niveau et redirige si l’utilisateur n’est pas authentifié) ou connecter votre composant avec un store Flux/Redux.
Chez RisingStack, nous aimons déjà séparer la récupération des données et la logique de “controller” dans des composants de haut niveau afin de garder nos vues les plus simples possible.

Tester

Tester avec une bonne couverture doit être une part importante de votre cycle de développement. Heureusement, la communauté React.js fournit d’excellentes librairies pour le faire.

Tester des composants

Une de nos librairies favorites pour tester des composants est enzyme de AirBnB. Avec sa fonctionnalité de “rendu peu profond”, vous pouvez tester la logique et le rendu de vos composants, ce qui est assez génial ! Cela ne remplace toujours pas des tests selenium, mais vous passez au niveau supérieur des tests frontend grâce à cet outil.

it('simulates click events', () => {
    const onButtonClick = sinon.spy()
    const wrapper = shallow(<Foo onButtonClick={onButtonClick} />)
    wrapper.find('button').simulate('click')
    expect(onButtonClick.calledOnce).to.be.true
})

C’est propre, non ?
Vous utilisez la librairie d’assertion Chai ? Il existe une intégration chai-enyzime.

Tester Redux

Tester un reducer devrait être facile, il répond à des actions entrantes et le font passer d’un état à un autre.

it('should set token', () => {
    const nextState = reducer(undefined, {
        type: USER_SET_TOKEN,
        token: 'my-token'
    })
    // immutable.js state output
    expect(nextState.toJS()).to.be.eql({
        token: 'my-token'
    })
})

Tester des actions est simple jusqu’à ce que vous commenciez à utiliser les actions asynchones. Pour tester des actions redux asynchrones, nous vous recommandons de regarder redux-mock-store, il peut beaucoup vous aider.

it('should dispatch action', (done) => {
    const getState = {}
    const action = { type: 'ADD_TODO' }
    const expectedActions = [action]
    const store = mockStore(getState, expectedActions, done)
    store.dispatch(action)
})

Pour du test redux plus poussé, allez voir la documentation officielle.

Utiliser NPM

Même si React.js fonctionne très bien sans packageur, nous recommandons l’utilisation de Webpack ou Browserify pour profiter de la puissance de NPM. NPM est remplie de package React.js de qualité, et il peut aider à gérer les dépendances de manière élégante.
(S’il vous plait, n’oubliez pas de réutiliser vos propres composants, c’est une excellente façon d’optimiser votre code)

Taille des paquets

Cette question n’est pas propre à React mais comme la plupart des gens packagent leur application React, j’ai pensé qu’il était important d’en parler.
Pendant que vous êtes en train de packager vos sources, restez toujours vigilant à la taille de votre paquet. Pour garder cette taille la plus petite possible, vous devez prendre en considération la manière dont vous définissez l’import/le require de vos dépendances.
L’exemple de code ci-dessous montre deux approches différentes qui peuvent faire une différence énorme en sortie.

import { concat, sortBy, map, sample } from 'lodash'
// vs.
import concat from 'lodash/concat';
import sortBy from 'lodash/sortBy';
import map from 'lodash/map';
import sample from 'lodash/sample';

Regardez l’article Reduce Your bundle.js File Size By Doing This One Thing pour plus de détails.
Nous aimons aussi découper notre code en au moins un vendor.js et app.js car les mises à jour des librairies tiers sont moins courantes que les mises à jour de votre base de code.
En ‘hashant’ les noms de fichiers de sortie (morceau de hash dans WebPack) et en les cachant sur de longue durée, vous pouvez drastiquement réduire la taille de code qu’il y a besoin de télécharger pour les utilisateurs revenants sur le site. Combiné au lazy loading vous pouvez imaginer comment cela peut-être optimal.
Si vous êtes nouveau en WebPack, regardez cet excellent article React WebPack cookbook.

Rechargement à chaud de composant

Si vous avez déjà écrit une Single Page Application (SPA) avec du rechargement à chaud (aka livereload), vous savez probablement à quel point cela peut être ennuyeux quand vous êtes en train de travailler sur un composant à état, et que l’ensemble de la page est rechargée car vous venez de sauvegarder dans votre éditeur. Il ne vous reste plus alors qu’à cliquer encore dans votre application, et recommencer à chaque enregistrement, encore et encore…
Avec React, il est possible de recharger un composant tout en gardant son état – boom, plus problème !

Utiliser ES2015

Je mentionnais que nous utilisions JSX dans nos composants React.js que nous transpilons avec Babel.js.
Babel
Babel peut faire beaucoup plus et permet aussi d’écrire du code ES6/ES2015 pour les navigateurs d’aujourd’hui. Chez RisingStack, nous utilisons les fonctionnalités d’ES2015 sur le côté serveur et le côté client qui sont disponibles sur la dernière version LTS de Node.js.

Linters

Peut-être avez-vous déjà utilisé un “style guide” pour votre code JavaScipt mais savez vous qu’il en existe tout autant pour React ? Nous vous recommandons fortement d’en choisir un et de commencer à le suivre.
Chez RisingStack, nous imposons l’exécution des Linters sur le serveur d’intégration continue et sur le git push aussi. Jetez un oeil au package pre-push ou pre-commit.
Nous utilisons “JavaScript Stand Style for JavaScript” avec eslint-plugin-react pour vérifier notre code React.js.
(C’est vrai, nous n’utilisons plus de point-virgule.)

GraphQL et Relay

GraphQL et Relay sont des technologies relativement nouvelles. Chez RisingStack, nous ne les utilisons pas en production pour l’instant, nous gardons juste un oeil dessus.
Nous avons écrit une librairie nommée graffiti qui est un ORM MongoDB pour Relay et rend possible la création d’un server GraphQL depuis des models mongoose existants.
Si vous souhaitez apprendre ces nouvelles technologies nous vous recommandons d’aller y jeter un oeil et de jouer avec.

Que retenir de ce “Best Practices” React

Plusieurs des techniques montrées et des librairies ne sont pas propres à React.js. Gardez toujours les yeux ouverts et regardez ce que font les autres dans la communauté. La communauté React s’est beaucoup inspirée de l’archirecture Elm en 2015.

Si vous avez une idée des outils React.js essentiels que tous les développeurs devraient utiliser en 2016, laissez nous un message !

 
Article originellement écrit par Péter Márton CTO chez RisingStack
Traduit par Mathieu Breton CTO chez 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″]