React Day Berlin 2019: Conference highlights

The Deeson development team descended on a cold December in Berlin to attend the React Day conference. As our first React conference experience, it did not disappoint! 

The event had a really edgy techno feel, with a CyberPunk look and feel to the slide decks and conference signage design, and MC’s entertaining us between talks.

The talks themselves were all excellent, which we expected after listening to other people’s feedback on previous React events.  

Some of our favourite talks from the conference:

The past, present and future of CSS-in-JS

https://youtu.be/3iSPDDPRLqA?t=1734 

The keynote talk was given by Max Stoiber. He briefly looked at the technique of writing CSS styling information directly into the JavaScript that generates your components, followed by an extensive stroll through the history of the libraries and people that have developed and popularised this technique over the past five years.

Essentially, instead of having a separate stylesheet inside your component folder, you put the styling inside the JavaScript file alongside the React component code. 

Although we have not yet tried this technique at Deeson, given its increasing interest it is something we are looking forward to exploring soon. 

Advantage:  JavaScript understands the styling information directly and can place exactly the right styling information for any given page request into the page header. This means that there is no need for separate hosting of stylesheets and no additional overheads of the browser calling out for styling information, which makes page requests lightning fast.

Disadvantage: If your team includes pure styling people who don’t know JavaScript, they might be locked out of the development unless they learn enough of the JavaScript structure to get by.

The evolution of the idea is an interesting example of how a community has an idea and then develops it by trying to better each other as well as sharing and collaborating and trying out new approaches.  

When one library finds an enhancement, the others soon follow.

Overall, the talk was very good and insightful; a great way to start the conference.

React is fiction

https://youtu.be/3iSPDDPRLqA?t=18324

I personally really enjoyed this talk from Jenn Creighton. From the title alone, I wasn’t sure what it would entail, but I’m glad I stuck around. 

It was a very well-delivered and expertly considered evaluation of how our work as engineers is actually an art form. 

Jenn nicely illustrated how breaking an application up into components isn’t an absolute science and there’s a creative skill at play here. We have to craft our work and remember that we can always make revisions as we go.

A big part of the developer job role requires applying logical approaches to the challenges that we are presented with. So, it’s natural that we try to optimise and refine the code that we write down to an absolute. Quite often, this results in an almost obsessive application of the DRY (don’t repeat yourself) principle. 

Instead, Jenn showed us that we should write what we know, rather than trying to optimize for situations that we don’t yet understand. Just write the code for what we know now and don’t be afraid of refactoring later.

This talk really resonated with me; it was really well put together and demonstrated a principle that goes way beyond React. I’d recommend anyone in any area of web development watch it.

Compassion driven development: building an accessible react UI

https://youtu.be/3iSPDDPRLqA?t=3866 

At Deeson, we are passionate about creating websites that are accessible for the many, not the few. But how does this ethos carry forward when working with emerging technologies like React?

As React gets rendered on the client side, can we still make our components accessible? 

Tae’lur Alexi gave a comprehensive talk at the conference on creating more accessible UI with React. It was really great to see that accessibility is becoming a priority for developers and Tae’lur gave some great tips on how we can all test our components to ensure they are accessible. 

"Accessibility is a priority, not an afterthought."

Here’s a small list of some of the things we should all be checking: 

• Keyboard accessibility:  Can the user navigate with just the keyboard?
• Resizable text: Can the text be resized by the user?
• Colour contrast: Do the colours used have enough contrast?
• Focus management: Can you direct the user to key areas with focus.?
• Alt-text: Do images have descriptive text?

One of the most helpful things for me as a developer was discovering a linting tool for JSX which helps to ensure your react components remain accessible as you code them. 

I’m really looking forward to using this on our next project and I encourage all developers to do the same. 

It’s time we all develop with accessibility at the forefront of our minds.

Testing is all about principles 

https://youtu.be/3iSPDDPRLqA?t=19745 

Alex Lobera began the talk by discussing how much of our codebase we should be aiming to cover with tests. 

He discussed the tradeoffs developers will make when aiming for high test coverage, and the diminishing returns as their coverage reaches 100%. 

He also mentioned how at 100% coverage we may be testing the quirks of our implementation rather than the required behaviour.

Alex made the point that the testing library being used, whether ​react-testing-library ​or Enzyme​, is much less important than how the code being tested is structured. 

He emphasised the extra flexibility provided by using dependency injection patterns rather than mocking; a situation I have encountered many times before and strongly agree with.

I was impressed with the example tests Alex presented and I am inspired to write many more component tests of my own. I even hope to write some component interaction behaviour in a TDD style in the near future.

Performance anxiety with React

https://youtu.be/3iSPDDPRLqA?t=5748 

Jessica Leach worked through a long list of areas that she, which you can consider using to help with the performance of your React application.

While, as developers, we can’t control the hardware that our applications run on, we can control things like bundle size and ways to reduce the load time of the application so that slower connections will still load in good time, especially with the majority of users being on mobile devices nowadays. Performance is important and something that we should all be actively considering when building applications.

One key area that causes performance problems is when React re-renders the Virtual DOM. 

Any changes to a parent component cause a rerender of each of its children components. These re-renders of components that don’t need re-rendering cause large performance problems.

Fortunately, there are profilers to help you find any issues with this - such as whyDidYouRender and React Profiler. These help you to determine where you are getting wasted re-renders of your application.

To avoid wasted re-renders, you should use the shouldComponentUpdate function within your components. By returning false for a component, it will stop that component from being re-rendered when its parent state changes.

Overusing this can cause unexpected problems if you aren’t careful, and should therefore only really be used if it provides a measurable improvement to your application when using the profilers.

A better way is to construct your components to extend PureComponent instead of a regular React class component. This uses shouldComponentUpdate under the hood and only updates if one of its properties are updated.

If you have an expensive operation being handled by component, you could look at ‘memorising’ your component. 

Memorisation is a powerful tool that acts as a cache for your component/ application. This can be done by your component using React.memo or calling the memorise callback within your application.

The use of hooks can also be used (such as useMemo & useCallback) to help with performance within your application, so should be considered when building.

When rendering lists, you need to specify a ‘key’. It is tempting to use the array key for this, but this can cause problems when items in your array are removed and added etc., so it is better to use a specific ID for each item in the list.

With large applications, the size of your bundle can be large due to the number of components and other factors. You can use lazy loading of components using react.lazy and use suspense methods to only load in the components that you need.

Finally, webpack analysers are great tools for analysing your bundle of applications. Using this, you can check on what the large dependencies on libraries are or duplicate libraries that have been included. Also, you can identify similar libraries which may be doing the same operations.

Watch the full list of talks online: https://www.youtube.com/channel/UC1EYHmQYBUJjkmL6OtK4rlw