
In this post I would like to share my recent experience of working with DataLoader, with a step-by-step example.

I actually have been thinking about writing an article about DataLoader for few years, since I first tried it. I even had [a talk](https://youtu.be/Iy1DUcBjXcQ) (in russian) about it once.
And finally I have some really simple and yet meaningful example of its usage outside of GraphQL ecosystem.

## Problem space

An app I have recently been working on was a _contentful_ extension which gathered some metrics about content usage/completeness.
One particular feature was to find links to the pages from other ones. E.g. we wanted to know how many offer pages are associated with a city page.

To give you an idea, _contentful_ has a very powerful mechanism to build site hierarchy (not only) - reference fields. Where one entry can have link/s to others.
With a help of it we've been able to create structure like this:

TODO

On which we heavily rely to automate a lot of content sections throughout our website: main navigation, breadcrumbs, thumbnails with parent/child/sibling pages and basically the whole gatsby (yep, we use SSG) build process relies on it.

## Limitation of existing API

And obviously we'd like to use this info to gather our metrics, moreover _contentful_ provides a way to do so - [links_to_entry](https://www.contentful.com/developers/docs/references/content-delivery-api/#/reference/search-parameters/links-to-entry) query param.
It returns a list of entries which refer to the one you are interested in. E.g. using js sdk:

```js
let { items: entries } = await space.getEntries({
  links_to_entry: 'id-of-our-city',
})
```

But there are few issues with this approach:

- it works for 1 entry, we can't get links to multiple cities;
- _contentful_ docs suggest: "it is more performant to query based on a content type's reference field";

And in my case, I really need to work with hundreds of pages, so both of them sound rather concerning.
Here is an example:

```js
let cityIds = [1, 2, 3, ...hundredMore]

// make 103 parallel heavy requests
// at least contentful sdk handles rate limit responses for us (retries requests)
let citiesWithLinks = await Promise.all(
  cityIds.map((id) => space.getEntries({ links_to_entry: id }))
)
```

Luckily _contentful_ provides an alternative:

```js
space.getEntries({
  // now we need to know
  content_type: 'offer', // referencing content type
  'fields.city.sys.id': 42, // and field
})
```

It also allows using operators, so we actually can make a single request for all cities at once:

```js
let offersReferencingToAllCities = space.getEntries({
  content_type: 'offer',
  'fields.city.sys.id[in]': cityIds,
})
```

Now we have to group this flat array of offers by the city they belong to:

```js
// lodash have a handy method for that
let offersByCityId = _.groupBy(
  offersReferencingToAllCities,
  (offer) => offer.fields.city.sys.id
)
```

Finally, we can get same result we had in the beginning with fewer (just 1 in our case) api calls. Here is full example:

```js
let cityIds = [1, 2, 3, ...hundredMore]

let offersReferencingToAllCities = space.getEntries({
  content_type: 'offer',
  'fields.city.sys.id[in]': cityIds,
})

let offersByCityId = _.groupBy(
  offersReferencingToAllCities,
  (offer) => offer.fields.city.sys.id
)

// ta-da!
cityIds.map((id) => offersByCityId[id] ?? [])
```

Well great, but it's it confusing that we achieved what we wanted to, but didn't use _DataLoader_ as I promised?

Right, there is a couple of issues with our final solution actually:

- it is obviously more complicated than the one we started with;
- contentful has a limit on number of returned entries, so it is very likely that we'd wanna batch in a smart way (and complicate solution even further);
- our abstractions not always allow us to operate on all entities, so that we can batch calls explicitly (e.g. graphql resolvers);

So wouldn't it be cool if we had an api similar to our initial solution, and performance of the last one? Easy! That's what we need _DataLoader_ for!

```js
/**
 * We'll have a data loader per content type and field,
 * cause that's what contentful allows us to batch
 */
let createLinksLoader = (contentType, field) =>
  // we should provide a batch loader
  // which gets an array of keys (in our case entry ids)
  // and returns array of resuls, respecting the original order
  new DataLoader(async (ids) => {
    // pretty much same code we had,
    // except now it is more generic/reusable
    let referencingEntries = await space.getEntries({
      content_type: contentType,
      [`fields.${field}.sys.id[in]`]: cityIds,
    })

    let groupedEntries = _.groupBy(
      referencingEntries,
      (offer) => offer.fields[field].sys.id
    )

    return ids.map((id) => groupedEntries[id] ?? [])
  })
```

And now we can use our loader:

```js
let cityIds = [1, 2, 3, ...hundredMore]

let offerToCityLinksLoader = createLinksLoader('offer', 'city')

let citiesWithLinks = await Promise.all(
  cityIds.map((id) => offerToCityLinksLoader.load(id))
)
```

Neat, isn't it? Now we have a performant, reusable links loader and even more:

- _DataLoader_ also deduplicate and cache calls;
- with a help of `maxBatchSize` option, we can prevent hitting the limit for number of returned entries I mentioned above;

Hope you enjoyed the article!


Power of DataLoader

In this article I will tell how to build "Related Reads" section for a [gatsby](https://www.gatsbyjs.org/) blog, like the one you can find at the bottom of this page.

As a prerequisite I expect, that you are already familiar with gatsby or even have an app with some source `[-plugin]`where you pull your articles from.

I use [netlify cms](https://www.netlifycms.org/) and store all my articles next to the source code [in git](https://github.com/kitos/kitos.github.io/tree/develop/src/_content/blog) as markdown files. So `gatsby-source-filesystem` and `gatsby-transformer-remark` plugins are responsible for making them available in graphql. E.g. here is how I can query all articles:

```graphql
query BlogPostList {
  allMarkdownRemark {
    nodes {
      frontmatter {
        title
      }
    }
  }
}
```

But enough about me, let's get back to business.

## Setup local plugin

First of all, I want to implement this feature as a local plugin (instead of root `gatsby-node.js`). I find this approach more idiomatic and clear. Creating one is a piece of cake and gatsby has [a decent documentation about it](https://www.gatsbyjs.org/docs/creating-a-local-plugin/), so check it out if you haven't yet.

As a result, we should have `/plugins/related-reads/gatsby-node.js` along with empty `package.json` and name (equal to name of the folder!) of our plugin listed in `gatsby-config.js`.

## Extend graphql

The next step would be extending graphql schema, generated by `gatsby-transformer-remark`. So along with a content of an article, we can also request a list of articles about similar topic[s]. Like this:

```graphql
query BlogPostList {
  allMarkdownRemark {
    nodes {
      frontmatter {
        title
      }

      // highlight-start
      relatedReads {
        slug
        title
      }
      // highlight-end
    }
  }
}
```

[A while ego](https://www.gatsbyjs.org/blog/2019-03-04-new-schema-customization/) gatsby team provided very nice way to achieve this - [schema customization API](https://www.gatsbyjs.org/docs/schema-customization). And we are going to leverage it, particularly `createResolvers`:

```js
exports.createResolvers = ({ createResolvers }) =>
  createResolvers({
    // node type we want to extend
    MarkdownRemark: {
      // name of the field we want to add
      relatedReads: {
        // we return an array of other articles
        type: '[MarkdownRemark!]',
        // let's allow to specify number of articles returned
        args: { limit: 'Int' },

        async resolve(
          source, // the node we extend
          args,
          // collection of helpers
          // including access to internal store - nodeModel
          ctx

        ) {
          return []
        },
      },
    },
  })
```

No we can implement the last bit - the logic of _Relative Reads_. In my blog each post have a list of tags, so I gonna use it to measure similarity.

```js
const intersection = require('lodash.intersection')

// I've extracted the resolve function just to get rid of extra noise
let resolve = async (source, args, ctx) {
  let { frontmatter: { slug, lang, tags } } = source
  let { limit = Number.MAX_SAFE_INTEGER } = args

  // request all other posts
  let otherPosts = await ctx.nodeModel.runQuery({
    firstOnly: false, // we want to get an array
    type: 'MarkdownRemark',
    query: {
      filter: {
        frontmatter: {
          slug: { ne: slug }, // not current article or translation
          lang: { eq: lang }, // same lang
        },
      },
    },
  })

  return otherPosts
    .map((p) => ({
      ...p,
      // measure the similarity by the size of tags intersection
      similarity: intersection(p.frontmatter.tags, tags).length,
    }))
    .filter(({ similarity }) => similarity !== 0)
    .sort(
      (a, b) =>
        b.similarity - a.similarity ||
        b.frontmatter.date.localeCompare(a.frontmatter.date)
    )
    .slice(0, limit)
}
```

That is it! Pretty easy implementation and zero runtime cost - everything is requested ahead of time and build into your html pages, that is the strongest point if gatsby and JAMStack.

Did you like this post? Want to hear more stories about gatby? Please leave comment about things you'd like to know about.


Build "Related Reads" for your gatsby blog

It is hard to underestimate an importance  of [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree) transformation tools in the frontend now:

* we use `babel`

  * to transform the most recent *ECMAScript* versions to work with older versions of browsers
  * to [optimize our code](https://github.com/jamiebuilds/babel-react-optimize)
  * to get [new features](https://emotion.sh/docs/css-prop)
* we use `eslint` to enforce best practices or avoid mistakes/bugs
* we use `prettier` to format the code

But today I wanna tell a short story about using *AST* transformation to refactor the code. Like some codemods you might used.

## Backstory

At [tourlane](https://www.tourlane.de/) we use [styled-components](https://styled-components.com/) (probably, the most popular *CSS-IN-JS* solution in react) along with [styled-system](https://styled-system.com/) (awesome utility belt for writing responsive styles based on scales from global theme), so we can build components like this:

```jsx
let User = ({ avatar, name }) => (
  <Flex flexDirection={['column', 'row']}>
    <Box as="img" mb={[1, 0]} mr={[0, 1]} src={avatar} />
    <Box p={1}>{name}</Box>
  </Flex>
)
```

While some of you might find this style of writing components pretty controversial, this is not the point of this article. But I still can recommend a couple articles to [](https://jxnblk.com/blog/two-steps-forward/)get more reasoning behind it:

* [Two steps forward, one step back](https://jxnblk.com/blog/two-steps-forward/)
* [Styles and Naming](<* [https://www.christopherbiscardi.com/post/styles-and-naming](https://www.christopherbiscardi.com/post/styles-and-naming/)/>)
* [Old and new ideas in React UI](https://react-ui.dev/core-concepts/ideas)

The point of the code block from above is the usage of responsive CSS values: `jsx±flexDirection={['column', 'row']}`(pretty handy isn't it?). Under the hood it will use media breakpoints provided in the theme to compile the responsive styles like:

```css
.some-generated-class {
  flex-direction: column;
}

@media screen and (min-width: 64em) {
  .some-generated-class {
    flex-direction: row;
  }
}
```

## The problem

When we started one of our projects we didn't have any styles specific to tablets, let's say we had something similar to this:

```jsx
let breakpoints = [
  // no need to define lower breakpoint
  // since we use mobile-first
  // (styles applied without media are considered to be mobile)
  
  '64em', // desktop
  '80em', // wide
]

let Layout = ({ children }) => (
  <ThemeProvider theme={{ breakpoints }}>
    <Header />
    {children}
    <Footer />
  </ThemeProvider>
)
```

But lately we got a new page where the mobile and table designs are quite different. But our scale system doesn't support it 😧: we can not use responsive attributes that we are used to 😨. Adding one more breakpoint will break all existing components 😰.

I bet you've been in a situation like this. E.g. you might used some library api which was deprecated. Luckily in cases like this, library authors usually prepare codemods which will update your codebase for you. So you don't even have to understand what it does under the hood.

But in our case there was no one to rely on, nobody to blame... but... me? 🥺

## jscodeshift to the rescue

Even though we could write tablet specific styles *"by hand"* - using *normal* `styled-component`s syntax. It wasn't the way we wanted to proceed - we really like the api provided by `styled-system`, moreover we didn't want to introduce  ambiguity in writing responsive styles. And obviously we weren’t too keen to go through the whole codebase and change all usages of responsive props.

Sounds like a perfect task for codemode!

I have never worked with them, but I've heard that [jscodeshift](https://github.com/facebook/jscodeshift) is a cool tool to build them, e.g. react team [uses it.](https://github.com/reactjs/react-codemod) All you have to do is create `js/ts` file and export the *transform* function which will take care of required AST transformations.

Another important part is, of course, a general understanding of AST: what it is, what it consists of and how we can alter it. I found this [babel handbook](https://github.com/jamiebuilds/babel-handbook) to be super useful intro. Another must-have tool is [AST explorer](https://astexplorer.net/). With help of this tool you can write some code to see its AST representation and write transform functions with immediate results!

Also I can hardly imagine writhing AST transformation without `typescript` (you can get info about nodes and their properties, right during typing intead of switching between editor and bable docs all the time), so I installed its typings (`@types/jscodeshift`) along with a library itself.

And after about an hour of playing with it I built this:

```typescript
import { Transform } from 'jscodeshift';

let directions = ['', 't', 'r', 'b', 'l', 'x', 'y'];
// these are responsive attrs provided by styled-system
let spaceAttributes = [
  ...directions.map(d => `m${d}`),
  ...directions.map(d => `p${d}`),
  'flexDirection', 'justifyContent', // ...
];

let transform: Transform = (fileInfo, { j }) =>
  j(fileInfo.source)
    .find(j.JSXAttribute)
    .forEach(({ node }) => {
      let attributeName =
        typeof node.name.name === 'string' ? node.name.name : `¯\\_(ツ)_/¯`;
      let { value } = node;

      if (
        spaceAttributes.includes(attributeName) &&
        // we are interested only array expressions which has more then 1 value
        // like <Box m={[8, 16, 24]}>
        value?.type === 'JSXExpressionContainer' &&
        value.expression.type === 'ArrayExpression' &&
        value.expression.elements.length > 1
      ) {
        let [xs, ...otherMedias] = value.expression.elements;

        // null in styled-system means - do not introduce new media query,
        // so thanks to mobile first approach we'll have values defined in xs.
        // I could also write [xs, xs, ...otherMedias],
        // it will just result in bigger css output
        value.expression.elements = [xs, j.identifier('null'), ...otherMedias];
      }
    })
    .toSource();

export default transform;
```

You can also play with live example in [AST explorer](https://astexplorer.net/#/gist/d76e9a0c6e5f0cea12c039bc1b3f0d4c/4a5c9afcfda6967a4d0205ba8093e2b0c363ac4c).

As you can see the transform is not that big and yet very descriptive. Obviously it doesn't cover all possible cases, e.g. we could use ternary expressions in jsx attributes or use variables referring to arrays and etc. But it does explain the idea, at least I hope so.

The cool thing is you can run your codemode ➡️rollback using git ➡️improve 🔁1000 times, until you are happy with the result.

## Make codemods part of your toolbelt

That is all I wanted to share today. I hope after reading this article you will consider codemods to be not just powerful tool, but also a thing that is easy to learn, as I did. If you have any questions or suggestion feel free to use comments section or rich me directly in [twitter](https://twitter.com/kitos_kirsanov). Thanks!


Refactor like no one is watching


Well, looks like now, during self isolation caused by COVID-19 🦠, I'll have some time to code and maybe even to write a couple of articles about it (code). This one is the first, in it I'm gonna play with `react-spring` to create simple digital clock animation like this:

![Animated digital clock](/uploads/digital-clock.gif 'Animated digital clock')

## Small things matter

How did I come up with this idea? I was just bored, started to check my pet projects, settled on [my game of life](https://kitos.github.io/game-of-life/), considered its UI to be too uneventful and decided that it might be a good idea to add some emojis, cause everybody like them 😋!

Implementation of this small component doesn't sound like a rocket science, but I will do my best to touch some interesting topics here, and after all I enjoined the process. And it is actually funny to realise that after more than 6 years of coding, participating in pretty complex projects and trying different technologies I still can take pleasure in things even smaller than this clock. I hope everyone can find a field where they can do the same.

## First building blocks

Let's start with something really simple - build a component which can render a numeral using emojis like this: 4️⃣2️⃣:

```jsx
let emojiDigits = ['0️⃣', '1️⃣', '2️⃣', '3️⃣', '4️⃣', '5️⃣', '6️⃣', '7️⃣', '8️⃣', '9️⃣']

let EmojiNumber = ({ value }) => (
  <div>
    {value
      .toString()
      .split('')
      .map((n, i) => (
        <span key={i}>{emojiDigits[n]}</span>
      ))}
  </div>
)
```

Nothing special except maybe they _key_: most of the time we [use some _id_ as _key_](https://reactjs.org/docs/lists-and-keys.html#keys) and [trying to avoid using index](https://medium.com/@robinpokorny/index-as-a-key-is-an-anti-pattern-e0349aece318). But in our example index is the only thing that matters - the order of digits in numbers is important, isn't it?

Having this small component we can already render time:

```jsx
// expect value to be an instance of Date
let Time = ({ value }) => (
  <div style={{ display: 'flex' }}>
    <EmojiNumber value={value.getHours()} />
    :
    <EmojiNumber value={value.getMinutes()} />
    :
    <EmojiNumber value={value.getSeconds()} />
    :
    <EmojiNumber value={value.getMilliseconds()} />
  </div>
)
```

Easy, but the implementation has a bug 🐛, did you notice it?

For time `03:05:09` it will render 3️⃣: 5️⃣: 9️⃣, while I would expect to see 0️⃣3️⃣: 0️⃣5️⃣: 0️⃣9️⃣ . Let's fix it with `padTime` _function_:

```jsx
// highlight-next-line
let padTime = (t, l = 2) => t.toString().padStart(l, '0')

let Time = ({ value }) => (
  <div style={{ display: 'flex' }}>
    // highlight-next-line
    <EmojiNumber value={padTime(value.getHours())} />
    : // highlight-next-line
    <EmojiNumber value={padTime(value.getMinutes())} />
    : // highlight-next-line
    <EmojiNumber value={padTime(value.getSeconds())} />
  </div>
)
```

Time to make it dynamic:

```jsx
let CurrentTime = () => {
  let [now, setNow] = useState(new Date())

  useEffect(() => {
    // highlight-start
    // it is more reliable to increment time
    // by creating new Date object
    // cause setInterval doesn't guarantee
    // that it will call our call back
    // in exactly 1000ms and rendering isn't free
    // highlight-end
    let tid = setInterval(() => setNow(new Date()), 1000)

    return () => clearInterval(tid)
  }, [setNow])

  return <Time value={now} />
}
```

Since we are trying to make some take-away out of this article, let's extract custom hook out of `jsx±<CurrentTime/>`:

```jsx
// highlight-start
let useIntervalValue = (factory, interval) => {
  let [value, set] = useState(factory)

  useEffect(
    () => {
      let tid = setInterval(() => set(factory), interval)

      return () => clearInterval(tid)
    },
    // ⚠️ we intententionally ignored 'factory' in dependencies array (for the sake of simplicity)
    // so it won't be updated with rerenders (simular to useState initializer)
    // while we could add deps argument to this hook to be able to update 'factory'
    [interval]
  )

  return value
}
// highlight-end

let CurrentTime = () => {
  // highlight-next-line
  let now = useIntervalValue(() => new Date(), 1000)

  return <Time value={now} />
}
```

Power of composition! So far we've built pretty simple _"app"_, yet it consists of 5 blocks (components/functions). Composition is definitely one of the strongest part of _react_ especially with _hooks_.

Let's look at the result:

![Digital clock with emoji](/uploads/no-animation-digital-clock.gif 'Digital clock with emoji')

## Time to animate

Event though our clock already looks pretty decent, we was going to add a fancy animation to it. So let's do it!

The best library for animation in react I know is [react-spring](https://github.com/react-spring/react-spring), I have already used it in [one of my previous articles](/blog/implementing-medium-like-tooltip/). And I am gonna use it again.

Here we are going to animate update of every emoji independently using [useTransition](https://www.react-spring.io/docs/hooks/use-transition) hook. Time for a new component?

The only tricky part here is to position animated blocks, I had to add extra hidden block in normal flow to preserve space. Without it our relative wrapper will collapse - all its other children are absolutely positioned. As an alternative we could also set fixed _height_/_width_ to our container or render one children once to calculate their size.

Do you know some other solutions? Share it comments.

```jsx
// children can be any react element
let Waterfall = ({ children }) => {
  let transitions = useTransition(children, null, {
    from: {
      position: 'absolute',
      top: 0,
      left: 0,
      transform: 'translate3d(0,-100%,0)',
      opacity: 0,
    },
    enter: { transform: 'translate3d(0,0,0)', opacity: 1 },
    leave: { transform: 'translate3d(0,60%,0)', opacity: 0 },
  })

  return (
    // highlight-next-line
    /* we will render animated blocks relative to this container */
    <div style={{ position: 'relative' }}>
      // highlight-next-line
      {/* we need one hidden extra block in normal flow to preserve space */}
      <div style={{ visibility: 'hidden' }}>{children}</div>
      {transitions.map(({ key, item, props }) => (
        <animated.div key={key} style={props}>
          {item}
        </animated.div>
      ))}
    </div>
  )
}
```

Now we can animate our `jsx±<EmojiNumber />` using this component 🎉:

```jsx
// highlight-next-line
let AnimatedEmojiNumber = ({ value }) => (
  <div style={{ display: 'flex' }}>
    {value
      .toString()
      .split('')
      .map((n, i) => (
        // highlight-next-line
        <Waterfall key={i} children={emojiDigits[n]} />
      ))}
  </div>
)
```

And full result you can find here:

[animated-digital-clock](embedded-codesandbox://enjoy-the-little-things/result)

## The End

Let's sum up what just happened:

- we've build cool animated digital clock
- we've played with composition in _react_

  - created custom hook

- played with `react-spring`
- did all above 👆while staying isolated 🦠

It is important to note that in this article I was just messing around and didn't strive to build this animation in a most efficient way. It doesn't make sense to include `react` or `react-spring` to your web-site if you want to create something like this (both libraries are pretty heavy). Unless you already have both... And even if you do, I'm pretty sure there is more performant/easy way to achieve the same goal. Maybe later I'll revisit this article to cover this topic. But for now, I want to thanks for reading this 😙.


Enjoy the little things


## Mystique

While working on migration of part our [main web-site](https://tourlane.de) to [gatsby](http://gatsbyjs.org), we faced really weird problem: one of a links in navigation menu wasn't styled on initial load. It was reproducible only on the desktop.

![Navigation menu with unstyled link](/uploads/broken-link.jpg 'Unstyled link')

Once you opened some other page (using client-side routing), styles get in place 🤯.

The fact that component, responsible for this menu, worked absolutely fine in the old app (which is using _nextjs_), made everything even more weird 👻.

## Investigation

Without a second thought I opened DOM inspector and discovered that this link had css-classes related to mobile menu, while I was obviously on the desktop 🤪.

_"React messes up DOM during_ [_hydration_](https://ru.reactjs.org/docs/react-dom.html#hydrate)_"_ - I thought to myself. It was hard to believe: such crucial issue should have been discovered long time ago, and everything is fine IN THE OLD APP.

I revised hydration contract:

> React expects that the rendered content is identical between the server and the client.

I dig into source code of the component 🕵️‍♂️:

```jsx
// simplified NavBar.js
import React from 'react'
import Media from 'react-media'

export const NavBar = () => (
  <Media queries={{ maxWidth: 599 }}>
    {matches => (matches ? <MobileNav /> : <DesktopNav />)}
  </Media>
)
```

## Verdict

Do you see a problem here?

- [react-media](https://github.com/ReactTraining/react-media) is used to serve different markup for desktop and mobile
- we are migrating our app to _gatsby_, which means all our pages are statically built (SSR is happening during build time). And on this stage, we obviously do not have any information about _width_ of the screen. By default `react-media` matches all media queries, so in our case we build mobile layout.

This results in next workflow:

1. desktop browser requests page and receive mobile html (user sees it on first contentful paint)
2. react messes up DOM during _hydration_ (absolutely legally, since we produced 2 different trees on the _"server"_ and client)

## How to fix this?

To avoid such problems we can:

- prefer regular css media queries to [matchMedia](https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia)\
  \
  Even if you cannot style same piece of html to fit your adaptive design, you can _"duplicate"_ it (html) and display one _"copy"_ per breakpoint.

  ```jsx
  let DesktopOnly = styled.div`
    @media (max-width: 599px) {
      display: none;
    }
  `

  let MobileOnly = styled.div`...`

  export const NavBar = () => (
    <>
      <MobileOnly>
        <MobileNav />
      </MobileOnly>

      <DesktopOnly>
        <DesktopNav />
      </DesktopOnly>
    </>
  )
  ```

  In this case not only you will avoid problems with _hydration_, but also end-user will get better experience: there will be no layout flickering during page load, since browser will render the page according to your html/css, and hydration will give it life.

- only in case the approach above doesn't work for you, use `react-media` (or similar solutions). E.g.:
  - SEO might suffer (I haven't faced such problems, but I assume that duplication of content, its growth... can influence it 💁‍♂️. Write a comment if you are aware of such cases)
  - performance might suffer, in case you render some complex element only for the desktop.\
    \
    **ATTENTION PLEASE!** Do not optimize prematurely! Always measure performance before you introduce any improvements. The fact that _react_ will have to render 50 more html elements shouldn't bother you.
  - something else might suffer 🤷‍♂️

But what about problems with hydration we experienced using second approach?

Well, as I mentioned at the beginning, such issue shouldn't have been left out, so it has a solution - two-pass rendering:

- choose a default layout you'd like to use by default:
  - if you are using runtime SSR, you can do it based on _User Agent_
  - for static sites based on usage statistics (in most cases it should be mobile, since devices are less performant, and it doesn't make sense to make them render tree twice)
- render three using this default during SSR and client hydration
- run an extra render in case actual layout didn't match default one

Official documentation [suggests](https://ru.reactjs.org/docs/react-dom.html#hydrate) to use state variable to implement this and `react-media` also [supports this](https://github.com/ReactTraining/react-media#server-side-rendering-ssr) via `defaultMatches` prop:

```jsx{3-6}
export const NavBar = () => (
  <Media
    queries={{ mobile: { maxWidth: 599 } }}
    defaultMatches={{ mobile: true }}
  >
    {matches => (matches.mobile ? <MobileNav /> : <DesktopNav />)}
  </Media>
)
```

### P.S.

"Why didn't you experience the same issue in your old app?" - a careful reader might wonder 🤨. Indeed, we use SSR there as well and do not use knowledge about browser (_User Agent_). To be honest, I didn't dig into legacy project in order to learn its secrets. But I guess it's about some extra render initiated by parent components 😬.


React SSR pitfalls in building adaptive layouts


## 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


## Decompose it!

To tell the truth, [medium like tooltip](https://www.nikitakirsanov.com/blog/implementing-medium-like-tooltip/) was implemented not to allow you to quote me in twitter (I can hardly believe somebody would ever do that). But to provide functionality for reporting typos/mistakes (at least it is useful for me).

"Why did you even created* tweet feature* thought it wasn't you original goal?" you might ask.

Well it's because of my passion to introduce everything very gradually. E.g. I prefer creating several small commits to single bigger one. And I encourage you to do the same, cause it'll make it much easier:

- for others to review your code
- to explore git history eventually

But small commits doesn't mean you won't get any benefits until the last commit. And they shouldn't break anything, leaving you codebase in some intermediate state. Quite the opposite, every single commit should make you app/lib/whatever better: extend api (new feature), fix and issue, etc.

The same thing with features you implement. Try to decompose them as much as possible: the smaller increment you produce, the faster you deliver it, the faster you get feedback, the better quality of product you build.

## Let's get down to business

So what I mean by "functionality for reporting typos/mistakes": I want to add an action to tooltip developed in [previous article](https://www.nikitakirsanov.com/blog/implementing-medium-like-tooltip/), that will open dialog with form for submitting mistake.

1. The easiest part would be to just append button to tooltip. That is how it'll look:

![Typo action](/uploads/typo-action.jpg 'Typo action')

2. Now we should implement dialog. There is plenty of ready solutions for dialogs (like [react-modal](https://github.com/reactjs/react-modal), also lots of UI libraries offer them), but I would like to give a try to the one from [reach-ui](https://ui.reach.tech/) developed by [Ryan Florence](https://twitter.com/ryanflorence).
   Its api is pretty straightforward, so I won't show an example with it (you can easily find [it on its site](https://ui.reach.tech/dialog)). But I'd like to mentioned that to animate it I used [react-spring](http://react-spring.surge.sh), as I did for tooltip (and you can also find [an example of using them together](https://ui.reach.tech/dialog#animation-example)). Here is [source code](https://github.com/kitos/kitos.github.io/blob/develop/src/components/dialog.js) of my dialog and result:

![Typo dialog](/uploads/typo-dialog.jpg 'Typo dialog')

3. The last but not least thing we should implement is backend which will receive out submissions and put it somewhere .

##

A in JAMStack stands for...

Wait... How static site should deal with dynamic data? Is it even possible?

Sure! Nothing stops me from using some database and **A**PI (service) to communicate with it, but:

- I don't want to complicate infrastructure of my site
  Currently I am using only github pages
- I don't want to pay for infrastructure
  Moreover it mostly won't be used
- I don't want to develop back office to manage submissions
- I want to be fancy

So I decided to use [github issues](https://github.com/kitos/kitos.github.io/issues) as a storage and [google cloud functions](https://cloud.google.com/functions/) as a service. This allows me to address all issues above:

- The only new thing I'll introduce is GCP function which is created in a couple of clicks
- Unlike VMs or any other platform types, you pay only while your code runs
  Also GCP [offers 2 million calls for free](https://cloud.google.com/free/), and I probably won't be able to go beyond this limit
- GitHub has a neat way to manage issues
- 😎

Time to share some code, here is my cloud function:

```js
const axios = require('axios')
const querystring = require('querystring')

const github = axios.create({
  baseURL: 'https://api.github.com',
  headers: { 'User-Agent': 'blog-typo-issue-creator' },
  auth: {
    username: 'kitos',
    // always use environment variables for sensitive data
    password: process.env.GH_TOKEN,
  },
})

exports.createIssue = async (request, response) => {
  let { title, link, source, suggestion } = request.query

  try {
    let {
      data: { html_url },
    } = await github.post('/repos/kitos/kitos.github.io/issues', {
      title: `Typo in blog post "${title}"`,
      body: `
There is a typo post [${title}](${link}).
### Source:
${source}
### Suggestion:
${suggestion}
      `,
      assignees: ['kitos'],
      labels: ['blog:typo'],
    })

    response.status(200).send({ url: html_url })
  } catch (e) {
    console.error(e.message)
    response.status(500).send(e.message)
  }
}
```

Pretty straightforward, right?

But you might wondering why I decided to use github api via cloud function instead of direct call. Well, I expect that not all my readers have github account and they wouldn't like to create one to submit a typo. Also later this functionality might become a part of something bigger (remember my passion to decomposition? 😏).

## Integration

The last thing we should accomplish is to call our function when user submits form. It shouldn't cause any difficulties except [same origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy): gcp function domain is like

_https://gcpRegion-your-app-id.cloudfunctions.net/function-name_ and browser would allow to make such request.

Fortunately we have [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) mechanism which allows us to tell browser that it can use our resource (cloud function) from a different domain (

_www.nikitakirsanov.com_). And it's to implement it using GCP ([official docs](https://cloud.google.com/functions/docs/writing/http#handling_cors_requests)): you should add special response headers:

```js
exports.createIssue = async (request, response) => {
  ...
  response.set('Access-Control-Allow-Origin', "https://www.nikitakirsanov.com")
  response.set('Access-Control-Allow-Methods', 'GET')
  ...
}
```

That's it! To see a demo just select _any text in this or any other article_:


Dynamics in a static site


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.


Implementing medium like tooltip


## First steps

First time I thought about creating personal site was when I was taking java courses at EPAM Systems. The main motivation was to learn new things. So I've created a list of technologies I wanted to build my blog with:

![List of technologies](/uploads/blog-tech-stack.jpg 'Technologies')

At that moment I haven't worked with either of them (except MySQL I guess) and hardly understood how I could wire them all together. Also you might noticed that I didn't write a word about infrastructure and deployment of my future site (I had no idea about it).

Time went on, I got a job, started to get familiar with technologies from my list: we actively used Liquibase on my first project; I figured out that I can use fancy groovy and gradle instead of xml and maven to write build scripts; but the main frontend library was jQuery, and it was clear that I wouldn't like to use it in personal project. In a year I joined project with AngularJS, one more year later I had realized that I would not use either :-)

## Getting closer to right stack

Meanwhile react was getting more and more popular. And I decided to give it a try: colleagues of mine and I started local frontend community - WebPurple and to be true frontend community it must have its own site. Its first version has under the hood: react, redux,material-ui, koa, mongoose and was deployed to some VPS. I've learned a couple of things:

- Material Design fits tools best (not sites)
- managing content manually is bad idea
- IaaS is overkill (also painful) as well as PaaS (after a couple of months fighting with manual setup of all infrastructure to VM I've moved to heroku and mlab) for promo site
- I don't want to pay for hosting (or a at least it to be cheap)
- I want WebPurple site to be BLAZING fast (without much effort)

## Love at second sight

Any ideas on what I am gonna talking about? Static site generation, JAMStack, GastbyJS! In early 2018, I began to hear more and more about Gatsby. I don't know why didn't pay much attention to it when I first time heard about it (I might thought it is not applicable for my cases). But after I started to investigate the approach (JAMStack) it offers I had fallen in love 😍. It took me about 2 weeks to migrate the whole (thought it is not that big) site from koa, mongodb and heroku to gatsby, netlify-cms and netlify.

- ⚡️site had perfect performance by default
  - static markup (first load)
  - code splitting
  - image optimization
  - prefetch...
- 💃content is easily managed via CMS
  - user friendly UI
  - extensible (build on react)
  - content stored alongside your code (in git repo!)...
- 🙈infrastructure is the simplest (ADN aka better CDN)
  - CD - deploy on every git push
  - automatic PR preview
  - https, custom domains, AWS lambdas...

You can checkout the result - www.webpurple.net (source). I've even given a talk (russian) about it.

Later I've applied gatsby for one of my customers news site, but with a bit different setup: strapi as a CMS and Jenkins as a CD tool.

## Happy end

Finally I felt like I've found best toolchain and it was time to get my hands on personal site. Since I fill pretty comfortable with technical stack (although this time I use contentful as CMS, travis as CI/CD and github pages as a hosting), my motivation is less about learning new things and more about improving my english (via writing articles about amazing things I deal with) and a bit of showing off 🤓. I hope you enjoy the site (its unique design 😇). And you started to think about building your one (using great gatsby of course). Keep in mind that gatsby is suitable not only for blogs or promo-sites, it can make any of your sites performant (even for e-commerce project).

### P.S.

By the way I've started to develop my site before it had become mainstream 😂.


Blog

By tag

2021