DEV Community: Ilya Lyamkin

What are Web Standards and how does Web Browser work?

Ilya Lyamkin — Wed, 27 May 2020 13:10:38 +0000

Let me tell you a story. Once I was building yet another date picker component for our design system. It consists of text input and pop-up with a calendar that shows by clicking on it. Then pop-up can be closed on click outside or if the date was selected.

Most implementations of the click outside logic made with actual click listeners attached to the DOM. However, I wanted to build our date picker accessible, so you could open a calendar with tabs and close the same way. Additionally, click listeners may conflict with each other if you put several date pickers on the page.

What if you could just rely on native focus and blur events instead of detecting clicks outside? They naturally support tabs, touch and click events, and already implemented in the browser. The only problem you need to solve in this case is when you click on the pop-up but without date selection: focus shifts to the calendar, triggering blur event on the text input and eventually closing the pop-up.

At this point, I started wondering if there is a way to click but do not shift a focus. After quick googling, I found a way to do it: prevent the default action of the mouseDown event for the pop-up. Just like that in one line, all clicks worked but the focus was still on the text input.

It seemed like that's the solution, let's move forward, but something inside of me was stopping me from that. Why specifically mouseDown and not mouseUp prevents focus but propagates click? Is it some part of the living standards? Can we rely on that? Does it work cross-browser? React Testing Library that we used to do integration tests also didn't support it and I'd have to change simulation function.

What is Web Standard?

Alright, since the Stack Overflow answer wasn't enough for me, so what could be a better place to learn about browser behavior than the web standards?

You probably heard about W3C or World Wide Web Consortium. It's an international community that develops open standards for the Web. W3C makes sure that everyone follows the same guidelines and we don't have to support dozens completely different environments. If you visit their website, you'll find the list of all standards they're working on.

Let's have a look at the one document that might have an answer to our questions - UI Events Standard. This document specifies the DOM event flow, defines a list of events and their execution order. If you thought that standards are boring, obscure, and hard-to-understand text blocks, then jump straight to DOM Event Architecture section that explains event bubbling and capturing with nice pictures and still being very specific as standard supposed to be. You'd be surprised by the quality of it, it's really well-written with a lot of examples and recommendations.

It also has a definition of our mouseDown event and its default actions:

"Many implementations use the mousedown event to begin a variety of contextually dependent default actions. These default actions can be prevented if this event is canceled. Some of these default actions could include: beginning a drag/drop interaction with an image or link, starting text selection, etc. Additionally, some implementations provide a mouse-driven panning feature that is activated when the middle mouse button is pressed at the time the mousedown event is dispatched."

Alright, so our event has some default actions, but there is nothing specific about focus because it really depends on browser implementations. Let's check them out.

Introduction to browser engines

A modern browser is a quite complicated piece of software with the codebase around tens of millions of lines of code. So it's usually split into several parts.

To find a place where focus events are defined, we need to get an overview of what each part is responsible for. Let's start with Chromium and its design documentation Getting Around The Chrome Source Code. As you can see there is a lot of modules responsible for different logic.

Let's briefly go over them to get the idea of how it works together.

chrome: it's a base app with startup logic, UI, and all windows. It contains the projects for chrome.exe and chrome.dll. Resources such as icons or cursors you can also find here.
content: it's a backend of the app which handles communication with child processes.
net: this is the networking library that helps to make queries to websites.
base: a place for common code shared between all sub-projects. This could include things like string manipulation, generic utilities, etc.
blink: it's a rendering engine that responsible for the whole rendering pipeline including DOM trees, styles, events, V8 integration.
v8: a final big part of a browser - Javascript engine. Its job is to compile JavaScript to native machine code.

As you can see browser consist of several independent parts that talk to each other via API. The most interesting parts for developers are usually Blink and V8. Browser defined default actions are not part of V8, but Blink should have all of them defined and implemented. But before we jump into the Blink codebase, let's understand how web browsers work from a user point of view.

Rendering pipeline

Imagine you enter domain address in a browser, then it fetches and loads a bunch of assets: HTML, CSS, and JS files, images, icons. But what would happen next?

As a first step, HTML files would be parsed and turned into a DOM tree. The DOM is not only the internal representation of the page but also an API exposed to Javascript for querying or modifying the rendering through a system called "bindings".

After the DOM tree, the next step is to process the CSS styles. For that purpose browsers have a CSS parser that builds a model of the style rules. Having built a model for style rules, we can merge them together with a set of default styles supplied by the browser and compute the final value of every style property for every DOM element. This process is called style resolving (or recalc).

In the next layout part, we need to determine the visual geometry of all the elements. At this stage each element gets its coordinates (x and y), width, and height. The layout engine calculates and keeps records of all overflow areas - which part is visible and which is not.

As we got all coordinates for all elements, it's time for painting. For this operation, we use coordinates from the previous step and color from style rules and combine them into a list of painting instructions. It's important to paint elements in the right order so that they stack correctly when they overlap. You can modify order via z-index style rule.

Let's execute our list of painting instructions and convert them into a bitmap of color values. This stage is called raster. At this moment we also take our images and decode them into bitmap as well.

Later the rastered bitmap will be stored in GPU memory. This stage includes libraries that abstract the hardware and issuing calls to OpenGL and DirectX on Windows. When GPU receives the instructions to display bitmap, it draws pixels on your screen.

Now we have the most important parts of the rendering pipeline. But what would happen if you scroll the page, or some animation would be applied? In fact, rendering is not static. Change is represented via animation frames. Each frame is a complete rendering of the state of the content at a particular point in time. The real challenge in this process is its performance. Smooth animations require generation at least 60 frames per second. It would almost impossible to complete a full pipeline 60 times in a second especially on slow devices.

What if instead of always re-rendering everything, we provide a way to invalidate an element at a specific stage. E.g. if you change the color of the button dynamically, the browser will mark this node as invalidated and it would be re-rerendered on the next animation frame. If nothing is changed we can reuse the old frame.

That's a good way to optimize small dynamic changes in the content. Let's think about change in big regions of content. For example, if scroll the page, all pixels have to be different now. For that purpose a page is decomposed into layers that raster independently. A layer can be fairly small and represent only one DOM node. Those layers then will be combined together on another thread called the compositor thread. With this optimization you don't need to re-raster everything, but rather do it for small layers and then correctly combine them together.

Now we have a little overview of what Blink does and how rendering pipeline looks like. Let's dive into the code.

Navigating Blink codebase

It seems like we are finally at the finish line. Let's open the Blink repository and look around.

We can quickly realize that even though we narrowed down a lot from our original question, it's still too big to manually find a specific line of code responsible for preventing focus.

Let's try to search by our event name in Google:

mousedown site:https://chromium.googlesource.com/chromium/blink/+/master/Source

It leads us to the EventHandler file where you can find implementation details for a lot of input events. Including the most important line for us:

bool swallowEvent = !dispatchMouseEvent(EventTypeNames::mousedown, mev.innerNode(), m_clickCount, mouseEvent);

dispatchMouseEvent return value means "continue default handling", so swallowEvent is true in case of preventDefault usage.

Just below there is a call for focus event which is triggered only if swallowEvent == false.

swallowEvent = swallowEvent || handleMouseFocus(MouseEventWithHitTestResults(mouseEvent, hitTestResult), sourceCapabilities);

Apart from focus handling, you can explore all default actions of the mouse down event including selection, drag-drop, and scrollbar cases. It also implements mouse release and double clicks events - everything is there.

Gecko and WebKit

At this point, we already spent some time discovering browsers source code and have a pretty good understanding of their structure, so why not check Firefox and Safari altogether. Firefox's browser engine called Gecko and Safari's - WebKit.

Gecko also has an overview page for developers, so you'd get an idea of the main concepts of it. Based on the experience with Chrome, you can find a neat 6000 lines of code EventStateManager file with events default actions and behavior. I've included a specific line in the link, so you won't have to go through it all.

WebKit is a browser engine from Apple used in Safari and other Apple products. Chrome's Blink was forked from WebKit, so they have a lot of things in common and it wasn't a problem to find events implementation in their version of EventHandler file.

Now since we made sure we can prevent mousedown event safely, I can step back and finish the PR with the date picker.

Conclusion

Together we went a journey from a simple problem to the introduction of Web Standards and browser implementation details.

Don't be scared by the hidden complexity of existing modules even if it's a browser or compiler. It will be a fun journey in the end. The chances are you can easily find things to improve, and more importantly, get unique insights into how things actually work. I've learned a ton of stuff during this deep dive and encourage everyone to do the same. Browsers will provide excellent documentation along the way at the point that I'm not sure why I need anything else.

Relevant links for further reading

Do you know what DOM is? How it's represented internally? What's the purpose of events? I'd highly recommend DOM Standard to everyone from beginners to more experienced developers. "An event signifies an occurrence, not an action." - my favorite part of it.
Official website of the W3C community.
Getting around Chromium codebase.
Design documents published by Chromium developers.
Life of a pixel - introduction into rendering pipeline of Chrome.

How to Build a Dev.to API Client Library in JS

Ilya Lyamkin — Mon, 27 Apr 2020 18:41:12 +0000

Every time I find myself connecting to a third-party API that doesn't have a client library I have to create a lot of boilerplate around it:

Manually getting and passing authentication credentials to the data fetching layer. What if you want to persist API keys or perform the OAuth process?
Defining data models and normalization. You would need to make sure that the data you receive from API is saved in a structured way.
Create a controller for API that keeps all the methods in one place, so you can easily modify and find all usages of the API across your codebase.
Keeping up with updates. The APIs tend to change a lot: new methods come, old ones deprecate.

It was one of these days where I decided to connect to Dev.to API to automatically collect stats for my published articles. There wasn't any API client ready for use, so I ended up creating all of the wrapping logic around it. So if it's already there then why not share it with others together with my learnings, right? We'll go through five steps and come out with a clear plan on how to implement your own client.

Step 1. Language and target platform

Before jumping into the coding part, let's discuss which language we're going to use. Remember my point about defining data models? For API client it's essential to give a user more information about data that is going be returned, so we don't have to constantly switch context between documentation and IDE. It also helps to avoid bugs and typos as you write code (we all have tests in the end, haven't we?). Keeping all that in mind, the best choice at the moment is to use Typescript.

Now let's think where our library is going to be run. Basically, it could a browser or a Node.js server. Why not develop a library that works in both? It'll also make it easier to use it together with server-side rendering where code executed at the server first and then on the client.

Step 2. Bundling

Two major differentiators for any library is its size and support of users with old and modern clients. First, we want our size to be as small as possible - API client shouldn't add much weight to the project. Second, the library should have decent browser support by serving the CommonJS bundle for those who cannot support the modern version and at the same time give a modern bundle for clients with newer versions.

The default choice for a web project is Webpack, but our library is fairly small and simple, so I've chosen Rollup as base bundler together with microbundle for easy setup.

npm i -D microbundle

Now update the package.js with build tasks and a path to entry point:

{
  "source": "src/foo.js",          // Your source file (same as 1st arg to microbundle)
  "main": "dist/foo.js",           // output path for CommonJS/Node
  "module": "dist/foo.module.js",  // output path for JS Modules
  "unpkg": "dist/foo.umd.js",      // optional, for unpkg.com
  "scripts": {
    "build": "microbundle",        // uses "source" and "main" as input and output paths by default
    "dev": "microbundle watch"
  }
}

Step 3. Structure of the library

As we indent to support a lot of API endpoints we want our code to scale well if API expands. One of the best ways to do that is to align folders with resource names. For Dev.to API it would look like this:

/src
    /articles
        index.ts // Everything that's related to articles
        ...
    /comments
        index.ts
        ...
    /users
        ...
    index.ts // Imports and joins all resources together

It also useful to keep resources as separate classes, so you don't need to change root index.ts every time you add a new method. Then you'd need to merge them together using Typescript Mixins.

function applyMixins(derivedCtor: any, baseCtors: any[]) {
    baseCtors.forEach(baseCtor => {
      Object.getOwnPropertyNames(baseCtor.prototype).forEach(name => {
        Object.defineProperty(
          derivedCtor.prototype,
          name,
          Object.getOwnPropertyDescriptor(baseCtor.prototype, name)
        );
      });
    });
}
class DevTo extends Base {}
interface DevTo extends Articles, Comments, Users {}
applyMixins(DevTo, [Articles, Comments, Users])
export default DevTo

Step 4. Fetching library

We wanted to make a library that works both in the browser and in Node.js. How we would make our requests universal as well? fetch is available in the browser but missing in Node.js where you should use the http module.
isomorphic-unfetch will help us use fetch function everywhere and switch between browser and Node.js versions automatically.

Now let's have a look at the request function which wraps fetch and append authentication header:

request<T> (endpoint: string, options?: RequestInit): Promise<T> {
    const url = this.basePath + endpoint
    const headers = {
        'api-key': this.apiKey,
        'Content-type': 'application/json'
    }
    const config = {
        ...options,
        headers,
    }
    return fetch(url, config).then(r => {
        if (r.ok) {
            return r.json()
        }
        throw new Error(r.statusText)
    })
}

We always return Promise, so clients can chain requests together or wait for the results.

Step 5. Testing

Most of the code in API client is integration with third-party endpoints. To make testing easier we can utilize the Nock library that conveniently mocks HTTP server for us.

describe('Article resource', () => {
    test('getArticles returns a list of articles', async () => {
        // Set up the mock request
        const scope = nock('https://dev.to/api/')
           .get('/articles')
           .reply(200, [{ title: 'Article' }])

        // Make the request
        const DevToClient = new DevTo({ apiKey: 'XYZ' })
        await DevToClient.getArticles()

        // Assert that the expected request was made.
        scope.done()
    })
})

In the example above we set up the mock, then make the request and finally checking that mock has been executed.

Conclusion

Together we designed an API client that is small, scalable, supports Typescript out-of-the-box, and works in browser and in Node.js.

I invite everyone to check out the repository to collaborate and improve the library. If you ever wanted to be a maintainer of an open-source library, this is something I'd be open to help.

Why Hackathons Make You a Better Developer

Ilya Lyamkin — Sat, 30 Nov 2019 18:04:47 +0000

Over the course of my life, I’ve participated in more than 20 hackathons, so I might be a little biased on them, but on the other hand, I know a lot about how they can be useful.

Let me start by explaining what a hackathon means to me. In general, it’s an event of short duration (usually one or two days) where people come together to creatively solve problems. Hackathons can be themed, where the projects are confined to a particular problem such as food sustainability or returning citizens.

Reasons to Participate in Hackathons

Now that we have covered the definition, we can start with the reasons why you’ll become a better developer by participating in hackathons.

Extreme programming

It’s very easy to forget about speed while working with Scrum processes, so let’s bring the former back. With short deadlines and ambitious ideas, hackathons teach you how to code fast and, more importantly, think fast.

If you’re wondering why it’s that important, the reason is that you’ll know your limits much better and will be able to push them even further after the hackathon. You’ll not only be surprised by how much you have achieved but also understand your areas of growth.

Learning how to estimate your efforts better

Due to the limited time, proper estimation is essential for your success. If your estimation is incorrect, you won’t be able to achieve what you planned in time.

The truth is, at a hackathon, you’ll notice that your estimations are far from perfect. Use this fact to your advantage and adjust your estimations so that it doesn’t happen at work.

Creative thinking

Hackathons teach you how to solve a known problem creatively. In the first stage, ideation, you have to come up with a unique and fresh idea. If you think that’s all, actually, this is just the beginning. Now it’s time for execution, and you have to be creative at every step of the way because you’ll never have enough time or well-defined processes. Something will always break most unexpectedly, and you’ll need to find a viable solution to be able to ship the product in time.

Learning new technology

Hackathons are perfect places to learn something new. If you use React.js at work, try Svelte. Writing back-end with Java? Learn Kotlin! Or completely switch your stack from front end to back end, and the other way around. Maybe you want to get into VR. This is your chance.

Networking

Hackathon is an excellent chance to talk to fellow developers and like-minded people. You can get a big picture of what they’re working on and which tools they’re currently using. Think of it as a conference where you also have to code.

Iteration-based approach

At hackathons, you should focus on building a minimum viable product, which means you should be able to drop parts that are not required and then iterate over it. That’d allow you to ship a product where you can show something to people even if you can’t finish this cool new feature in time.

Learning how to split tasks in the best way

If your team consists of four or five people, you have to make sure your team works as one organism and utilizes the abilities of each team member. Be ready to communicate with your team actively and split the product into several independent pieces. Without proper separation of concerns, four people would work as two with clearly divided tasks.

Shifting focus to bring business value

In our work, you can easily forget why you’re writing code and what value it brings to the end-user. On the other hand, at hackathons, you’re solving real-world challenges — and thinking about them in the first place. It shifts your vision from just code to a big picture of what you’re trying to archive.

Workshops

It’s popular to have workshops that you can attend at the time of the event. They could be about new technology or about soft skills like improving your resume. They can be highly beneficial if you have just started your career or want to learn something new.

Getting feedback

Hackathons are one of the best places for validating your ideas. In your normal life, it’s hard to find someone who will be both honest and willing to spend time reviewing your ideas. Other options include using your personal network or paying for ads. At hackathons, you get all of that for free, and from people like you.

Giving feedback

I know a lot of people who find joy in helping and teaching others. By doing so, you can learn what others are doing and, if you have expertise in that area, help them. The best way to grow your network is to be helpful, so actively seek out these opportunities.

Having fun

Ultimately, this is what hackathons are all about. Don’t worry if you’re not going to be able to present a perfect product, just have fun. If your hackathon takes place in a different city or country, take advantage. Get to know the local culture and engage in unique experiences.

How To Get Started

If you decide to give hackathons a chance, there are several resources to check out.
The first is Major League Hacking (MLH). It’s the official student hackathon league that runs over 200 weekend-long invention competitions.
Second, make sure to go over Junction Hackathon and TechCrunch Disrupt Hackathon. They’re one of the biggest independent hackathons in the world.
Last but not least, check Meetup to find local hackathons in your city.

Conclusion

I hope I convinced you to take a look at hackathons. It would definitely not be easy to code for two days non-stop, but the results will pay off. You’ll learn a lot about yourself and your limits, find out how to estimate and split tasks, and understand how to apply your skills to solve real-world challenges. And don’t forget to have fun.

You Might Not Need Controlled Components

Ilya Lyamkin — Wed, 27 Nov 2019 20:31:57 +0000

If you'll go to the official React website it says that the recommended way to use inputs is to control them via React state. It also mentions that in some cases you can go with an uncontrolled option but do not say what are these cases explicitly. Let’s try to dive into it and see the pros and cons of this approach.

It’s all about control

Controlled input values are being kept in the local state. Every time the user changes the content of the input, the onChange function updates the React state, Component rerenders with the new value passed to Input.

Let browser do its job

On the other hand, uncontrolled inputs are being handled by the browser itself. So you don’t have direct control over inputs value in the component, but you can use ref to get access to it.

Looking at these two examples you can clearly say that the second one looks cleaner and less verbose than the first one. You don’t need to instantiate state, pass the value to each input and override onChange handlers.

An uncontrolled form doesn’t have state, so every time you type, your component doesn’t re-render, increasing overall performance.

By leveraging uncontrolled inputs you’re trusting browser with form management and become closer to the native implementation. Why do you need to write something that was already created anyway? 🤔

But what if I need to handle complex form, perform validation or handle custom submit logic?

Use refs. With new Hooks API, refs became a more stable and better way to control DOM. Consider the following example where you need to access forms values outside of the onSubmit function.

Embrace HTML5

Browser API provides you with a lot of useful features to handle forms and inputs.

form.reset() — use the reset function to clear all your fields
form.submit() — use it to programmatically submit the form
form.reportValidity() — checks validation constraints and returns true or false
document.forms — interface that allows you to access all forms on the page.
Constraint Validation API — set of properties and methods that allows you to create complex validations on the fields. min, max, pattern, email, required — all of that and much more is covered by it.

What about libraries that I can use with uncontrolled inputs?

Sure! React-Hook-Form allows you to build a form and perform validation on it without the hassle. Unform helps you build complex forms with nested fields, validation using uncontrolled components.

When it makes sense to use controlled inputs then?

Basically you need to choose controlled inputs when you need to re-render your component on every type. For example, you want to display or send all form values as you type (imagine autocomplete field for the search bar). Or if you need to pass input value to child component through props. There are quite a few cases where you have to use it.

Conclusion

I believe that uncontrolled components are currently undervalued and should have more presence in modern React applications. Indeed they’re not gonna solve all your problems but would help increase the performance and reliability of your components in many cases.

Adventuring Into React Hooks Performance Practices

Ilya Lyamkin — Thu, 07 Nov 2019 19:41:06 +0000

From version 16.8.0, React introduced us to a way to use state and other React features without writing a class — React Hooks.

It’s an amazing improvement around the classic Class paradigm which allows us to reuse stateful logic between components. No surprise that it comes with a learning curve that could lead to performance pitfalls.

Let’s deep dive into the most popular ones and try to figure out how to avoid them.

Re-Renders Matter

Alright, we identified that we may encounter some performance issues while using Hooks, but where are they coming from?

Essentially, most of the issues with Hooks come from unnecessary renders of your components. Have a look at the following example:

This is a component that has two states, A and B, and four increment actions on them. I’ve added the console.log method to see the message on every render. The first two actions are basic increments and just increase A or B values by one.

Let’s click on the a++, b++ button and have a look at the console: on each click, there should be only one render. This is really good because that’s what we wanted.

Now press the a++, b++ after 1s button: on each click, you’d see two renders. If you’re wondering what’s happening underneath — the answer is simple.
React batches synchronous state updates into one.

On the other hand, for asynchronous functions, each setState function triggers a render method.

But what if you want to have consistent behavior? Here comes the first rule of Hooks.

Rule 1: Do Not Split State Between Several useState Methods for Connected Data Models

Imagine you have two independent states. Then, the requirements changed, thus update of one state causes an update of another one.
In this case, you have to join them in one object: const { A, B } = useState({ A: 0, B: 0}). Or, take advantage of the useReducer function.

Another good example of this rule is data loading. Usually, you need three variables to handle it: isLoading, data, and error. Don’t try to keep them separate, prefer useReducer instead.

It allows you to separate state logic from components and helps you to avoid bugs. Having one object with these three properties will be a solution as well but would not be that explicit and error-prone.

Trust me on that, I have seen so many people forgetting to set isLoading: false on error.

Custom Hooks

Now that we’ve figured out how to manage useState in a single component, let’s move increment functionality outside to be used in different places.

We refactored the increment logic to its own Hook and then we run it once using the useEffect function.

Note that we have to provide the incrementA setter in the dependency array because we’re using it inside and it’s enforced by Hook’s ESLint rules. (Please enable them if you didn’t do that before!).

If you try to render this component, your page will be frozen because of infinite re-renders. To fix it, we need to define the second rule of Hooks.

Rule 2. Make Sure You Return New Objects From Custom Hooks Only If They’ve Changed

The component above is always re-rendering because the increment Hook returns a new function every time. To avoid creating a new function every time, wrap it in the useCallback function.

Now it’s safe to use this Hook.

Sometimes, you need to return a plain object from custom Hooks, make sure you update it only when its content changes using useMemo.

How to Find These Re-Renders Before It’s Too Late?

Normally, it’s troublesome to find these issues before it causes performance issues, so you have to use specific tools to detect them beforehand.

One of them is the why-did-you-render library that tells you about avoidable re-renders. Mark your component as MyComponent.whyDidYouRender = true, start interacting with it, and look for messages in the console.

I guarantee that you’ll discover something new in the next five minutes.

Another option is to use the Profiler tab in React Dev Tools extension. Although you have to think about how many re-renders you expect from your component— this tab only shows the number of re-renders.

Let me know what other challenges you’ve encountered with Hooks, let’s solve them together.

References and Further Resources

Implementing the Prefetch Pattern in React Concurrent Mode

Ilya Lyamkin — Tue, 05 Nov 2019 23:04:56 +0000

Recently, React announced a feature of the React ecosystem — Concurrent Mode. This would allow us to stop or delay the execution of components for the time that we need. It’ll help React apps stay responsive and gracefully adjust to the user’s device capabilities and network speed.

Concurrent Mode consists of a set of new features — one of the biggest ones is suspense and a new approach to data fetching.

Basically, there are three ways to do it:

Fetch-on-render: We start rendering components and each of these components may trigger data fetching in their effects and lifecycle methods. A good example of that is fetch in useEffect.
Fetch-then-render: Start fetching all the data for the next screen as early as possible. When the data is ready, render the new screen. We can’t do anything until the data arrives. The example of that is having a Container component that handles data fetching and conditionally renders the child presentational component once we’ve received everything.
Render-as-you-fetch: Start fetching all the required data for the next screen as early as possible, and start rendering the new screen immediately, even before we get a network response. As data streams in, React retries rendering components that still need data until they’re all ready.

I believe that the concepts of the first two approaches are well known and definitely presented in your code. Let’s dive straight into the render-as-you-fetch approach.

Render-As-You-Fetch

You’ve probably noticed that the explanation of this approach has two parts:

Start loading data as early as possible.
Start trying to render components that may still need data.

Fetch early

Let’s build an app together that loads major stock indexes. For that, we have a simple “Load” button. Once you click on it, we start loading data immediately:

prefetchQuery is a function that performs the fetch request and returns an object that we’re going to pass to the <IndexList /> component. The key takeaway from this example is that we’re triggering fetch from the onClick event and not in the render phase.

Render early with Suspense

The second part of the example above is that we’re saving the object from prefetchQuery to the state and starting to render <IndexList /> immediately as well.

On the other hand, we also don’t want to render the list with empty data, so ideally, we’d like to be able to suspend render until we have all the data without writing if (isLoading) return null. Luckily, we have the Suspense component for exactly that purpose.

Suspense is a mechanism for data-fetching libraries to communicate to React that the data a component is reading is not ready yet. React can then wait for it to be ready and update the UI.

Let me show you an example:

To take advantage of Suspense, you just need to wrap your component with it. It accepts a fallback prop: the element that you want to show while waiting for data.

How To Fetch Data in Sync With Suspense?

Now that you know about Suspense and prefetch practices, you wonder how this all works together. So, here is the last piece of this puzzle. To solve it, let’s finally check out the prefetchQuery function.

Don’t be scared by the complexity of it, it’s actually fairly simple.
First, we take a URL and pass it to the native fetch function, receive a promise, and pass it to the wrapPromise function. This function returns an object with the read() method:

If a promise is still pending, we throw this promise.
If a promise is resolved with error, we throw the error.
If a promise is resolved, just return the data.

In fact, the only difference we have, compared to traditional fetching practices, is throwing a pending promise.

When you have usePrefetchedQuery in IndexList, it just executes the read() method. If data is not there yet, it throws a promise before actually rendering anything and Suspense will catch that.

How To Experiment With This?

The React team introduced an experimental releases branch with a modern API.
For that, you need to run npm i react@experimental react-dom@experimental and play with it locally. I also created a live example on CodeSandbox for you that shows everything I did together in one working project.

Can I Use It in My Production Projects?

No. Concurrent mode is still under development and some implementation details could change. Use experimental versions to get familiar with new concepts and maybe propose your own ideas. For example, how to integrate prefetch practices in routers or provide a good way to cache data.

Further Resources

An experimental version of Relay with Suspense.
Soon, you’ll be able to connect preload functionality to routers. Have a look at https://github.com/ReactTraining/react-router/pull/7010 or Navi router.
Introduction to Concurrent mode.
Introduction to Suspense for data fetching.
Live sandbox with examples.