React Europe – Current state of React.js

React Europe

Two weeks ago I went to the React Europe conference in Paris and would like to give you some insights about current topics of React.js development, tools and ecosystem. Besides the fact that Paris was actually burning hot and the venue had no working AC the conference has been a blast. There have been approx 700 attendees and all the big players in the React community participated, like Facebook’s core dev team, community committers and big companies such as Twitter, Yahoo, etc. who are building big apps based on React. In summary the following areas (and much more) have been discussed by the speakers.

Current State of React

React is currently evolving to be a universal, target-agnostic view rendering engine. The DOM is just an implementation detail as Sebastian Markbåge from Facebook said and React in its core has nothing to do with browsers. In fact its base principle is actually all about defining components and their rendering logic in a declarative way. And this makes it really powerful because it can target other platforms such as native iOS/Android, canvas, WebGL or something else while keeping the same programming paradigm.

The latest version 0.14 (currently beta) is already going into this direction by extracting the DOM related logic from its core.

React Native

Currently only the iOS components of React Native are open sourced. The Android related implementation is supposed to be published in the near future. The conference was not covering a lot about this topic, besides a talk about fluent user interfaces by Spencer Ahrens . However Christopher Chedeau gave some nice insights in his keynote about developing the Facebook AdsManager with React Native. The app is public available for iOS and Android . Anyhow, the interesting thing is that the iOS app has been developed by 7 engineers without any iOS experience. But they knew React and were able to finish the iOS app within 5 months development time. Because of the React codebase, they were actually able to reuse 87% of their code base for the Android implementation which then took only 3 months of development time. The only difference they had to cover was the navigation model. The remaining  components could be shared across platforms. This sounds really promising and I am looking forward to see more in this area.

Flux

The Flux application architecture has been a big topic of discussion at the conference. Based on Facebook’s reference implementation there are currently plenty of Flux libraries (Redux, Fluxible, MyFly, Barracks, Reflux, Fluxy, Fluxxor) available. According to Christopher Chedeau, this is a good sign, because it is driving the innovation with the hope that the strongest concepts/ideas become a “standard” in the future. However for beginners it’s currently a pain to pick a specific library. They all rely on the same concepts but each of them enhanced or redefined specific parts such as the coupling/communication between actions, stores and the dispatcher. If you are in the situation to choose one library I would strongly recommend to compare at least two implementations. Watch out how popular a library is (community activity, etc), try to compare the differences, check the documentation quality, examples for unit testing and choose a style/pattern you are comfortable with. Also think about server-side rendering (Isomorphic Flux) if one of your requirements is to support SEO, legacy browsers and loading performance. Not all flux libraries support server side rendering by default.

Another interesting topic is real time communication between your clients and server. Flux by default is only having an in-browser-memory state on the client: There is no server state which is shared among other clients. If this is a requirement for you, then nexus-flux might be a good fit.

Relay & GraphQL

Relay is Facebook’s answer to complex data fetching issues for React applications. So why a framework for data fetching? One reason is all about the difficulties of handling edge cases such as state management, caching, retry, error handling, request coordination, pagination, etc. Even simple apps have to deal with such problems and it usually takes a lot of time to get them right. Relay is trying to encapsulate that problem space and let the developers focus on products and business logic by defining what data in which order to fetch (Joseph Savona ). To achieve that, Relay is actually wrapping each component as a higher order component with a specific query definition language called GraphQL. Based on the query, Relay is then fetching the data before a component gets rendered and injects it into the component properties. This makes it really easy to understand the behaviour of a single component because the data and render contract are tied together. If for example a given child component requires additional data, there is no need to touch all the parent components to pass the new data down, because each individual component is defining what data it needs.

Relay and GraphQL are definitely some very interesting approaches to handle complex data fetching issues and I highly recommend  keeping an eye on these technologies. Especially the idea of having one central GraphQL API for data fetching is really promising. This decreases the coupling of clients with traditional REST API resources and makes it easier to handle API changes without breaking clients and vice versa. This stack is for sure not a fit for every use case, especially businesses with a consistent data model with rare changes should stick to their existing APIs. In the end it really depends on the problems a given API causes and how complex it is to integrate a GraphQL API into a custom infrastructure.

Both technologies are in very early stages of development and there is probably a lot of movement and changes to be expected especially when the community hits this space. Facebook is actually running this stack already in production and they announced to Open Source Relay this August. GraphQL is currently released as an RFC draft and there is a reference implementation (GraphQL.js ) written in JavaScript.

Final thoughts

React is already a great framework for programming complex UIs. Because of its design it allows you to think about components in isolation in a declarative way without the need to understand the whole system at once. This makes programming with React a lot of fun and is probably one of the reasons why such a big community is currently pushing that stack. Because of this attraction there are a lot experiments going on especially around the Flux architecture which makes it currently really hard to pick one of those countless libraries. I hope this is going to settle down in the near future.

I was also expecting more news about React Native but this area was not covered a lot by the talks. Surprisingly the biggest news of the conference were the RFC announcement for GraphQL as well as the JavaScript based reference implementation (see above). This will definitely enhance the React ecosystem and improve the way we are thinking about data fetching in the future. I am really curious to see how this topics evolve.

All the conference talks can also be seen online at Youtube . This is a good starting point if you would like to dive into the React “space”.