Highlights from the React Day Conference
The ecosystem around React itself is quite stable at the moment compared to the turbulent shifts that we’ve seen in recent years. Declarativeness rules the code and GraphQL is a real game changer.
In this article I’ve included some top picks to summarize the React Day Conference which took place in Berlin on December 2, 2017.
It’s all about the user
The React developer stack has matured and it definitely showed in the conference talks. In spite of the tough discussions we often have on how to properly call APIs, we usually end up with some sort of react-redux-webpack combination. As the javascript world has progressed over the years with more advanced tooling and libraries, we no longer need to solve trivial issues. Instead, our focus has shifted to a more abstract level — closer to the user.
This was demonstrated by several speakers during the day, most obviously by Kristin Baumann’s Designing with React. Kristin did a great job showing us how React Sketch.app can be leveraged in design, bringing real data into the process. AirBnB recently open-sourced an initial version of Lona, which aims to make it possible to generate cross-platform code & Sketch files at the same time. Interesting things may happen, so it’s definitely worth checking out.
WTFM — write the fantastic manual
Users — specifically developers — also played a big role in the lightning talk Humanizing your documentation by Carolyn Stransky. She pointed out one recurring mistake we often perpetrate. Let’s take a look at docs for Redux and then React Native, how do they differ? Moreover, how do they feel? If you’ve ever worked with both, I bet you perceived Redux Docs to be much better. That’s because it doesn’t just describe the API, but also contains the philosophy behind particular use cases. Carolyn explains precisely why we postpone writing docs for later, even though we should start in the beginning when use cases are being discussed. So you should keep this in mind the next time you develop something.
The peculiar story of Storybook
Norbert de Langen is the core maintainer of Storybook and in his presentation Building Storybook he took us backstage and showed us how a few diverse people around the globe put their free time into delivering this tool which is used by many companies. It’s always interesting to learn how little there is to prevent you from becoming an open source contributor. Norbert just walked over when Kadira, the original maintainer, went bankrupt in May. He gained full rights to the repository overnight and established the Storybook organization.
If you take documentation seriously, have a look at Storybook and start using it early — when your first use cases & React components are created. @storybook/addon-jest: this fresh new add-on may help you on your way.
GraphQL: the game changer
“Delete your twitter account to avoid hype.”
Kristijan Ristovski
One of the most influential highlights of the day was definitely React state management in a GraphQL era by Kristijan Ristovski a.k.a Kitze. Kristijan proved his deep knowledge of state management in applications as a consultant on various projects. He can tell the difference between a useful library and hype with a high degree of certainty. Here are a few points that Kristijan mentioned which we had to learn the hard way:
- Thread each route as a miniapp — everyone talks about microservices on the backend, but we often magically forget about it when we switch to a browser environment. You simply don’t need the added difficulty when setting your routes. Instead, create small app for each route and let the page refresh when navigating. It’s not wrong at all.
- Think about your target users (see, again!). Some users may live in tunnels, in which case redux-offline would be useful. But if all of your potential customers are from NY, surfing on the latest iPhone, then it’s probably going to be useless.
- Say yes to GraphQL — the reasons deserve an article on its own. It’s the most significant step in development in recent years, which among other things enables you to avoid making accidental breaking changes in the API and from writing the same repetitive “prepare data payload, fetch, handle, dispatch” code all over again.
- There is no strict yes or no whether you need redux along with your GraphQL stack. If you feel inclined to not include Redux, Apollo recently released apollo-link-state to manage state in a GraphQL style.
And because we actively use & love GraphQL at Kiwi.com, we couldn’t resist implementing a simple mobile app, taking advantage of the Apollo local state. Check out the expo snack: https://snack.expo.io/@kubajz/graphql-todo-list
