React Norway 2019 (Notes)

I attended React Norway 2019, an event targeted towards sharing the latest techniques and best practices in the React community. This was my first non north-american conference that I attend. Looking back, I enjoyed the conference a lot. The event was well organized, had a good line-up of speakers, and was in a beautiful venue. Unfortunately, there doesn’t seem to be any video recordings of the talk for this year’s conference. I decided to share my notes in case someone else finds them useful.

Curious Cases of GraphQL (Nader Dabit)

Nader spoke about how developers are using GraphQL as an API gateway to accomplish things that you may have never thought possible. Nader dug into the code of a couple of applications that uses GraphQL and went thought the steps of modelling the data and defining the schema type & operations.

  • GraphQL Real-time Drawing Canvas
  • GraphQL Image Rekognition
  • Real-time Q & A in Markdown
  • Real-time Music Collaboration
  • GraphQL text to audio translation

The source code for the demos can be found here.

Using React in large teams (Kåre Høvik)

What Kåre does at Microsoft:

  • Everything people related
  • Office, outlook, etc.
  • Deliver the front-end

Evaluating React:

  • Clean programming model
  • Decent performance
  • Allowed usage of Typescript
  • Functional coding style
  • Crappy license

2016:

  • React - flux
  • Typescript
  • Gulp
  • Git

2017 (going native):

  • React native to reuse code from web (70% of the web code is now shared with react native)
  • Common repo for native
  • First attempt to monorepo
    • Less maintenance overhead
    • More reliable tools
    • Easier package integration (no more version mess)

Monorepo benefits:

  • Less maintenance overhead
  • Easier package integration (no more version mess)
  • More reliable tools

Key learning:

  • Increased knowledge sharing between teams/products
  • Increased developer flexibility
  • Shorter ramp up time - no longer need to learn other JS frameworks (React is only a library)

Ecommerce with React and fast performance (Håkoon Gullord Krogh)

Why build yourself when you have Shopify and friends?

  • Enables you to custom tailor it to your customers
  • Makes you stand out
  • Allows your site to be discovered

SEO:

  • Good URL for SEO performance:
    • A bad URL is one with too many backslashes
    • Use hyphens, not slashes unless they’re a critical part of the product or category
    • Use words not numbers
      • Don’t - teddy-bear?id=54321
      • Do - teddy-bear/dingo
  • E-commerce better with server-side rendering (SSR)
    • SPA is relatively new. Not all crawlers are configured to handle single page applications (SPA)
    • Social media crawlers are bad with SPA
    • Google is able to crawl SPAs

Speed:

  • Time between the first meaningful paint and time to interactive is your application’s biggest lie
    • Elements are displayed but clicks won’t work
    • Scroll is sluggish
  • If you are running an e-commerce site, then you probably want some buttons to react right away. A button like “BUY” should work without having to wait and click again.

Building a typed and code split Redux store (Matthew Gerstman)

  • Redux - statement management system for React applications.
  • Code-split your store to minimize the amount of JavaScript served
    • Asynchronously register reducers - allows to async load code associated with those reducers

React Advanced Patterns (Manjula Dube)

Manjula goes over a list of react patterns. The list of the patterns discussed can be found here.

Don’t build that app! (Luke Jackson)

Luke does a lot of prototyping at work:

  • Has to pull hundred dependencies
  • npx create-react-app results in around 200mb on disk for every app

This is not sustainable for a 128gb hard drive. Luke shows how you can build React applications without a build step simply by relying on ES modules and on tagged template literals. See the demo of a React app without node_modules, webpack, and babel.

Be a React a11y: Making React applications work for everyone (Yuraima Estevez)

Accessibility - any website that is designed and developed so that people with disabilities can use them.

Why is it important?

  • Equal access and equal opportunity
  • $$$ (e.g., Target got sued for 6 million dollars)
  • It’s the right thing to do

A11y Principles:

  1. Perceivable
  2. Operable
  3. Understandable
  4. Robust

Perceivable:

  • Information and UI components must be presentable to users in ways they can perceive (e.g., screen reader). For example, provide text alternatives for any non-text content. Set the “alt” attribute in all image elements.

Operable:

  • Keyboard accessible
  • Manage keyboardd focus

Understandable:

  • Provide input assistance
  • Label your form fields
  • Identify input errors when they occur. For example, when there is a error message, set focus on error message. If more than one error, you can default to the first error message on that form. That way the user is able to tab into the other error messages and fix those errors.

Robust:

  • Content must be interpreted by a wide variety of user agents, including assistive technologies. Make sure your markup is validated and elements are used according to their specifications. For example, do not use a div as the direct child of a ol element. That’s invalid code. There is possibility of breaking functionality for our assistive technology. To remove this issue, we can use react fragments to replace the div.