At the beginning of July, Truls and I went on our first work trip abroad to attend the first ever ReactEurope conference in Paris. A two-day conference dedicated to the very popular React.js, a frontend library made by Facebook, and other related topics. Despite of an intense heatwave in southern Europe and the lack of an A/C that could cool down 700 people in a single venue, we still feel that the conference was a great experience. There were many great speakers who presented interesting topics and we learned a lot from their talks. The speakers include the creators of React.js, React Native, Flux, ImmutableJS, GraphQL, Relay, Babel, Redux and React Router, all important parts of the React ecosystem. We also had many enlightening discussions with other attendees.

Prior to the conference we attended a two-day React workshop with Michael Jackson (no, not the king of pop) and Ryan Florence from React.js Training. The workshop focused on learning the fundamentals of React and – perhaps more importantly – how to think in “the React way.” This because React components are written declaratively based on the state of the application. Writing code this way makes it easier to reason about the logic of your application. To help us think Reactively™ they taught us to always be able answer the two following questions when writing React components:

1. What state is there?
2. When/where does it change?

If these two questions are easy to answer, your component is probably easy to understand later for yourself and others.

There was great enthusiasm for React at the conference, and also JavaScript in general. Even more impressively was the desire to create open-source software for everyone to use and improve through collaboration. With so many people involved to make an ecosystem together, the sky’s the limit.

The following sections will give a brief look into some of the topics we found most interesting at the conference and from the workshop, summing up the biggest take-aways for us.

“Don’t rewrite, React!”
Ryan Florence’s talk at the conference was about migrating your app from any frontend framework to React – piece by piece. He showed how we can change a single piece of an app, e.g. a simple form, into one or more React components, and still have it work seamlessly with the rest of the app. An important point he made was to do this type of migration using a bottom-up approach. The idea is to not have two separate projects running – one with the already existing code base and one using React. We should rather change components of the app piece by piece. When we get new requirements or reported bugs we can decide whether to implement it in the previous framework or with React. This because both frameworks live side-by-side in the same code base. Historically, the more typical approach would be to create the entire app again from scratch with the new framework, using a top-down approach.

React Router
The React Router created by Michael Jackson and Ryan Florence seem to have become the defacto router for React. Declaring routes is just as easy as using any React component, i.e. you’re just writing JSX. The library also includes some nice features such as location transition handling and lazy code loading. The talk by Jackson explained how the router works, and some of the new features of the recent 1.0 version. We were also shown a few demos, which he barely was able to show due to the poor WiFi connection at the venue. Luckily, Ryan Florence jumped up from the audience to help Jackson out, as well as showing off some fine dance moves.

GraphQL and Relay
Back in 2012, Facebook saw an increasing problem with their often changing APIs when they started making native support for phones and tablets. This lead to a new way of sending data over the wire – a specification that is now known as GraphQL. The idea is to have a single endpoint on the server and then query for whatever data you need using a graph-like query language. At the core of the GraphQL specification is a type system, or a contract between clients and server. The server says “this is what you may query for”, and the client will only receive whatever data it asks for. Less data sent over the wire with fewer requests to the server.

A question many of us at the conference was discussing before the talk about GraphQL was “will I have to rewrite my entire database to be a graph database for this to work?” The answer is definitely “no”. The GraphQL endpoint is just another entry point, or interface, to your server application. You will have to implement how GraphQL should retrieve (and insert/update/delete) data from your application.

Relay is a library that handles data fetching for React applications. You simply describe your data requirements declaratively as GraphQL queries, and let Relay figure out how and when to actually fetch the data. Relay objects wraps React components and pass the fetched data using props, i.e. parameters to React components. Relay actually started out as a router framework as well as a fetching framework. But due to the previously mentioned React Router the router part of Relay was stripped out.

Lee Byron – Exploring GraphQL
Nick Schrock & Dan Schafer – Creating a GraphQL Server
Joseph Savona – Relay: An Application Framework For React

The state of animation in React
Animation can be a powerful tool to increase user experience. In React we try to express components declaratively, i.e. we describe what we want to happen, and not how we want it to happen. There is no concept of order and time. Animation is kind of the opposite. Something that happens in a sequence over a certain amount of time. Cheng Lou had a great talk about this topic. He has created an animation library for React that abstracts away the concept of time and lets us continue writing declaratively, making animations easier than ever.

Inline styling
When creating webapps, we tend to use three types of files; HTML, JS and CSS, where the files are responsible for structure, behavior and layout, respectively. This separation has advantages, but it also means that a single component, let’s say a button, has all of its code spread into three different files in possibly three different directories. This seems pretty difficult for a developer to work with. So why do we do this? Wouldn’t it be easier if all the code for a single component resided in a single file? We have already started doing this with React by writing HTML (or more precisely, JSX) and JS inside React components. And it works great!

Michael Chan talked about how we can take this one step further, and add styling into the same components. This means that all the concerns of a single element of the UI can reside in a single component, making it easier for developers to work with. We’re looking forward to seeing if this will work for larger applications.

Developer experience
DX. We’re not big on buzzwords, but this one kind of got to us. We want a great developer experience. Christopher Chedeau, an engineer at Facebook and the keynote speaker at ReactEurope, said that developers need a good experience in order to create great software in a reasonable amount of time. When we don’t have to fight the development tools, the end result – and ultimately the user experience – will almost always be better. At the very least, development is quicker with good tools. And remember, developers are people too. When we have fun, we work better.

We’ve all been there. A bad build tool. Difficult to push your code to production. Having to read unreadable code in order to fix some trivial bug. The JavaScript community is here to help. React.js makes it easier to reason about applications with its declarative paradigm. Note that this doesn’t come for free. You have to write “idiomatic React” in order to get this benefit. Great build tools such as webpack and Babel makes bundling and transformations easy. Facebook has even discontinued their own transformer, the JSTransformer, and are now using the third party Babel transformer.

Perhaps one of the best tools we learned about was the React Hot Loader by Dan Abramov. When you’re developing the tool will reload the code in your browser when you save a file while maintaining the state of your app. This means not having to reproduce the state of whatever you’re working on for every little change you make. He even created a whole new Flux library, Redux, that also support maintaining state of data stores. And if that’s not enough he has also built Redux DevTools that records all state changes so you can easily do rollbacks and toggle between the state changes. Now, that’s great DX!

In conclusion, the conference was a great experience where we learned a lot, and we would be happy to go again next year. Au revoir, ReactEurope!

ReactEurope 2015 – Day 1

ReactEurope 2015 – Day 2

Truls Skeie & Henrik Glasø Skifjeld