React Europe 2019

The M6 Distribution’s (M6 Web’s new name!) front team hasn’t posted for a long time. We took part as listeners of the 5th European React Conference in Paris on May 24th and 25th. It’s an opportunity to talk about what are the last moves in the React community and at M6.

As usual, we were waiting for lot of announcements in this conference and a lot of new tools or new libraries. There has been no big declaration, no surprise. But many subjects were interesting and several talks confirmed the way we have taken over the last few years.

Hooks, more hooks and suspense

During the keynote, Jared Palmer put the emphasis on hooks through an example to simplify the use of GraphQL queries. At M6 Distribution, we use hooks since the beginning of the year and many are in production. That has changed the way we write components. We already have used functionnal components before, but using hooks simplify the readability and the evolutivity of old class component. The bad point is testing… Because we use Enzyme, testing hooks is painful for now. Until Enzyme fully supports hooks, we have implemented custom mocks.

Jared Palmer also showed us the interest of React Suspense to manage a main loading state in an app instead of many spinners that don’t offer a good user experience. We can’t use Suspense for our app because of the SSR. As it is recommended by the React team, we use Loadable Components instead. Jared announced that a new asynchronous server renderer is in progress and could be released in 2019 supporting Suspense. Suspense will also include data fetching.

Others features or refactoring will come in the future, but there is very limited information:

Do the harlem shake

Several conferences have addressed the theme of animations with React. This subject is very often complicated to solve. Finding a high-performance solution that is compatible with as many browsers as possible can be a real challenge.

For more than a year now, we have been migrating from Sass to styled-components. Despite some resentment, it should be noted that this new tool makes it very easy to create/compose our new visual components. It also helps us a lot with its management of the theme.

Between the react-spring library and the tips of Joshua Comeau, we now have many ways to integrate the new animations that designers can invent.

To summarize their comments, there is no single best way to make animations in all situations. Whether with canvas, SVG, web API, CSS, 2D sprite, you should try to do it in several ways to compare performance and rendering in order to choose the best option for your specific case.

Make tests but make good tests

Lisa Gagarina gave us some tips to better testing the code. Even If we have been using ESLint and Prettier for a long time in our JS projects, we have chosen not to implement static typing for the moment. Indeed, we think that it is a huge step, it has a big impact on the code and it can make the onboarding of new developpers more complex. For now, we just use the React proptypes well.

Lisa also advices to better use Jest snapshots. They are often too many, too big, not clear, hard to review. And we have experienced it too. A best pratice can be to reduce snapshots size and inline it in the test file. The readability of a test is indeed very important and it is not recommended to refer to other files than the test file (this is valid for snapshots but also for fixtures). There are some ESLint rules to ensure this: jest/no-large-snapshots, jest/prefer-inline-snapshots. snapshot-diff can also helps by making a diff between the nominal case and the tested case of a component rendering.

A difficult thing is to keep test agnostic to implementation details. We should consider the code as a black-box and only test the user interaction of the components, otherwise any refactoring of code will be painful and might discourage developers from writing tests.

E2E tests are also complex to setup, write and debug but are absolutely necessary. For the back office app, unlike our front app where we use a custom stack, we choose Cypress a complete E2E framework that has saved us a lot of time.

Lisa concluded her very interesting lightning talk by saying that there is no such thing as a one-size-fits-all approach, the way of testing has to be adapted to the team and the project. For example on our 6play project, we have more than 3000 unit tests performed by Jest in less than 4 minutes and 450 E2E scenarios that save your life every day!

If you are interested in this subject, take a look at this article about JS testing best practices.

Finally a little GraphQL in our projects

One of the main themes of the conference was also GraphQL. This data exchange paradigm now seems to have its place among many users. For more than a year now, we have been using GraphQL on our back office and we are already seeing a lot of benefits:

a front/back exchange contract materialized in a schema,
easy consumption thanks to queries,
cache management provided by Apollo (also providing a collection of great tools for GraphQL).

Kenny already talked about it in 2015 but now we use it!

Development worflow: the expected journey

One of the most interesting conferences in my opinion was about the need to optimize the development workflow. This is an element that is too often ignored but is very important in the life of a project. Paul Amstrong presents us here an analysis of the workflow of his team in charge of the development of the Twitter Lite application. He also presented some conclusions and solutions he implemented. In a standard development workflow there are 3 points that allow a significant margin of progress:

increased developer confidence and delivery speed,
automate the PR process to maximum,
detect errors as early as possible.

These words echo our own questions on the subject and these conclusions confirm our decisions. It is important to have the shortest and most automated workflow possible between the developer and the user without sacrificing the developer’s experience because it goes hand in hand with all the other aspects of a project.

At M6 Distribution, we use most of the tools presented, but two in particular caught our attention.

The first, React Component Benchmark, is of particular interest to us because in the past we had started to investigate the subject and used tools that are depreciated today.

The second, Build Tracker, which allows us to test the evolution of bundle size, will allow us to replace an equivalent tool developed internally while providing a more detailed analysis in order to work more accurately on these issues.

Here is an example of a message posted by our in-house build tracker on a Pull Request.

Several very inspiring talks on accessibility seem to show that this issue finally appears to be considered by web actors. In particular Facebook, which has distinguished itself by showing its assistant to detect accessibility errors in the development of its new version. However, it is regrettable that this toolkit is not accessible to the community because it could be a great help to avoid putting people from being in a situation of handicap.

It is clear that our front web app is not yet very accessible but we are working to correct this error, especially on the new screens we have been integrating for several months.

Our expectations on Yarn finally fulfilled

We were waiting for it at M6, the new yarn release named berry offers almost everything we were missing in our favorite package manager. Indeed, by using yarn in monorepo mode for our front projects, we were confronted with several problems that had to be overcome with in-house tools. Example here with our monorepo-dependencies-check tool which is now becoming obsolete thanks to Constraints.

We are also delighted with the functionality of Zero install. But what we expected the most was about the workspaces. We will finally have a management of the publication of these.

Take a look at this repository for more information.

Some projects that interest us a lot: Next.js & Code Sandbox

Even if these two tools are not used for the development of our applications, the new features of Next.js and Code Sandbox are clearly very interesting.

As for Next.js, our front web project has its own configuration of server side rendering (Florent explains it in ‘Last night isomorphic JS saved our life!’). However, NextJS is a great project that we use for many of our side projects. AMP support, client-only pages and API endpoints are clearly welcome.

As for Code Sandbox, Ives van Hoorne told us his personal story and that of his project. In addition to the great tool that is CodeSandbox, we have seen that the use of WebAssembly seems to have solved a lot of performance and implementation problems. For example, he cites the coloring of the code based on TextMate only available in C could not have been ported to the browser without going through WebAssembly.