Sitegeist sent me and my colleague Henrik on a 6 day trip to Paris, to participate in this year’s React Europe Conference and the joined React workshop given by Nik Graf and Max Stoiber just before the main event.

In this article, I’d like to share my impressions and give an overview, of what we’ve taken away from this experience.

Conference website: https://www.react-europe.org/

TL;DR Paris is an amazing location for such a conference. We’ve been fairly overwhelmed by the number of visitors. React Fiber looks awesome, JavaScript Fatigue is nothing to worry about (on the contrary!), GraphQL definitely is the next big thing for us to have a closer look at and React VR is very likely to be our future playground 🙂

As it turns out, one article simply isn’t enough to cover the entire event, so I decided to split it into two separate ones. So here’s part one. Enjoy 🙂



Arrival

Thankfully, sitegeist let us arrive one day earlier, so we had a little buffer before the workshop started.

We used that time to explore Paris. As soon as we’ve arrived, we left our baggage at the hotel, immediately acquired week-passes for the Metro and headed off to the Eiffel Tower (cliché is a french word, after all).

From there on, we got a little side tracked, as our initial plan – having a guided roundtrip on a tourist bus – was disrupted just by the beauty of this colourful city, that dragged us deeper and deeper into itself. Besides that, it’s sometimes difficult to express yourself around there, if French is not exactly part of your multilingual repertoire. Parlez vous anglais? No? Well, handsigns will do then 🙂

We ended up walking all the way from the Eiffel Tower to the Notre-Dame cathedral to later end the day just there, experiencing the most french scenary imaginable: Sitting outside a street café, enjoying a nice meal – the Seine just in front of us, where we could watch a mime performing on a bridge to a thin layer of accordion music in the background.

This place came across exactly as advertised 🙂 And so ended this phenomenal first day.

Workshop days

Luckily we were accomodated in a hotel close to the conference location, so the next day we just needed to walk over there. At the conference hotel (the “Espace Charenton”) we got re-routed to the part of the conference area, in which our workshop took place.

We entered the “Salle Apollo” – quite ironically, as we discovered later on. There we found plenty of rows of prepared seated desks. And – most importantly – prepared coffee at the side.

The “Salle Apollo” offered quite enough room for the about 50 attendees, which was impressive to us never having experienced a workshop on that size (one should be careful about crowd sizes nowadays though, but 50 surely is in the ballpark).

Day 1

In preparation for the workshop, all of us had to clone a nicely prepared git repository containing a create-react-app setup alongside some excercises.

https://github.com/reacteurope/react-workshop

So, as the crowd was sitting down, booting up their laptops, git clone ing and yarn install ing, Nik Graf and Max Stoiber took the stage.

Nik Graf (@nikgraf, https://github.com/nikgraf) is an extremely active OpenSource contributor, working on projects like belle-ui and serverless.com (https://serverless.com/). He’s passionate about UI and UX and brings a lot of experience with React, ReactVR and Redux.

Max Stoiber (@mxstbr, https://github.com/mxstbr) is also extremely active in contribution and works on projects like keystonejs and postcss. He is CTO and co-founder of Spectrum (https://github.com/withspectrum) and a distinguished coffee afficionado.

Both of them are organizers at the React Vienna meetup: https://www.meetup.com/de-DE/ReactVienna/

The schedule for the first workshop day included a couple of basic concepts – not all of them unfamiliar to us, but presented with a lot of background knowledge:

The React Children API

Higher Order Components + Composition

Hot reloading

Webpack DLL

Codesplitting and Treeshaking with webpack

All of which deserve their own article, so I’ll just concentrate on what was most relevant to us. Nik and Max have done an amazing job explaining these ideas and tools.

About half an hour of introduction to each concept was followed by about an hour of excercise (Labs) on prepared code examples, which were available as branches in the aforementioned git repository. If finished early, we were encouraged to help others.

The overall pacing of the workshop felt quite good. The excercises were carefully constructed and challenging enough to really grasp the underlying concepts.

The workshop was accompanied by an app written by Gerard Sans (@gerardsans, https://github.com/gsans), which allowed us to asynchronously ask questions throughout the entire workshop.

Nik and Max would occasionally open up the app to address all the questions that came up so far. It really felt, like this helped to enable much more questions than in a regular Q&A session. We even whitnessed real time criticism (“Wouldn’t Doug Crockford cry right now?” :D), which really felt transparent, unobstrusive and highly informative.

In the context of such techical topics, writing questions feels much more precise. You are able to include links, code etc. And since you stay relatively anonymous, the awkwardness of posing any kind of question goes away.

This inspired me to take this application under consideration for our future activities at sitegeist regarding meetups, conferences and workshops.

Thanks, Gerard!

https://github.com/gsans/handsup-react

https://medium.com/@gerard.sans/building-handsup-an-os-real-time-voting-app-using-graphql-and-react-b2b7dcd0e136

Probably the most important topic for us to get out on day 1 were Higher Order Components + Composition.

Since every React component can be expressed as a function of props (in contrast to the familiar class-based approach), the concept of Higher Order Functions can be similarly applied to components.

Whoever used redux before is probably familar with the connect decorator. Decorators are in fact nothing more than Higher Order Components.

Let’s say, we want to control the visibility of a component and don’t want it render at all, if the isVisible prop is false . It would probably look like this:

const MyComponent = ({isVisible}) => ( isVisible && <div>Hello World!</div> );

The isVisible behavior ist pretty universal and could be useful for a number of components. So, obviously you’d find implementations that look like this all over the place. Unless, there was a method to re-use the relevant code.

Enter Higher Order Components:

const onlyRenderIfVisible = Component => ({isVisible, ...props}) => ( isVisible && <Component {...props}/> );

The function onlyRenderIfVisible is a Higher Order Component, that can now be wrapped around any other Component like this:

const MyComponent = () => ( <div>Hello World!</div> ); const MyEnhancedComponent = onlyRenderIfVisible(MyComponent);

Calling <MyEnhancedComponent isVisible={false}/> would lead to the expected result.

Since components are nothing but functions, Higher Order Components can also be composed:

const MyComponent = () => ( <div>Hello World!</div> ); const enhance = compose( onlyRenderIfVisible, toggleVisibilityOnClick ); const MyEnhancedComponent = enhance(MyComponent);

This way you get a nice level of abstraction for partial functionality that can be re-used across multiple view-centered components. You get separation of concerns and beyond that the same predictability and testability that comes with pure functions.

In this part of the workshop we also got introduced to recompose , a library that contains a rich set of helpful Higher Order Components. It left such a positively lasting impression to me, that I’m already using it in the ongoing UI rewrite of Sitegeist.Monocle 🙂 So, I strongly recommend to take a look at it.

recompose: https://github.com/acdlite/recompose

The second half of the workshop dealt with development techniques and build setups, especially Hot Reloading and Code Splitting.

Albeit a fascinating topic, it kind of lacks relevancy to most of our setups, because in content-driven projects it is a bit harder to tell at which point JavaScript code can be meaningfully split than it is in SPAs.

Nevertheless we got an in-depth introduction to the topic and the associated techniques. Enough stuff for us to think about in our own build setups.

At the end we had a little bit of time left, which @nikgraf used to give us an introduction to React VR. This library allows you to create VR experiences for the web by just using the familiar component architecture of React. Each object in your VR world can be expressed as a component and thus positioned, manipulated and even animated.

To get started is exceptionally easy. You only have to install the react-vr-cli tool to kick off a scaffolded project like this:

npm install -g react-vr-cli react-vr init MyAwesomeVrExperience

More infos about ReactVR here: https://github.com/facebook/react-vr

Day 2

The second day was all about GraphQL, the theory of which I was already pretty familiar with. But since I’m lacking the practical experience, I was looking forward to discover a full stack setup.

GraphQL is an alternative to RESTful APIs, that shifts a lot of the contractual responsibility of the API onto the client. The server basically exposes arbitrary datastructures, discoverable by a schema. The client decides in what shape it expects to receive that data, described in a Query Language that is the core ingredient of GraphQL.

A Query like this:

query { teasers { title link image } }

Would result in a JSON-structure like this:

{ "teasers": [ { "title": "Teaser #1", "link": "http://www.example.com", "image": "http://www.example.com/example.jpg" }, { "title": "Teaser #2", "link": "http://www.example.com", "image": "http://www.example.com/example.jpg" }, ... ] }

Et voilá, request and response are similarly shaped. And the client ultimately decides over the shape.

By being strictly typed and not even allowing for a wildcard property request, GraphQL becomes a strong ally when it comes to keeping your client-server contract under control.

If facebook would decide to deprecate an arbitrary property somewhere in their numerous data-structures, they could find out exactly at which point which client is still using it. This is the major super-power of GraphQL especially when compared to RESTful alternatives.

We learned how to get the backend up and running with Node.js. But, as a side note, there are also solutions for PHP-backends in general and Neos CMS in particular in place:

https://github.com/webonyx/graphql-php

https://github.com/bwaidelich/Wwwision.GraphQL

https://github.com/bwaidelich/Wwwision.Neos.GraphQL

On the client side, we got introduced to the Apollo Client (remember? We were seated in the “Salle Apollo” 🙂 But we don’t know if that pun was intended).

Apollo Client is a universal GraphQL client for the browser, that comes with integrations for Angular, React, Vue, Ember and many other libraries. Apollo is very easy to set up and designed to work as an adoptable solution to existing code bases.

The React integration works as a Higher Order Component that injects requested data from an ad-hoc GraphQL query. So basically, it can be attached to any existing React component, that then receives server data via it’s props.

Like on day 1, we got introduced to numerous topics like static reading queries, dynamic reading queries and writing queries (or mutations), all of which had their own “Lab” excercise.

With the next opportunity I’d really like to try a combination of Wwwision.Neos.GraphQL and Apollo Client in action. And thanks to this workshop, I feel very comfortable in giving this a shot.

Apollo Client: https://github.com/apollographql/apollo-client

React Apollo: http://dev.apollodata.com/react/

Summary

Nik and Max did an awesome job with this workshop. Not only did they get the pacing like on the nose right, they also kept the practical excercises at a challenging yet informative level. And by trying @gerardsans‘ app, they also handled our immediate feedback perfectly, so that the entire workshop remained responsive to the crowd.

This is it for part one. Part two will be a summary of both conference days and will contain an explainatation of why there’s no reason to be worried about JavaScript fatigue 😉