I was excited to attend the React Amsterdam conference and I had a really great time. You can notice that from the millions of tweets I have sent during the conference. The speakers and the talks were excellent so I wanted to make a quick summary of the whole event for the people who weren’t there.
Let’s start!
Tadeu Zagallo did an overview of the React Native Architecture.
He showed a really simple React Native app with a text field and a button that displayed an alert when it was clicked. He proceeded to explain how all the internals of React Native work, how does the RN display the native View and what exactly happens in the background when the user interacts with the button to show the alert. He also explained some of the VM basics like how the source code is copied, parsed, the AST is generated, bytecode is generated and then finally executed. It was a really entertaining talk even for the people who were not interested in doing RN apps.
Jamis Charles talked about how they’re migrating the legacy code at PayPal in React+Redux.
Currently, they are using Backbone for the frontend but they didn’t like it because it had too many abstraction layers, they had low confidence that everything will work properly, and they have encountered too many state bugs. They couldn’t ditch it right away, so they started refactoring the app from the bottom up. Starting from the smallest child components, they’re replacing the views with React+Redux but they are still keeping some of the Backbone code until the whole app is completely refactored. His slides are available here.
Martijn Walraven explained about building reactive GraphQL apps with Apollo
First of all, he showed us the basics of Meteor and why Blaze was created. When Angular and React didn’t exist the Meteor devs didn’t have any other option except to create their own view layer. At the time, they needed to add their own package manager. Now the times have changed and Meteor is integrating really well with Angular & React, they even encourage developers to use them and they have official tutorials. Also they’re moving completely from their own package manager and embrace npm. Martijn also spoke about GraphQL and the difference between a REST API with millions of endpoints. Finally, he told us about Apollo.
Apollo is a GraphQL-based data stack which will feature a GraphQL client and server that can be used to efficiently build a new app from the ground up. The interesting thing he mentioned is that the Apollo client is built on top of Redux, and it will be really easy to implement it into existing apps that are already using Redux. If you want to learn more you can read this blogpost.
Sven Anders Robbestad convinced us that server-rendered apps will be around for a while
After his talk my first question was “Will there be a point in time where we won’t need server rendered apps anymore?” and he responded that a lot of things have to change for that to happen. HTTP2 will help a bit but it won’t be enough. Also, Jack Franklin made a good point on Twitter — “I don’t think there will ever be a time when we don’t need server side rendering — trains always go through tunnels! :)” So yes, I guess it’s time to master server rendered apps with React because of these main reasons:
- Page loading is too slow which can result in loss of potential customers
- Google Cache and SEO.
- People who disable JS in their browser
- People with really slow mobile connections
- People who use really old hardware
There are few solutions he mentioned for server rendering, the first solution is to use ReactDOMServer.renderToString but it can be slow due to lack of optimizations, it can make the server files really complex and you need to rely on a fetch method before render. An improved solution is react-dom-stream and an out of the box solution is fluxible.io
Jack Franklin showed us that testing React components can be easy-breezy if you use the right tools
Through a really entertaining and engaging talk, Jack showed us step-by-step how can React components be tested. His testing library of choice was tape but you can also use Jasmine, Mocha or whatever you want. To plug Babel into the tests you need to use babel-register. If you separate your logic and state from the UI, and the state is manipulated with only plain JS functions, you can easily test it separately. To test the actual React components though, you need react-addons-test-utils. It’s really convenient to test the components without a DOM. It’s called Shallow Rendering, and React doesn’t render the components but it gives you back a representation of how would the render look like. If you want your component tests to make sense when you look at them, you should look into using a doubler library instead of using a standard callback approach. With the React Test Utils you can also test user interactions like clicks etc. but considering the weird syntax and reaaally long method names like scryRenderedDOMComponentWithClass it’s preferred to use AirBnb’s library Enzyme which is mimicking jQuery’s API for DOM manipulation and traversal, so the syntax and the shallow rendering are better. So TL;DR is to use Enzyme and Tape and you’ll be fine for running tests in the command line, but if you want to run them in an actual browser you should use tape-run. You can find the slides here.
Johannes Stein has finally shown us a different use-case for React — Game Development
I mean, nothing can be cooler than attacking ships with cannonballs in React, am I right?Inspired by the fact that React was compared to Doom @ F8, he thinks that React is a perfect fit for games. We saw how they’re usually structured and also how different concepts in game development such as the entity-component pattern etc. can be implemented in React.
Oleg Slobodskoi compared all the solutions for styling in React, and explained further on why he prefers JSS
When most of the people start with styling in React, they are either stuck using regular css/sass or something like css-modules and inline styles. All of those solutions have some drawbacks. Like Oleg said, CSS is for documents, and React is all about components. There are a lot of problems with CSS at scale that we know of, and inline styles were supposed to solve all of that … but they kind of didn’t. They’re built into React but they don’t support media queries, keyframes and so on. To solve that you need to add something like Radium, which has some negatives too. That’s where libraries like aphrodite and JSS enter the game. JSS creates an internal representation for each rule. Each virtual rule knows how to stringify it to CSS rule and how to manipulate it. Also it generates a conflict free class name. At the end you just end up with <style> tags and some pretty boring CSS output.
Additionally, if you use react-jss integration, you get 2 performance optimizations: Lazy compilation and detection of unused styles. JSS has many other benefits like cutting vendor prefixes, selectors and lots of duplicated code from the payload, which can save up to 50% bandwidth. It also has a plugin API, which opens the possibilities for extensibility. The takeaway is:
- CSS in JS is not only for big projects, it’s for any maintainable project.
- Use Inline Styles for state styles and animations
- Don’t be religious. Keep an open mind and use tools that solve your problems!
You can see all the slides here.
Paul van Dam gave a presentation on implementing React at Coolblue.
He spoke about how last year they have started building new tooling using React and took us through a trip through the research and decision making that was part of coming to their current development stack.
Henrique Alves made us fall in love with “Building Loveable UIs”
First, he threw us back to the early days when we had Page Driven Development and everything was represented as HTML for the Markup, JS for the UI and CSS for the styling.
But along came React and everything has changed. Now we’re trying to use React components as building blocks of our apps. To make sure that we’re properly doing that, we need to make sure that the components are encapsulated, and easily composable. What that means is that they should be self-contained and not care about the data or the overall app state. When it comes to naming components you should be careful if you want the name of the component to represent what it actually does when you first look at it.
The next point: You’ll find your components much easier to reuse and reason about if you divide them into two categories: Container and Presentational.
Presentational components are taking care of how things look, have no dependency to the store, they don’t specify how the data is loaded or mutated, don’t have their own state, and most of the time are written as “Functional components”. Functional components are basically functions that receive the props as parameters and return the appropriate markup.
So if you embrace all of these principles, and you read a little bit more about them in the full slides, you will end up with building 💜able UIs.
Michael Weststrate blew our minds with his talk about MobX and how simple state management can be
Ok, but let’s not kid ourselves … state can be hard sometimes. Why?
You just have to keep track of so many things. Here’s where MobX shines because it can ensure efficiency and consistency. Michael said that state should be minimally defined which means: No caching, no data duplication, no cascading state changes and not worrying about how the app should react to the state. Everything should be derived and calculated automatically.
I’m pretty convinced that you can get the whole concept of MobX by looking at this one slide:
It’s just that simple. And if you define your state in JS classes you can simply decorate the properties with:
- @observable — which enables MobX to observe your data
- @computed — MobX ensures that this value is consistent with the state
You may be skeptical, but don’t doubt that MobX is very performant. When I say that I — really — mean — it . It’s already proven that it’s being used in production at Mendix and many other big companies, and in the demo Michael showed us that it can render a complicated React app with hundreds of dom nodes without a problem. Even though it if has nothing to do with immutable state, it still comes with the option to time travel through it and the awesome dev-tools can give you more detailed metrics about how much time did a component take for rendering, etc.
The takeaway is that MobX is scalable, the code is really simple, it gives you some architectural freedom and people actually love it and recommend it more and more! If you want to learn more you can see the slides or take this 10 minute interactive tutorial.
Joshua Sierles introduced us to The React Native Playground
Have you ever wanted to open an editor, quickly whip up a mobile app and see the results? You did, but it’s not that easy. The React Native Playground breaks down barriers to mobile development by making it easy to write React Native apps right in the browser, and test them across platforms and devices. It sounds unbelievable but you can actually check it out at https://rnplay.org/ and run one of the tons of examples that they have. You can pick between iOS and Android and play it right away or just scan a QR code and run it straight on your device.
It was also announced that the React Native team will soon be using interactive examples right next to every component in their documentation, which means that the users will be able to play around and interact with the components live on the RN site.
Last but not least, Alexey Kureev, and Mike Grabowski took their turns on stage to tell about how they solved a tooling problem for React Native
Unfortunately, React Native, being open-sourced last year, still suffers from the lack of great unified tooling. So if you install some RN library from npm and then you just import it into your project you will encounter tons of errors. The assets, native dependencies and custom fonts that the library can contain won’t be included. And what you want to do is focus on your app and not learn Objective-C, Java and not mess with Xcode and tons of dependencies.
Just use rnpm to install and manage your dependencies and the problem will disappear.
RNPM (React Native Package Manager) was built to ease your daily React Native development. Inspired by CocoaPods and fastlane it acts as your best friend and guides you through the native unknowns. It aims to work with almost all packages available with no extra configuration required.
But Alexey and Mike don’t like the duplication of tooling so at the conference they “officially” announced that rnpm will be merging with react-native-cli soon, which is really cool.
And that’s a wrap.
TL;DR It was a really well-organized conference with a lot to learn. I had tons of fun, met a lot of cool people and I can’t wait to see what we’ll learn next year.
Until then I'll be tweeting 24/7, and teaching React at React Academy.
All the videos from the conference are available here: https://www.youtube.com/playlist?list=PLNBNS7NRGKMG3uLrm5fgY02hJ87Wzb4IU
