
## The problem

The more complex our applications become the more work browser have to do. And due to single threaded nature of javascript it is becoming harder to make our apps responsive (to respond to user interactions immediately).

Let's develop some simple app to clearly understand what I am talking about. An app I would like to create will generate huge array of random numbers and sort it.

Let's start with core feature - sort function. Yep, we are not going use

_Array.prototype.sort_, cause it will be impossible to improve it later. The simplest algorithm I know is [bubble sort](https://en.wikipedia.org/wiki/Bubble_sort):

```js
let sortPass = array => {
  let needOneMorePass = false

  for (let i = 0; i < array.length - 1; i++) {
    if (array[i] > array[i + 1]) {
      let temp = array[i]
      array[i] = array[i + 1]
      array[i + 1] = temp

      needOneMorePass = true
    }
  }

  return needOneMorePass
}

let bubbleSortSync = array => {
  // do not mutate original array
  let clone = array.slice()

  while (sortPass(clone)) {}

  return clone
}
```

I've splitted algorithm into 2 functions to show how it is easy breakable into units of work - passes.

Now let's add some simple ui: button to trigger core functional of our app (sorting). To track ui responsiveness during algorithm execution we will add css animation and text input. Also we will try to display several array elements before and after sorting:

[stop the world - bubble sort](embedded-codesandbox://the-simplest-example-of-scheduling-on-the-main-thread/stop-the-world)

Have you seen that? Button click "stops the world": green block is not rotating anymore, input cannot be edited. And the reason for that is that browser processes everything in a single thread: it wasn't able to update layout and respond to user while we were sorting.

![Stop the world](/uploads/stop-the-world.jpg 'Stop the world')

To improve our app we should not block main thread for more than 16ms (for 60 frames per second). Thus, we should be able to suspend the execution of the sort function and resume it after the browser has completed its work.

## Schedule on the main thread!

Luckily our algorithm can be suspended/resumed easily and browser has [nice API](https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback) to determine best time to execute low priority (not connected to user interactions and animations) code - \_requestIdleCallback. \_Here is how we can use it:

```js
// we won't be able to return sorted array synchronously anymore
// so let's use promises
let bubbleSortAsync = array =>
  new Promise(resolve => {
    // immutability espeсially importaint in async code
    let clone = array.slice()

    requestIdleCallback(function step(deadline) {
      let needOneMorePass = false

      do {
        needOneMorePass = sortPass(clone)
      } while (needOneMorePass && deadline.timeRemaining())

      if (needOneMorePass) {
        // resume sorting later
        requestIdleCallback(step)
      } else {
        resolve(clone)
      }
    })
  })
```

Experience became so smooth that I decided to rerender array elements on every callback (to show the progress).
And here is a demo:

[Imagine next app](embedded-codesandbox://the-simplest-example-of-scheduling-on-the-main-thread/scheduling)

Here is how it looks in profiler:

![Smooth sort profile](/uploads/smooth-sort-profile.jpg 'Smooth sort profile')

Looks cool, right? Though sorting takes a bit more time to finish, user doesn't feel that it is slow. That is exactly what we were looking for.

### We are not alone in scheduling war

Pretty same ideas are used in newer version of [react reconciliation](https://reactjs.org/docs/reconciliation.html) algorithm - Fiber. But in our case we didn't take into account a lot of things:

- it was easy to split work of bubble sort into chunks (what about other algorithms?)
- we did not care about cancelation what if user pressed sort button again?
  can we drop a job we've done and start new one?
- in real apps there would be probably more kind of jobs
  so what about prioritising?
- ...

And we do not have to! React team has already solved all this complex things and we haven't even noticed that - there was no API changes when fiber was introduced.

Also one day browsers might introduce [more convenient API](https://github.com/developit/task-worklet) for scheduling.

### Useful links

- [A Quest to Guarantee Responsiveness: Scheduling On and Off the Main Thread (Chrome Dev Summit 2018)](https://www.youtube.com/watch?v=mDdgfyRB5kg)
- [Lin Clark - A Cartoon Intro to Fiber - React Conf 2017](https://www.youtube.com/watch?v=ZCuYPiUIONs)
- [The how and why on React’s usage of linked list in Fiber to walk the component’s tree](https://medium.com/react-in-depth/the-how-and-why-on-reacts-usage-of-linked-list-in-fiber-67f1014d0eb7)
- [React as a UI Runtime](https://overreacted.io/react-as-a-ui-runtime/)


The simplest example of scheduling on the main thread


Just after I've released [1.8](https://www.nikitakirsanov.com/changelog/) version of site and published post [Implementing medium like tooltip](https://www.nikitakirsanov.com/blog/implementing-medium-like-tooltip/), I had understood its page loads 6 mb! And it is absolutely inappropriate for my blazing fast site. The most significant change of this release was integration with [codesandbox](https://codesandbox.io): all embedded links to it are transformed to iframes. Results I've got in _network_ tab of chrome dev tools also had met my expectations: most of resources were loaded by iframes.

Obvious solution is to load iframes lazily - when they appear in the viewport. So here is a code I came up with:

First of all rename src attribute of iframe to something else (e.g. data-src), so it won't load anything during initial render.

```html{2}
<iframe data-src="https://nikitakirsanov.com"> </iframe>
```

And insert src when iframe intersects with viewport:

```js
// react hooks fits perfect for extracting
// such type (not only) of reusable logic
let useLazyIframe = () =>
  // we need to register our observer after our component mounted
  useEffect(
    () => {
      let observer = new IntersectionObserver(
        entries => {
          entries
            // filter only visible iframes
            .filter(e => e.isIntersecting)
            .forEach(({ target: $el }) => {
              // iframe will start loading now
              $el.setAttribute('src', $el.getAttribute('data-src'))
              // no need to observe it anymore
              observer.unobserve($el)
            })
        },
        {
          // we'll load iframe a bit beforehand
          rootMargin: '10%',
        }
      )

      document
        .querySelectorAll('iframe[data-src]')
        .forEach($el => observer.observe($el))

      // do not forget to clean up on component unmount
      return () => observer.disconnect()
    },
    [
      /* we need to register observer once */
    ]
  )
```

That's it!

**Read more:**

[Intersection Observer API](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API)

[IntersectionObserver’s Coming into View](https://developers.google.com/web/updates/2016/04/intersectionobserver)

[React hooks overview](https://reactjs.org/docs/hooks-overview.html)


Load everything lazily with IntersectionObserver


It might (and should) look like quite a trivial thing to implement. But still there are some pitfalls, so I want to tell how to avoid them, what libraries and patterns can help. And again to strengthen my English 😁

## Positioning is not easy

Here is a list of problems commonly faced when dealing with popups:

- how to position element relative to some other one
- how to position element over everything else aka _z-index: 999;_
- take into account viewport borders
- handle scrolling

Fortunately we live in open source era, so there is plenty of ready solutions. E.g. [react-popper](https://github.com/FezVrasta/react-popper) - library that takes care about all positioning issues. I've already used it in my previous projects and was satisfied. So I'll use it here as well.

Let's try to create simple popup using it:

[popper-example](embedded-codesandbox://implementing-medium-like-tooltip/popper)

By the way, its api should be more neat [with hooks](https://github.com/FezVrasta/react-popper/issues/241).

As you can see, _react-popper_ solved all problems I've mentioned above:

- calculated position of popup relative to input
- positioned it using _translate3d _(you can also use position fixed or even [portals](https://reactjs.org/docs/portals.html) in case you are using overflow...)
- took into account viewport and handles scrolling

## Let's make it bit more complex

To tell the truth, it is not the end of our positioning journey: the tooltip should appear next to the selected text, not its DOM node (cause it might be huge paragraph).

Any ideas how we can accomplish that? A couple of questions to google and boom - browser has a [selection api](https://developer.mozilla.org/en-US/docs/Web/API/Selection). With its help we can get access to parts of text nodes - [Ranges](https://developer.mozilla.org/en-US/docs/Web/API/Range).

Let's look at how we can apply this api:

```jsx
let handleMouseUp = () => {
  let selection = window.getSelection()

  // we do not need "empty" selection
  if (!selection.isCollapsed) {
    let range = selection.getRangeAt(0)

    // now we know where to render tooltip
    range.getBoundingClientRect()
  }
}
```

Here is a demo:

[selection-api](embedded-codesandbox://implementing-medium-like-tooltip/selection-api)

Well looks cool, but how can we attach that to _react-popper_? It expects to get a ref to DOM node...

Its documentation has an answer - [we should create "virtual" DOM node](https://github.com/FezVrasta/react-popper#usage-without-a-reference-htmlelement):

```js
// we are implementing methods required for react-popper
class VirtualSelectionReference {
  constructor(selection) {
    this.selection = selection
  }

  getBoundingClientRect() {
    return this.selection.getRangeAt(0).getBoundingClientRect()
  }

  get clientWidth() {
    return this.getBoundingClientRect().width
  }

  get clientHeight() {
    return this.getBoundingClientRect().height
  }
}
```

It's time to bring everything together:

```jsx
let SelectionReference = ({ onSelect, children }) => (
  <Reference>
    {({ ref }) =>
      // 1. more handy api
      children(function getProps({ onMouseUp, ...rest } = {}) ({
        ...rest,
        onMouseUp: (...args) => {
          let selection = window.getSelection()

          if (!selection.isCollapsed) {
            // 2. feed it to react-popper
            ref(new VirtualSelectionReference(selection))
            // 3. handy method
            onSelect && onSelect(selection, ...args)
          }

          // 1. user of our component might want to use this event too
          onMouseUp && onMouseUp(...args)
        },
      }))
    }
  </Reference>
)
```

Let's review the solution step by step:

1. We've created special _SelectionReference_ component by wrapping original one.
   It has same signature with one exception: children function (aka [render prop](https://cdb.reacttraining.com/use-a-render-prop-50de598f11ce)) will receive function instead of object - it is known as [get props pattern](https://blog.kentcdodds.com/how-to-give-rendering-control-to-users-with-prop-getters-549eaef76acf). The main benefit of it here is that our component taking care of merging its own props (_onMouseUp_ handler) with props we might want to provide when outside.
2. We've fed our "fake" DOM node to original _Reference \_component_.\_
3. We've created handy _onSelect_ event, which we'll use later.

That's it! now we can use our component to position tooltip:

[medium-like-tooptip_popper+selection-api](embedded-codesandbox://implementing-medium-like-tooltip/all-together)

## Cherry on top

This guide would be incomplete if we won't animate appearance of tooltip. And again I will use proven solution - [react-spring](https://github.com/react-spring/react-spring).

All we need is to wrap our tooltip into _Transition_ (it animates component lifecycles). So we'll get composition of 2 _render prop_ components:

```jsx
// our component should be totally reusable so
// 1. we manage its state (isOpen) outside
// 2. we receive content (children) from outside as well
let Tooltip = ({ isOpen, children }) => (
  <Popper>
    {/* Popper provides styles for positioning */}
    {({ ref, style }) => (
      <Transition
        items={isOpen}
        from={{ transform: `translateY(30px) scale(0.9)`, opacity: 0 }}
        enter={{ transform: `translateY(0) scale(1)`, opacity: 1 }}
        leave={{ transform: `translateY(30px) scale(0.9)`, opacity: 0 }}
      >
        {/* we should use flag provided by Transition to make animation work */}
        {transitionIsOpen =>
          transitionIsOpen &&
          (transitionStyle => (
            // and here is styles provided by react-spring to animate appearance
            <div ref={ref} style={style}>
              <SomeStyledTooltip style={transitionStyle}>
                {children}
              </SomeStyledTooltip>
            </div>
          ))
        }
      </Transition>
    )}
  </Popper>
)
```

It is a bit simplified code, full version of it you can find [here](https://github.com/kitos/kitos.github.io/blob/develop/src/components/tooltip/tooltip.js). And, by the way, you can see the demo by selecting any text in this (any any other) blog post 😏.

That is all I wanted to share for now. I hope you found this article useful.


Blog #web-api

The simplest example of scheduling on the main thread

Load everything lazily with IntersectionObserver

Implementing medium like tooltip