ReactFest 2018 London write-up
I went to ReactFest 2018, a one-day open-source ReactJS conference in London. It’s a single-track conference with 14 talks and over 200 developers participating. Thanks to their diversity sponsorship scheme I was able to register for a free ticket to join this awesome event. I had a magical day filled with brilliant ideas, code to take home, good chats and strong Italian coffee.
This post is to let me put some quick notes for the key points and cool tips that I found most relevant, and also list out the libraries, tools, and resources for my reference.
Internationalization
Eli in her talk “React + i18n: You have no excuse!” told us how important internationalization is for the web content and how we can implement localization with React. This is my favorite talk personally. Being a non-native English speaker and having met so many people who couldn’t get access to the same amount of information online due to the language barrier, I think internationalization of our web content is one of the most important and urgent things to do for accessibility and inclusivity of the internet.
I also resonate with this topic professionally as I work as a developer at Sage Business Cloud Accounting and we have been building the accounting app serving our business clients across different locales and languages including English (British and American), Spanish, German and French (France and Canada). It’s good to learn from Eli’s experience in internationalizing React app at Trainline to reach more people and provide a better user experience.
And internationalization is not just about language. There are many more aspects about internationalization such as currency, writing system and writing direction (from left to right or right to left), date and time format, ordering, pluralization, grammar, relative time (eg. a few days ago), etc. These are all culture and region-specific that app developers should be conscious about right from the beginning of starting to write the code. Eli emphasized that it is so much easier to integrate internationalization early in your project, even though you may think that your users at an early stage are all English speakers and therefore there’s no need for that. She also suggested that we should always let the users choose their locale instead of guessing it from their IP address or header.
The libraries, tools, and resources for internationalizing React apps that Eli suggested to look up to are:
React Intl (Her favorite library)
Use language tags and sub tags
Integrates I18n.js with React Native
(Further reading: Internationalization in React)
GraphQL
Using GraphQL to deal with data in React is the main theme of the ReactFest throughout the day as it has been brought up by several speakers.
Peggy from Apollo introduced us to the new release of Apollo’s starter package and apollo-link-state to run GraphQL in the browser (!) and do client-side state management. She showed us how to import GraphQL from Apollo Boost, query local data with Apollo link state and uses Apollo Cache to normalize the data and keep it consistent. Also, they built Dev Tools for inspecting the cache. As an Open Source Engineer, Peggy told us that we should put ourselves as those who are just starting out to try your tools for the first time, especially when you are building open-source projects. “Empathy builds better software”. See here for Peggy’s presentation and demo app.
David talked about running GraphQL Server in client. He demoed how GraphQL can do declarative rendering and data fetching to optimize the compile time, referencing to Compiler architecture from Facebook. He also talked about how to use GraphQL to manage local view state, interact with legacy Rest APIs and resolve with HTTP requests. As Facebook designed GraphQL for replacing RestAPI, it is becoming a standardize language for data fetching and see it in many more places in the future. Kitze’s talk was “State management in a GraphQL era”. He said most of the time Redux for state management is overkill and suggested that MobX may be a good alternative for smaller scale React app to manage the state. The more important question is not which library is fancier, but what’s suitable for my app, my team, and my use case. And when using GraphQL, most of the time there’s no need for a state management library.
(Further reading: GraphQL Server on Cloud Functions for Firebase)
Garbage Collection
Jan from SoundCloud talks about how to do garbage collection in large scale JS app using the case of the SoundCloud app. The key problem SoundCloud faces is people use the app a lot and for a very long period of time. As a result, the app keeps adding data in the redux store, and at some point, the app is killed in the background. As it is using up too much memory, the app killed the windows and it is certainly something terrible that needs to be resolved. The classic ways to free memory in JS are 1) reload the page/hard refresh the page, which stops the music playing; 2) set myState = null but it refetches everything which is not ideal either. So here comes the garbage collector which removes whatever which has no reference linked to and release parts of the state. And because only selector function is being re-evaluated, there’s no re-rendering involved and therefore performance is not compromised. This can keep stable lower memory usage over time.
Design Systems
Siddharth from Auth0 talked about having design systems to put developers and designers on the same page when it comes to CSS and design guidelines. He walked us through some of the ways to “tokenize” the values and units by giving the abstract values concrete, memorable name. Also, he suggested that we can treat React component as design tokens. This practice is actually exercised in the Carbon repo. Carbon is an open-sourced library of React components for building web applications built and maintained by my awesome colleagues in Sage (Go check out the code). Our designers maintain a palette that gives definition of values. For example, we only defined 4 tones of orange and given them memorable names, such as beta (#FF5400) and orange-bright (#FF7D00), instead of having endless shades of orange. This can reduce ambiguity and miscommunication between dev and designer, and increase consistency of the tones, instead of having a terror of figuring out what “a bit darker yellow for that button” actually means. What Siddharth advocates are prioritised consistency over flexibility.
Some cool tools for writing documentation and creating components:
Cosmos: for creating reusable React components
Storybook: a development environment for UI components
React Styleguidist: writing documentation for the style
Airbnb react-sketchapp: React ← →Sketch
Further reading:
Building a Visual Language — Behind the scenes of our new design system (by Karri Saarinen, Design Lead on Airbnb Design System)
Productivity in Development
Stephanie from ThoughtWorks talked about “Productive React Development”, which was the only talk of the day about dev productivity on a more strategic level. She shared some best practices of testing React apps, from unit test to UI test. One key takeaway is to optimize the feedback loop. To increase productivity, we should reward the brain by keeping a constant state of flow. One good way is to make sure the feedback is fast after writing the code without waiting for it to be recompiled. We can use Hot Module Replacement and React Hot Loader to do the hot loading. Also, we should ask ourselves if the test gives you the right kind of feedback.
Stephanie shared her experience in using three of the most popular testing frameworks, Jest, Mocha, and AVA. AVA is fastest when the test files are not many, while Jest and Mocha are faster when the test files increase. So the lesson is there’s no such thing as the best testing frameworks. It’s all about use cases. And sometimes end-to-end tests (eg. Selenium and Cypress) may not be as effective as Consumer-Driven Contract Tests (with PACT framework).
A really cool testing framework that I haven’t heard of was Navalia, a browser automation framework based in GraphQL.
It’s indeed a GraphQL day.
(Further reading: 7 Reasons to Choose Consumer-Driven Contract Tests Over End-to-End Tests)
Suspense!
He gave a longer version of the talk in JSConf Iceland not long ago. All about
data fetching and code splitting to for performance increase.
If there’s live coding in the Olympics, that would be it.
And many more
There were so many more talks and ideas at the conference that I can’t list out all. Sophie on how to manage complicated data fetch flow with Redux-saga. Marcel on Reason and Bucklescript as the type language. Sara evaluated the pros and cons of several approaches to style components in React and says that we should pick the one that works the best for us. Go see her slides here. Thomas demo super cool VR and AR effect on React using just a few lines of code. He showed us how to use React-Web-AR for making AR content on top of a real image. React VR is pretty friendly for beginners too. I couldn’t believe that I can learn so much on a single track one-day tech conference. I think the format of having 20-minute talks and no Q&A made it possible to have as many talks possible while giving enough time to each speaker and plenty of breaks. Well done guys!
The Post-Conference Highlight
Over the weekend after the wonderful ReactFest conference while I was still recovering from all the learning and alcohol (did I mention the after party?), I went to the Sunday coding class of CodeYourFuture, a coding school organizing free 6-month coding bootcamps to refugees and asylum seekers who love to learn to code but lack the resources. Surprise, surprise! Dan came to visit us and talked to our students who are learning React.
About CodeYourFuture, our course contains:
And you are welcome to contribute to our syllabus
We are recruiting volunteers and students in London, Glasgow, Manchester, and Newcastle. Roles include:
- Lead Mentors
- PR Reviewers for student homework
- Other volunteers
Drop me an email (wendy@codeyourfuture.io) if you want to know more. Please spread the message!
