🎵 React Summit '21 Notes

PS

Peter Sun /

🪙 Credit goes to all speakers at React Summit '21

Internationalizing React#

Definitions

  1. i18n (internaltionalization) — Process of architecting your app so l10n works
  2. l10n (localization) — Making the content and experience suitable for a given locale

Requirements

  1. Formatting the date correctly based on locale (see the date formatting libraries).
  2. Allowing bidirectionally of content layout since there are some languages that read from right to left vs the common left to right (see the RTL formatting libraries).
  3. Text should be translated for different languages.

Locale Overview

There are 5 parts to localization: language, script, country, variant and extension. The most common used is just language and country codes as denoted in es-ES (left value is the language and the right value is the country) for spanish in spain. The data type used for accessing translation stting are standardized to ensure this look up heavy process is fast.

const TranslationMap = { "en-ES" : { SomeLabel: "Translated Label Text" } }

References

  1. Internationalization — depends on locale and country code
  2. Date Formatting — depends on locale and country code
  3. RTL (right to left) — depends on if we want too render LTR or RTL direction

Remote Rendering With Web Workers#

Introduction

Shopify built this to run external code in a safe a secure way (i.e making the web worker a sandbox).

💡 This can be extended to be run on the server instead to define components.

Core Concepts

  1. Javascript sandbox
    • Securely execute code in a background thread
    • Communicate to the main thread by sending messages (see RPC section).
    • As a web worker on web and as a headless JS engine on iOS/Android
  2. RPC — Remote procedure calls for communication between the main thread and helper (web worker / headless JS engine)
  3. Proxy layer — A way of allowing the host to call functions in the JS sandbox and vice versa

Libraries

  1. Remote-UI

Building Better Websites With Remix#

Why Remix?

  1. Remix fully server side rendered react pages, this means it seems like a single page application but only sends the minimum required javascript and css files for running what is rendered.
  2. Styles are programmatically removed when their respective routes are not rendered.
  3. JSX is compiled to HTML via react.hydrate and only that is sent to the browser.

Why not Remix?

  1. There direct competitor is NextJS and are more battle tested
  2. Remix is still in early access and is not free OSS

References

  1. Remix
  2. Remix Starter Projects

Let's Build React Query in 150 Lines of Code!#

Requirements

  1. It needs to fetch, cache and update the data.
  2. Data should be able to come from anywhere (i.e client) as long as it returns a promise.
  3. It should provide cached data until it is updated.
  4. It should be only triggered once even if used in multiple components.

System Design

  1. We need to keep track of these different values (i.e using state) in an API request. These allows us to cache queries and prevent duplicate inflight queries:
    • isFetching
    • data
    • error
    • status
    • lastUpdated
    • queryHash — The query parameters used and their corresponding data
    • queryKey — The query parameters used
    • promise — A pointer to hold onto the resolving promise (i.e in flight API request)
    • subscribers — Who to notify when fetched data has changed?
  2. Client should be defined by users (and abstracted) in case you would like to use a custom built API client.
  3. Query observer to update any subscribers, refetching logic with stale time, clearing cache (i.e garbage collection)

💡 You can force rerenders via const [,rerender] = React.useReducer (i=>,o)

Scaling React Development with Nx#

Core Concepts

Nx is a library to help monorepo management, specifically:

  1. Dependency graph (on how the react components are imported)
  2. New project creation (based on best practices)
  3. Dependency constraints (in case some pages should not access certain internal libraries or only access shared libraries)

💡 Note that Nx seems to be opinionated about best practices which might conform to how things are done for you (requires prototyping to see if the project is suitable).

References

  1. Nx

Doing the Least Amount of Work Possible: An Intro to Runtime Performance#

Core Concepts

Runtime performance starts when the page is fully interactive and the javascript has been loaded into the browser (i.e blocking the main thread). This are some runtime performance issues:

  1. Computationally expensive tasks
  2. Animations and graphical updates
  3. Reflow/Repaint and layout
  4. Parsing
  5. Memory Leaks

A runtime performance drop is apparent since the website freezes up, drops frames or has input delay. There are some prescriptive things to improve runtime performance (do not over optimize):

  1. Use regular for loops (i.e scale properly overtime)
  2. Instead of searching large arrays, use lookup tables
  3. Avoid creating new objects
  4. Turn off animation (perceived performance)
  5. Avoid reflow/relayouts
  6. Caching
  7. Sneaky tricks (i.e set object index to undefined instead of using the delete keyword)

How To

  1. Profile runtime performance
    • Go to the developer console in Google Chrome.
    • Go to the performance tab and click record.
    • Perform the action you want to measure.
    • Anything with the red indicator is blocking the main thread.
    • Right clicking and selecting performance indicator will bring up the CPU usage chart of the app.
  2. Profile specific sections of code (runtime performance related):
    • Add the performance.mark to the start and end of the relevant code to measure.
    • Add performance.measure to compare between the start and end markers.
    • Begin profiling runtime performance (see 1). There will be a new timings field with the relevant markers to view how long each step is taking.
  3. Profile memory performance
    • Go to the developer console in Google Chrome.
    • Go to the memory tab and click record.
    • Perform the action you want to measure.
    • The objects stored in memory will be visible (and their corresponding variable naming) and how they evolved (vs before the snapshot).

Lessons Learnt from Building Interactive React Applications#

Core Concepts

Animation should always be used to provide visual cues to the user hinting what to expect. These are some tips when designing animations for web / application interactions:

  1. Subtly fading in text after loading (without a loading indicator feels more native like the page is loading but this does not work for load times > 500ms).
  2. Transform position of content from where it should be coming from (clicking back should move the current page should to the right).
  3. Be sure to take into considerations accessibility concerns in reduce motion.

Libraries

  1. Framer motion (hides abstraction when components are initially placed in the DOM)

Building Accessible React Components#

Introduction

The main guideline used to benchmark accessibility is WCAG. There are 3 grades to achieve A, AA, AAA (minimum grade to be considered accessible is A)

Main Principles

  1. Perceivable — Content can be viewed by sight impaired users.
  2. Operable — Keyboard / mouse, text read via screen reader, etc
  3. Understandable — Know which input fields are required, etc
  4. Robust — Isn't buggy.

Form Specific Tips

These are some important element properties when designing forms to be accessible are :

  1. required — If this input is required.
  2. aria-required — If this input is required when there is no HTML5 support.
  3. aria-labeledby — If this input has specific instructions and links to another DOM element with text (i.e another DOM element labels this input element).
  4. aria-describedby — Similar to aria-labeledby, but will override aria-labeledby. It is useful to tag errors with this component.
  5. aria-invalid – Used in conjunction with aria-describedby, if it an error.
  6. aria-disabled - Used instead of disabled; Disabled removes elements from the accessibility tree.

Generic Concerns

  1. Do not remove focus outlines, making it transparent helps with high contrast edge cases.
  2. Make sure items are focusable where needed (try tab-ing in each page).
  3. Dialogs are tricky and using libraries like react-a11y-dialog is suggested instead of building from scratch.
  4. content-visibility should be used to hide elements out of the viewport.
  5. Adding commas are great in alt text for when the screen reader should pause.
  6. Navigating / creating a new tab should be explicitly mentioned in links under the alt text.
  7. Media queries are a great way of capturing if the reduce motion option is toggled.

References

  1. jsx-a11y
  2. axe-core/react
  3. pa11y
  4. storybook-addon-a11y
  5. WAVE Browser Extensions
  6. Web AIM Color Contrast Checker

React on the Blockchain#

References

  1. web3 is an interface to the blockchain
  2. truffle is used to build smart contracts
  3. solidity-coverage is used for linting
  4. openzeppelin-solidity is used for the math behind hashing on the merkle tree

Platform powered: Build a Frontend Platform to Scale as fast as You do?#

Introduction

Usually tools and processes are only effective in one order go magnitude of scale in a company, different approaches help in the various levels of scale. In Lyft, they migrated from monolith to micro services which lead to:

  1. Long lived services required maintenance
  2. Platform was fragmenting
  3. Infrastructure updates were hard to apply (support is required for all versions released)

Core Concepts

Building the application as a tiered service, this allows seperation of concerns:

  1. Top layer; App — Apps frontend which most developer work on to ship features.
  2. Mid Layer; Libraries — The helper methods most used in the top layer.
  3. Low Layer; Infrastructure — Configurations to build the Javascript bundle

The lower two levels are managed with a core team to empower the top layer (where all product engineers work on). The most problems come in the middle layer in terms of managing and structuring libraries (to prevent bloat and duplication).

Lyft Specific Solution

  1. Building on top of NextJS (since it comes out of the box with best practices to follow) which solves the lowest level of the stack.
  2. Standardizing libraries which help business logic development via:
    • Library helpers for frontend functions (essentially services to build a react context for passing information through the application).
    • Express middleware for serverside functions.
  3. JSCodeShift to migrate breaking changes like exported naming from libraries (no longer run into breaking changes).
  4. Versioned migrations to allow better tracking of what migrations should be run (since they are stateful).
  5. Tying both the platform and library versions (this joins the two layers into one).

Test Kitchen: A Recipe for Good Tests#

Core Concepts

  1. Test should inspire confidence that the core functionality does not break.
  2. Tests should be automated (so developers do not have to run it manually and we can run it all the time). It is important to run on the branch before merging and on the main branch after merging.
  3. Tests should be fast:
    • Run tests in parallel.
    • Do not wait/sleep in tests unless necessary.
  4. Tests should be behavioral and structure intensive and be based on the consumer perspective where possible.
  5. Tests should be deterministic (same input and output), isolated (independent from other tests) and composable(runnable without side effects and race condition).
  6. Tests should be specific and one per test case.
  7. Tests should be short.
  8. Test should have a good description.
  9. Tests should be expressive (visual regression instead of validating snapshot for color changes).
  10. Test should be writable.

How Core Web Vitals Will Affect Google Ranking in 2021#

Core Concepts

It is important to increase performance; since a decrease of 100ms on latency increases sales by 1%. The best way to measure this performance is through the end user perceived experience via Core Web Vitals:

  1. Measuring Loading — LCP; Largest Contentful Paint, This is when the largest item has been loaded on to the screen (Good < 2.5s > Meh < 4s > Poor).
  2. Measuring Interactivity — FID; First Input Delay, This is when the first input has been interacted with and when the browser processes the event (Good < 100ms?> Meh < 300ms > Poor).
  3. Measuring visual stability — CLS; Cumulative Layout Shift, This is when the content moves on the page?(Good < 0.1 > Meh < 0.25 > Poor).

NextJS Specific Tips

  1. Prerender content via Static generation or server sider rendering.
  2. Optimize images:
    • Use image and with to prevent layout shift.
    • Lazy load images based on viewport.
    • Use modern image types (WebP).
    • Use source sets to load correct image quality per device.
  3. Optimize fonts:
    • Use a variable font.
    • Preload your font file.
    • Use font-display: optional to prevent layout shifts.

References

  1. web-vitals
  2. Lighthouse

XState: The Visual Future of State Management#

Introduction

State and events are the best way to application state (think about redux) but are not easy to visualize. XState tries to take learnings from Redux but makes it state first and allows it to be easily visualized, test generation, analytics and autogeneration. It allows you to catch DOM events and updating the state accordingly.

Library Specific Functions

  1. createModel — Allows you to store data (also know as context)
  2. createMachine — Creates the state machine
  3. useSelector — Pulls data from the machine

References

  1. xState

Lessons To Outlive React#

They can be grouped into core, interface, productionize and humanize concepts. These are the lessons in detail:

  1. Reconciler + Scheduler Pattern
    • To make a program regenerate every time, add caching and structural sharing of previous files.
    • This means each build system has two parts, a scheduler which ?orchestrates what and when work needs to be done and the rebuilder which hashes and then decide whether to build or extract from the cache.
  2. Minimal API Surface Area (similar to YAGNI)
    • Remove as much complexity as you add , it's much easeier to recover from an explicit and repetitive API.
    • Use design patterns instead of increasing the framework.
  3. API Design is Language Design
    • Name something with better intent and assumption they will become part of language.
  4. Optimize for Change
    • It should be easy to read and write (memorable, guessable, unambiguous and readable).
    • Easy to change as new requirements come in (production pivots).
    • Enable local Reasoning by having all context within the same file so users do not have to grok global context.
  5. Test the Public API (write test for what is exposed to the user).
  6. Devtools is not optional.
    • React Codemods are great to auto migrate code.
    • Error codes — Allows better understanding and standardization of possible errors.
    • Readable lint errors in console — So users know what they are doing wrong
    • Fixtures — Be able to toggle on different feature flags for different combination of use cases
    • Hold the line — Do not allow your important stats to move in the wrong direction (test coverage, type coverage, bundle sizes, perf metrics, etc)
  7. Community is Important, listen to feedback (they are the network effect).

Scaling Component Across Multiple Frameworks#

Core Concepts

The best way to create a standardized component would be to create a DOM element at the low level via CustomElements (see mozilla docs on custom elements) and only uses native functionality. This element will be usable with React Angular, etc.

Libraries

  1. Stencil

Graphic = fn(state)#

Core Concepts

User experience is always a function of state (we always show things based on some state). This applies to icons as well which means we should be abstracting icons as React components since SVGs can be rendered dynamically with props (change color and size).

Build a UI that learns: Intelligent Prefetching with React and TensorFlow.js#

Core Concepts

In a large single page app, the best way to reduce bundle size is to defer the loading of each screen until navigation happens (via React.lazy). To optimize the flow, sometimes we want to prefetch routes to reduce the loading time. In this use case, data can be collected to identify user's full navigation pattern (per session); With Deep Learning, it allows the system to predict the sequence or next page the user will be navigating to. The best way to share this deep learning model is through Tensorflow's model object; Analysis is done in the backend and prediction are run in the client.

References

  1. TensorFlow.js

We Don't Know How React State Hooks Work#

💡 Setting state in an async function, each call to set state will cause a re-render (eager loading). If it is within one function context, all calls to set states will be implemented before the UI is updated (lazy loading).

Inside Fiber: An Overview Of React's Reconciliation Algorithm#

Introduction

To match 60fps, a new frame is displayed every 16ms. This means if the rendering and reconciliation takes > 16ms, there would be a dropped framed with causes a choppy or janky UI (this is extremely important for Javascript since it is a single threaded language). React Fiber does a simulation of being multi threaded by scheduling and prioritizating work. We can interactiwith it via React's Concurrent which is experimental. For example, useDeferred hook schedules the work with a different priority. This means the reconcilation can:

  1. Pause work and resume it later (and not block the thread).
  2. Assign different priorities to different types of work.
  3. Reuse previously computed work, or throw it away if no longer needed.

Definitions

  1. Fiber — A Javascript object that contains information about a component, it's input, and it's output. This is the smallest unit in React (each element is represented as a Fiber).
  2. Fiber Trees — A in-memory version of the DOM React uses to compute what components should be updated. There is a current and work-in-progress tree to compute the current and future states. Another way to think about these two trees are like the master branch vs your personal branch.When the work is completed, you push to master without hindering it's state and when it's convenient to the master branch (in this case main thread should be available).
  3. Two phase algorithm — On the first pass, it does reconciliation (pause-able/continue-able) and the second pass it does commit (uninterruptible).

Building the Right Product and Building It Right: A Glimpse into Extreme Programming and Atomic Design#

Core Concepts

  1. Communication — Heavily communicate so everyone is on the same page
  2. Simplicity — We want to build the smallest MVP to test the ideas.
  3. Feedback — We want to get feedback ASAP to provide more insight for the next iteration of the work
  4. Courage — Throw things away if users don't use it
  5. Respect — Respect all opinions and create a safe space for it

Job Descriptions

  1. Product Mangers — Get buy in from the company and ensure features are broken down in a sustainable product roadmap.
  2. Designers — Evaluate the product design and extract the feedback from the users.
  3. Engineers — Evaluate feasibility and implement the work.

Stories and Strategies from Converting to TypeScript#

Core Concepts

  1. Take note of hidden costs (user interviews) before proposals, etc.
  2. Hype train is really useful for pushing people to adopt new.
  3. Advertise it by helping individuals understand the problem and the solution.
  4. Knowledge Sharing is important via Internal Presentation / Brown Bags / Code Pairing (does not scale but useful).
  5. Spreading consensus with two helpers:
    • Area Experts — People who know the technology on the best practices and how to bring it into the company (2 per project to bounce off ideas)
    • Cheerleaders — People are excited to try things out to be beta testers and help as the network effect (1 per affected team)
  6. Create a style guide document where possible and have a FAQs.
  7. Automate wherever possible.
  8. Never convert and change behavior.
  9. Celebrate, so people remember the work!

Typescript Specific Workflow

  1. Convert few files (minimal disruption without sudden change).
  2. Integrations should be built up beforehand for the incremental change.
  3. Ensure these configurations are turned on to prioritize ease of adoption:
    • allowJS/checkJS: off — No need to disrupt engineer with messages for legacy code.
    • noImplicitAny: off — Too time consuming & difficult in a JS/TS codebase.
    • strictNullchecks: on — Useful and not expensive.
  4. Have dedicated PRs for converting things to typescript to allow bite size work for various engineers to try the migration. The PR description should explain any new syntax for others.
  5. Monitor how the Typescript percentage changes overtime.
  6. Optimize for comfort so everyone feels comfortable with the changes.
  7. Used TypeStat (custom helper) to programmatically help creating types, etc.
  8. Any casts are fine to get things to migrate to Typescript.
Subscribe to the newsletter

Get early access to new articles.

Discuss on Twitter • Edit on GitHub

Made with ❤️ by Peter; Inspired by Lee Robinson