DEV Community: aabdullin

Making Nuxt.js clone with Vue 3 and Vite (Vue Custom Server Side Rendering)

aabdullin — Tue, 30 Aug 2022 10:00:00 +0000

Competently writing applications in JavaScript is sometimes not an easy task, but this task can become much more difficult in a situation where one day your application will need indexing by search engines such as Google, DuckDuckGo, Bind, etc. And the problem is that not all of them are able to index SPA applications correctly, and before you will face the task of turning from Client Side Render (CSR) into an application with Server Side Render (SSR) support.

This article will be useful for those who want to write an application with Custom Server Side Rendering. For those who want to add SSR support to the existing application. But also, of course, those who work with Nuxt, and want to learn more about how it works under the hood.

You can find all the code from the article and an example of the project here.

P.S. If you want jump to the code, scroll to Let's start writing code section

SSR Framework Requirements

And so I want to more accurately outline my requirements for an ideal framework for server side rendering, I have prepared a visual visualization:

Learn more about each item:

Lazy Loading - the framework should be able to split routes into different chunks to reduce the weight of the bundle that the user loads by logging into the application. The benefit of Vite and the plugin for Vue out of the box in the process of rendering the application on the server side is to register all the modules that will need to be uploaded to the user, more here.
Middlewares - the framework should allow you to write Middleware, in order to redirect unregistered users that should not have access to the page, or make some pages possible to view only in guest mode.
Nested routes - the router should allow you to create a complex composition of nested pages.
Data Fetching - each page should be able to load data from the API, and take into account the nested pages.
Integration with Pinia - Each page pulls certain actions at the time of loading data, but what happens if one of the API calls returns a 404 error? For example, we have an action fetchProduct that transmits the product id, and if we receive a 404, we should be able to say that we should give the page with the 404 status to the user, or even make a redirect directly in the action, without taking this logic outside the action. It seems to me that the close integration of the store with the SSR router to solve such situations is a frequent omission in the world of modern SSR frameworks.
Working with Head - And of course, what kind of SEO without meta tags, the framework should provide the ability to edit the contents of the <head /> tag both on the server and client side.

Why custom Server Side Rendering?

First reason what i see it is a interest in how Nuxt/Next works under the hood for educational purposes, and second when you have a lot of expirience with Nuxt/Next and already exactly know why need it, and you have already met the limitations in other frameworks 😄

For example:
How to customize nuxt default html template in Nuxt 3?
In Nuxt 2 we have BODY_SCRIPTS, but not in Nuxt 3 (At the time of writing article).

Or i have problem what i am not able to get user ip address, because it is undefined in Nuxt 3 server-middleware 😕 (At the time of writing article).

A few words Vite

Vite very fast bundler oriented EcmaScript Modules.
He have Vue SSR example repository.

Routing
Lazy Loading
Data Fetching
Middlewares
Working with
Integration with Pinia
Routing

We use Vue Router, it's very flexible API compared to any routers.

Lazy Loading

Default Vue Router Lazy loading mechanism. All works out of the box 😍

Data Fetching

Let’s talk about the data fetching method.
For fetching data in Nuxt 3, you could see that useAsyncData is used, and I suggest taking a look at how it works inside, here and we see that they use onServerPrefetch for fetching data, but how does it work?
In fact, as soon as Vue encounters onServerPrefetch, rendering of the component stops until the asynchronous operation is performed, and only after that Vue will continue the rendering process. Learn more about onServerPrefetch here.

Here I want to draw your attention to two things:

onServerPrefetch was added to Vue in order to give the developer the opportunity to fetch data at any level of component nesting, and not as it is arranged in Nuxt 2 when the custom option asyncData is available only at the page component level.
But this approach also has disadvantages, because it is a compromise between convenience (Development Experience) and performance. Because each call to onServerPrefetch will stop the rendering process and wait until the rendering can be continued, and in the case of nested routes we have one problem, I suggest looking at the waterfall graph:

Here we able to see, then we have 3 level nested route, before calling the next onServerPrefetch, we must wait for the previous one to complete its work. And in case then we have 3 API calls that resolve after ~1.4, ~2.1, ~1.5 seconds:

onServerPrefetch/useAsyncData the user need wait all API requests, that equal in total to 5 seconds.
asyncData the user need wait only longest API request, that equal to 2.1 seconds.

This is concepts of how we able fetch data.
And because nested routing is important concept in our framework we choose asyncData option. And we have one limitation, all page level components that use asyncData need to use defineComponent API.

A little more about the nested routes

For example Next has one big architectural flaw (At the time of writing article), it does not know how to work with nested routes. For those who do not know, Vue Router allows using the component <router-view /> to display child pages, at any nesting level. I have prepared a visual visualization of what nested routes are, for those who are familiar with React + Remix I think it will be very familiar. Because nested routes are killer features Remix.
By the way, while I was writing the article, Layouts RFC came out on the Next blog.js, which means that soon there will be support in Next.js .
Let's go back to the Remix framework:

Here you can clearly see that the components <Root />, <Sales />, <Invoices />, <Invoice /> are pages, each of which has its own component, just as it works with nested routes in Vue Router.
Vue Router uses a config file for the declaration of routes, I think this is the most convenient and flexible way to declare routes. But this approach in the case of SSR burdens us with the need to be able to fetch the data of all nested pages that match the url with our routes, more details below.

Why Vue 3 is the best for Server Side Rendering?

Evan Yoo and the Vue Core Team have done a lot of work on optimizing the Vue SFC compiler, and improved TypeScript support.
But the most important killer feature of Vue is that for SSR bundle, the runtime of components is different from the runtime of components for CSR. There is a separate compiler that converts our templates literally into strings.
For clarity, let's compare the runtime stages of the Vue 2/3 and React components at the time of rewriting on the server:

As you can see, Vue 2 and React, at the time of rendering the component <Component /> create VDOM first, and only then the renderToString function converts the viral nodes into drains (Not sure about Vue 2).
On the other side we have Vue 3, the rendering process of the components of which is includes normalization of dynamic attributes and string concatenation.

I suggest you take a visual look at how it looks in Vue 3:

<script lang="ts">
import { defineComponent } from 'vue'

export default defineComponent({
  props: {
    alt: String,
    png: String,
    webp: String,
  },
})
</script>

<template>
  <picture class="picture">
    <source :srcset="$props.webp" type="image/webp">
    <source :srcset="$props.png" type="image/png">
    <img
      :src="$props.png"
      :alt="$props.alt"
      draggable="false"
      loading="lazy"
    >
  </picture>
</template>

<style>
.picture > img {
  width: 100%;
}
</style>

What do you think this template will look like after compilation?
You can learn more about the work of the Vue SFC Compiler here in SFC Playground (click open the "SSR" tab).

/* Analyzed bindings: {} */

import { defineComponent } from 'vue'

const __sfc__ = defineComponent({
  props: {
    alt: String,
    png: String,
    webp: String,
  },
})

import { mergeProps as _mergeProps } from "vue"
import { ssrRenderAttr as _ssrRenderAttr, ssrRenderAttrs as _ssrRenderAttrs } from "vue/server-renderer"
function ssrRender(_ctx, _push, _parent, _attrs, $props, $setup, $data, $options) {
  _push(`<picture${
    _ssrRenderAttrs(_mergeProps({ class: "picture" }, _attrs))
  }><source${
    _ssrRenderAttr("srcset", _ctx.$props.webp)
  } type="image/webp"><source${
    _ssrRenderAttr("srcset", _ctx.$props.png)
  } type="image/png"><img${
    _ssrRenderAttr("src", _ctx.$props.png)
  }${
    _ssrRenderAttr("alt", _ctx.$props.alt)
  } draggable="false" loading="lazy"></picture>`)
}
__sfc__.ssrRender = ssrRender
__sfc__.__file = "App.vue"
export default __sfc__

And what can we see here? An experienced developer familiar with React would be surprised to see this for the first time.
Since the runtime process of the Vue 3 component in the server rendering process is string concatenation, this is an insanely fast comparison operation with creating a VNode for each element as in React.

Let's start writing code

Bundling SSR applications using Vite

For bundling, we will use Vite for several reasons:

Vite is the de facto standard for Vue 3, yes, Vue 3 can be assembled by Webpack, but first of all, the custom Webpack config will have to be constantly updated as updates, and this is not such an easy task in itself. And it is incredibly difficult to find manuals for Vue 3 at least at the time of the middle of 2021, and in contrast we have a collection with the simplest possible config file (finally 🥹) sharpened to a greater extent for Vue.
The speed of work, with the right setup, the same Vita setup will be faster than the Webpack in everything except the build speed, the speed of the Hot Module Replacement (HMR) is especially pleasing, this is the thing that makes you reload CSS, Vue files and so on without reloading the page.
Openness and simplicity, you can find a discussion of the new Vita features in issues/RFC, etc. and to study the code base of the Vita is much easier in my opinion than to understand how Webpack works. For example, in this article, I sometimes openly refer to some points in the sources of the same vitejs/plugin-vue, and it is not as difficult to understand it as it seems.

I recommend that instead of manually initializing the project, I recommend to clone the official SSR-example or my demo project for this article (I recommend it).

And so let's move on to setting up the Vite config:

/* vite.config.js */
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  css: {
    modules: {
      generateScopedName: '[hash:base64:5]',
      hashPrefix: ' ',
    },
  },
})

The main thing we need to do is to connect vitejs/plugin-vue.
You can also pay attention that I use css.modules.generateScopedName in the value [hash:base64:5], you don't have to do this, but if you use CSS modules, this parameter will allow you to get CSS class names like vwGJw, this is very concise, and allows you to slightly reduce the size of CSS files, JS files, as well as reduce the size of the HTML document by saving on the length of CSS classes.

In package.json add the following scripts:

{
  "scripts": {
    "dev": "node server.js",
    "build": "vue-tsc --noEmit && yarn run build:client && yarn run build:server",
    "build:client": "vite build --ssrManifest --outDir dist/client",
    "build:server": "vite build --ssr src/entry-server.ts --outDir dist/server",
    "serve": "cross-env NODE_ENV=production node server.js"
  },
}

And create a file index.html, and server.js at the root of the project.
You can create a server.ts, and use replace the dev script with node --experimental-specifier-resolution=node --loader ts-node/esm server.ts, but this has one big disadvantage, the start speed of the application, especially for production it is critical, so I I recommend not using TypeScript for server.js file, but this is the only JavaScript file that we will have.

Here are the minimum files we need to create for our SSR to work:

What does each of them mean?

App.vue - the input component of our application
main.ts - function to initialize our application, there we will call createSSRApp, createRouter, createPinia, createHead, etc.
entry-server.ts - here will be stored the same render function responsible for rendering on the server side that we connect to server.js.
entry-client.ts - well, by analogy, we will have an input file for the client bundle, which will not run on the server, but serves for the hydration process of our application.

And let's start with the content server.js:

// In the polyfills file.js you can connect polyfills for fetch calls in the environment Node.js
// https://github.com/fyapy/vue3-vite-custom-ssr-example/blob/master/src/server/polyfills.ts
require('./server/polyfills')
const fs = require('fs')
const path = require('path')
const express = require('express')

const resolve = p => path.resolve(__dirname, p)

async function createServer(
  root = process.cwd(),
  isProd = process.env.NODE_ENV === 'production'
) {
  const indexProd = isProd
    ? fs.readFileSync(resolve('dist/client/index.html'), 'utf-8')
    : ''

  const manifest = isProd
    ? require('./dist/client/ssr-manifest.json')
    : {}

  const app = express()

  /**
   * @type {import('vite').ViteDevServer}
   */
  let vite
  if (!isProd) {
    vite = await require('vite').createServer({
      root,
      logLevel: 'info',
      server: {
        middlewareMode: 'ssr',
        watch: {
          usePolling: true,
          interval: 100,
        },
      },
    })

    app.use(vite.middlewares)
  } else {
    app.use(require('compression')())
    app.use(
      require('serve-static')(resolve('dist/client'), {
        index: false,
      })
    )
  }

  app.use('*', async (req, res) => {
    // handler...
  })

  return {
    app,
    vite,
  }
}

exports.createServer = createServer

This is almost a basic setup of the Vite server programmatically.
But the most interesting thing is where all the formation of the server response body to our user takes place, all the work with caching, etc.

app.use('*', async (req, res) => {
  try {
    let template, render
    if (!isProd) {
      // In dev mode, we load on the fly index.html
      template = fs.readFileSync(resolve('index.html'), 'utf-8')
      template = await vite.transformIndexHtml(req.originalUrl, template)
      // And in the same way we load the render function
      render = (await vite.ssrLoadModule('/src/entry-server.ts')).render
    } else {
      template = indexProd
      // In the case of production, we already have a ready bundle that we will connect
      render = require('./dist/server/entry-server.js').render
    }

    const {
      html: appHtml,
      preloadLinks,
      headTags,
    } = await render({
      url: req.originalUrl,
      req,
      res,
      manifest,
    })

    const html = template
      .replace('<!--head-tags-->', headTags)
      .replace('<!--preload-links-->', preloadLinks)
      .replace('<!--app-html-->', appHtml)

    res.set({ 'Content-Type': 'text/html' }).end(html)
  } catch (e) {
    vite && vite.ssrFixStacktrace(e)
    console.log(e.stack)
    res.status(500).end(e.stack)
  }
})

The contents of the file App.vue, the most standard, inside which there is a <router-view /> in which we will display the top level of the pages of our pages. Here is the router config:

import {
  createMemoryHistory,
  createRouter as _createRouter,
  createWebHistory,
  type RouteRecordRaw,
} from 'vue-router'
import Resources from './pages/Resources/Resources.vue'
import Resource from './pages/Resources/Resource.vue'


const routes: RouteRecordRaw[] = [

  {
    path: '/',
    component: Resources,
    children: [
      {
        path: 'resource/:id',
        component: Resource,
        children: [
          {
            path: 'transactions',
            component: () => import('./pages/Resources/Transactions.vue'),
          },
          {
            path: 'requisites',
            component: () => import('./pages/Resources/Requisites.vue'),
          },
        ],
      },
    ],
  },
  {
    path: '/home',
    component: () => import('./pages/Home.vue'),
  },
  {
    path: '/:pathMatch(.*)*',
    component: () => import('./ui/pages/NotFound.vue'),
  },
]

export const createRouter = () => _createRouter({
  history: import.meta.env.SSR ? createMemoryHistory() : createWebHistory(),
  routes,
  scrollBehavior() {
    return {
      top: 0,
    }
  }
})

The most important thing here is that the creation of a router instance is a function, in normal SPA it's just a hanging global variable, but because the concept of server-side application rewriting implies that for each request we create a completely new application instance, including routing.
And don't miss this condition:

import.meta.env.SSR ? createMemoryHistory() : createWebHistory()

Because the History API is not available on our server, we create a MemoryHistory, which is a mock History instance in the browser.
And import.meta.env is the ECMAScript version of `process.env'.

The 'main.ts` file is responsible for initializing the Vue instance of the application.

import App from './App.vue'
import { createSSRApp } from 'vue'
import { createPinia } from 'pinia'
import { createRouter } from './router'

export const createApp = () => {
  const app = createSSRApp(App)
  const router = createRouter()
  // we will create a store instance right away for one thing
  // we'll need it very soon
  const pinia = createPinia()

  app.use(router)
  app.use(pinia)

  return {
    app,
    pinia,
    router,
  }
}

File server-entry.ts:

import type { Request, Response } from 'express'
import { renderToString, SSRContext } from 'vue/server-renderer'
import serialize from 'serialize-javascript'
import { createApp } from './main'


interface AppContext {
  req: Request | null
  res: Response | null
  pinia: Pinia
  router: Router
  query: LocationQuery
  params: Record<string, string>
}

export type Manifest = Record<string, string[]>


export const render = async ({
  url,
  req,
  res,
  manifest,
}: {
  url: string
  manifest: Manifest
  req: Request
  res: Response
}) => {
  const { app, router, pinia } = createApp()

  router.push(url)
  await router.isReady()

  const ctx: SSRContext = {}
  const html = await renderToString(app, ctx)

  const preloadLinks = renderPreloadLinks(ctx.modules, manifest)

  const initialState = serialize(pinia.state.value)

  return {
    html,
    initialState,
    preloadLinks,
  }
}

function renderPreloadLinks(modules: string[], manifest: Manifest) {
  let links = ''
  const seen = new Set()
  modules.forEach((id) => {
    const files = manifest[id]
    if (files) {
      files.forEach((file: string) => {
        if (!seen.has(file)) {
          seen.add(file)
          const filename = basename(file)
          if (manifest[filename]) {
            for (const depFile of manifest[filename]) {
              links += renderPreloadLink(depFile)
              seen.add(depFile)
            }
          }
          links += renderPreloadLink(file)
        }
      })
    }
  })
  return links
}
function renderPreloadLink(file: string) {
  if (file.endsWith('.js')) {
    return `<link rel="modulepreload" crossorigin href="${file}">`
  } else if (file.endsWith('.css')) {
    return `<link rel="stylesheet" href="${file}">`
  } else if (file.endsWith('.woff')) {
    return ` <link rel="preload" href="${file}" as="font" type="font/woff" crossorigin>`
  } else if (file.endsWith('.woff2')) {
    return ` <link rel="preload" href="${file}" as="font" type="font/woff2" crossorigin>`
  } else if (file.endsWith('.gif')) {
    return ` <link rel="preload" href="${file}" as="image" type="image/gif">`
  } else if (file.endsWith('.jpg') || file.endsWith('.jpeg')) {
    return ` <link rel="preload" href="${file}" as="image" type="image/jpeg">`
  } else if (file.endsWith('.png')) {
    return ` <link rel="preload" href="${file}" as="image" type="image/png">`
  }
}

Here we are interested in several mements:

renderPreloadLinks and renderPreloadLink are functions responsible for rendering CSS/JS resources that we load on the client side, it is fully compatible with the Lazy-loading mechanism of Vue Router, they are automatically registered during page rendering in Vue Vite Plugin here.
serialize is an important part that provides protection from XSS attacks, by escaping the contents of the store serialize(pinia.state.value).

And now let's write client-entry.ts:

import { createApp } from './main'

const { app, router, pinia } = createApp()

router.isReady().then(() => app.mount('#app'))

And this setup will allow us to launch the application already, and test how everything works.

Context

Now I propose to introduce a new concept of Context, I think many are familiar with it from Nuxt/Next frameworks.
So that's exactly what we will transfer to our middlewares and async Data page functions.

It consists of:

req/res - available only on the server side, I do not recommend using them directly.
pinia is an instance of our store, you will need it to use the store, because on the client side Pinia refers to a global object, but on the server side you cannot do this, because in the process of rendering our application on the server, we can simultaneously open different pages with several requests that cause their own actions, and as a result, the entire rendering process will refer to the same instance of the store, and we need to isolate the rendering process for each request. Here you can see how when calling defineStore Pinia tries to get an "active" instance.
query - query from the router
params - params from the router
router - router instance

And so when we have formed the Context, we can proceed to the work of middlewares and async Data.

Data fetching, middlewares and Context implementation

For data fetching we choose asyncData fetching strategy, because it is faster in case with nested routes.
And we have one limitation, all page level components that use asyncData need to use defineComponent API.

Your project should have a declaration file vue.d.ts, and in it you need to add new parameters asyncData, and middleware to Vue ComponentCustomOptions:

import type { AppContext as SSRAppContext } from './ssr'

// Typing for middleware
type RedirectLocation = {
  path: string
  status: number
}
type RedirectTo = void | string | RedirectLocation
type Middleware = (ctx: AppContext) => RedirectTo | PromiseLike<RedirectTo>


declare module '@vue/runtime-core' {
  interface ComponentCustomOptions {
    asyncData?(ctx: SSRAppContext): void
    middleware?: Middleware | Middleware[]
  }
}

export {}

We will use the ComponentCustomOptions data at the page component level.

asyncData - option for uploading data
middleware - serves as an analogue of Navigation Guards from Vue Router, but unlike it will work both on the client side and on the server. You can call it guard if you/your team is more used to it.

And now let me show you clearly what it will look like:

<script lang="ts">
import { defineComponent } from 'vue'

export default defineComponent({
  middleware: () => '/redirected-to', // You can write a separate file for middleware, and import it here
})
</script>

It's very similar to Navigation Guards from Vue Router?
Isn't it? That's just where the Context of our application is available to you, and you can contact Pinia for example to verify authorization

const authMiddleware: Middleware = ({ pinia }) => {
  // !!! Important !!!
  // tell all the stores you are contacting
  // Pinia instance, otherwise you will have problems because Pinia will access the global object
  // https://github.com/vuejs/pinia/blob/8626aac0049243de231401a01fe20092eeaf279c/packages/pinia/src/store.ts#L870
  if (!authStore(pinia).isAuth) {
    return {
      path:'/login',
      status: 401,
    }
  }
}

And here is an example of using asyncData:

<script lang="ts">
import { computed, defineComponent } from 'vue'
import { useStore } from '../../store'

export default defineComponent({
  asyncData: ({ pinia, params }) => useStore(pinia).fetchRequisites(params.id),
  setup() {
    const store = useStore()

    const requisites = computed(() => store.requisites)

    return {
      requisites,
    }
  },
})
</script>

And at the same time there are two important points:

At the time of calling the store in asyncData, pass pinia there from the application context, otherwise there will be problems when rendering on the server side
In case of calling several actions that do not depend on each other, use Promise.all to run them in parallel, this is one of the most common mistakes of beginners when working with SSR, which has a very negative effect on the opening time of the page, do this:

export default defineComponent({
  asyncData: ({ pinia, params }) => Promise.all([
    useStore(pinia).fetchRequisites(params.id),
    useStore(pinia).fetchHome(),
  ]),
})

And now let's finally put the work of data ham and middle vars into action. And since middleware will have the ability to redirect the user, which should work both on the client and on the server, let's add a class with the error RedirectError:

export class RedirectError extends Error {
  redirectTo: string
  status: number
  _isRedirect = true

  constructor(redirectTo: string, status = 302) {
    super()

    this.redirectTo = redirectTo
    this.status = status
  }
}

In which we will pass the url for the redirect and the status of the redirect code, which by default is 302.
Many may say that a redirect by throwing an error is not the "right" thing, but it is firstly used only inside service functions, and does not affect business logic, and secondly it simplifies the mechanism of redirects.
And now let's make our middlewares work:

import { DefineComponent } from 'vue'

export const fireMiddlewares = async (
  components: DefineComponent[],
  context: AppContext
) => {
  // We take out the CustomOption middleware from the components
  const middles = components
    .map(c => c.middleware)
    .filter(Boolean)
    .flat() as Middleware[]

  if (middles.length !== 0) {
    const redirects = (
      await Promise.all(middles.map(m => m(context)))
    ).filter(Boolean)

    if (redirects.length !== 0) {
      for (const to of redirects) {
        if (typeof to === 'string') {
          throw new RedirectError(to)
        } else if (typeof to === 'object') {
          throw new RedirectError(to.path, to.status)
        }
      }
    }
  }
}

We will pass the application context and page components to the fireMiddlewares function, and I will tell you how to get them later.
In the meantime, let's write the same function for fetching data:

import { DefineComponent } from 'vue'

export const fireAsyncData = async (
  components: DefineComponent[],
  context: AppContext
) => {
  // We take it out of the components CustomOption asyncData
  const asyncs = components.map(c => c.asyncData).filter(Boolean) as Exclude<ComponentCustomOptions['asyncData'], undefined>[]

  if (asyncs.length !== 0) {
    await Promise.all(asyncs.map(a => a(context)))
  }
}

And after we have the opportunity to run async Data and middleware CunstomOptions, we will proceed to calling them in entry-client.ts:

import { createApp } from './main'
import { AppContext, fireAsyncData, fireMiddlewares, matchedComponents, RedirectError } from './ssr'

const { app, router, pinia } = createApp()

router.isReady().then(() => {
  pinia.state.value = window.__pinia

  router.beforeResolve(async (to, _from, next) => {
    try {
      const context: AppContext = {
        req: null,
        res: null,
        pinia,
        router,
        query: to.query,
        params: to.params as AppContext['params'],
      }

      const components = matchedComponents(to.matched)

      await fireMiddlewares(components, context)
      await fireAsyncData(components, context)

      next()
    } catch (e) {
      if (e instanceof RedirectError) {
        return next(e.redirectTo)
      }

      throw e
    }
  })

  app.mount('#app')
})

And I propose to sort out how everything works:

pines.state.value = window.__pinia - filling the store with serialized data
context - We form the application context on the client side.
router.beforeResolve - Vue Router has the most convenient hook that is called after Lazy-components are loaded, but not yet shown to the user, it can be used to work middlewares and asyncData on the client.
matchedComponents - Vue Router in the to.matched parameter, passes all the components of the pages, it is them that we normalize in the matchedComponents function, its implementation will be below.
RedirectError - in the catch block, we process errors, and immediately we can intercept all RedirectError errors and redirect on the client side.

Here is the implementation of matchedComponents:

import type { RouteRecordNormalized } from 'vue-router'
import type { DefineComponent } from 'vue'

export const matchedComponents = (matched: RouteRecordNormalized[]) =>
  matched.map((m) => Object.values(m.components)).flat() as DefineComponent[]

And now you can update server-entry.ts with peace of mind:

export const render = async ({
  url,
  req,
  res,
  manifest,
}: {
  url: string
  manifest: Manifest
  req: Request
  res: Response
}) => {
  const { app, router, pinia } = createApp()

  router.push(url)
  await router.isReady()

  const _route = router.currentRoute.value

  const context: AppContext = {
    req,
    res,
    pinia,
    router,
    query: _route.query,
    params: _route.params as AppContext['params'],
  }

  const components = matchedComponents(_route.matched)

  await fireMiddlewares(components, context)
  await fireAsyncData(components, context)

  const ctx: SSRContext = {}
  const html = await renderToString(app, ctx)

  const preloadLinks = renderPreloadLinks(ctx.modules, manifest)

  const initialState = serialize(pinia.state.value)

  return {
    html,
    initialState,
    preloadLinks,
  }
}

And also in server.js in the catch block, you need to add redirects to third-party servers to work:

if (e._isRedirect) {
  res.status(e.status)
  res.redirect(e.redirectTo)

  return
}

And now we have a fully working mechanism for restricting access to pages and a date ham 🥳
But there is still a lot of work to do with the integration of Pinia and Vue Router, and work with Head.

Integration router redirects, HTTP Status codes with Pinia

So, I think many people are not familiar with the concept of integrating a router into the Store, but in fact they most likely met the Connected React Router library, it allows, for example, with successful authentication directly in the action, to redirect the user to the /profile or /dashboard page, this allows the authentication logic do not spread beyond the action.
To begin with, we will write timings for the state of this store.

type HistoryState = {
  _router: Router | null
  _redirectUrl: string | null
  status: number
}

Let's look at what we have here and why:

_router is a link instance of our Vue Router, in order to have access to calling the push, replace method, etc., so that redirects work on the client side.
_redirectUrl - in case of a redirect, there will be a url to which we need to redirect the user. Used only on the server side.
status - HTTP Status code of the server response, whether it is 200, 302, or 404.

And now we will write the very implementation of the store that will be responsible for this integration:

export const useHistory = defineStore('history', {
  state: (): HistoryState => ({
    _router: null,
    _redirectUrl: null,
    status: 200,
  }),
  actions: {
    setStatus(status: number) {
      this.status = status
    },
    _setRouter(_router: HistoryState['_router']) {
      (this._router as unknown as HistoryState['_router']) = _router
    },
    push(path: string, status = 302) {
      this.status = status
      this._redirectUrl = path
      this._router?.push(path)
    },
    replace(path: string, status = 302) {
      this.status = status
      this._redirectUrl = path
      this._router?.replace(path)
    },
    go(delta: number) {
      this._router?.go(delta)
    },
    back() {
      this._router?.go(-1)
    },
    forward() {
      this._router?.go(1)
    },
  },
})

And so, let's go through the methods:

push, replace, back, go, forward - their purpose is simply to proxy calls to the router, and in case of a redirect, write its HTTP Code, and redirectUrl itself.
_setRouter - since we cannot directly access global objects in the case of server rendering, we need a method in order to bind/unlink the router instance to the store.
setStatus - the ability to manually set the status of the response code, for example, when the API returns a 404 code to us in order to let search engines understand that the page they are looking for has not been found.

And now the example of using this integration is clear, let's imagine that we have a Pinia store with the fetchRubric action:

async fetchRubric(rubricSlug: string, citySlug: string) {
  try {
    const {
      city,
      rubric,
      reviews,
    } = await http.get(`/rubrics/page/${rubricSlug}/${citySlug}`)

    this.reviews = reviews
    this.data = {
      city,
      rubric,
    }
  } catch (e: any) {
    this.error = e
    useHistory(this._p).setStatus(e.status === 404
      ? 404
      : 500)
  }
},

We can see here how in the case of an API response with a 404 error, we say that the user should also receive a 404 code.

You may have noticed that the call to the store useHistory(this._p) is accompanied by the parameter this._p, this is a mandatory parameter that passes the Pinia instance to the store, by analogy as we did in CustomOption asyncData and middleware. Or here for example is an example of an authentication action:

async login(values: LoginValues) {
  this.isSending = true

  try {
    const { accessToken } = await http.post('/auth/login', values)

    setAccessToken(accessToken)
    useHistory(this._p).push('/profile')
  } catch (e) {
    if (e instanceof Response) {
      return (await e.json()).message
    }
  } finally {
    this.isSending = false
  }
}

In this case, in case of a successful response, we redirect the user to the profile url.

And now let's make server-entry.ts and client-entry.ts be able to work with this integration.
I suggest starting with server-entry.ts:

export const render = async ({
  url,
  req,
  res,
  manifest,
}: {
  url: string
  manifest: Manifest
  req: Request
  res: Response
}) => {
  // ...code

  const context: AppContext = {
    req,
    res,
    pinia,
    router,
    query: _route.query,
    params: _route.params as AppContext['params'],
  }

  const historyStore = useHistory(pinia)
  useHistory(pinia)._setRouter(router)

  const components = matchedComponents(_route.matched)

  await fireMiddlewares(components, context)
  await fireAsyncData(components, context)

  if (historyStore._redirectUrl) {
    throw new RedirectError(historyStore._redirectUrl, historyStore.status)
  }
  if (historyStore.status !== 200) {
    res.status(historyStore.status)
  }

  const ctx: SSRContext = {}
  const html = await renderToString(app, ctx)

  const preloadLinks = renderPreloadLinks(ctx.modules ?? [], manifest)

  useHistory(pinia)._setRouter(null)
  const initialState = serialize(pinia.state.value)

  return {
    html,
    initialState,
    preloadLinks,
  }
}

Here, after creating the context, we have added the following steps:

Let's create an instance of our store with the name historyStore.
Binding to the historyStore instance of the router useHistory(pinia)._setRouter(router).
Checking if (historyStore._redirectUrl) for a redirect.
Checking if (historyStore.status !== 200) to change the response code.
And before the serialization stage of the store, we untie the router instance useHistory(pinia)._setRouter(null) because it is not needed during the hydration of the serialized store, d and in general on the server side will no longer be needed.

Everything is fine with the server.
Next in line is client-entry.ts:

router.isReady().then(() => {
  pinia.state.value = window.__pinia
  useHistory(pinia)._setRouter(router)

  router.beforeResolve(async (to, _from, next) => {
    // no changes
  })

  app.mount('#app')
})

Here we just need to link the router instance to the store, and that's it, the integration will work correctly on the client side.
Now we can store all the logic inside our actions 😍

Head and SEO tags

I think it's no secret that Server Rendering is usually resorted to if search engines need correct indexing.
To work with head, Vue 3 already has the vueuse/head library, while it supports SSR. You can find all the documentation on working with it in their repository, and I'll show you a simple example and help you introduce it to server rendering.
And so in the application code, you just need to call useHead at any level of component nesting:

<script lang="ts">
import { computed, defineComponent } from 'vue'
import { useHead } from '@vueuse/head'

export default defineComponent({
  setup() {
    const rubricStore = useRubricStore()

    // code...

    useHead({
      title: computed(() => rubricStore.data!.rubric.title),
      meta: [
        {
          name: 'description',
          content: computed(() => rubricStore.data!.rubric.metaDescription),
        },
      ],
    })

    // code...
  }
})
</script>

Update the main.ts file, add the initialization of the VueHead instance there:

import App from './App.vue'
import { createSSRApp } from 'vue'
import { createPinia } from 'pinia'
import { createHead } from '@vueuse/head'
import { createRouter } from './router'

export const createApp = () => {
  const app = createSSRApp(App)
  const router = createRouter()
  const pinia = createPinia()
  const head = createHead()

  app.use(router)
  app.use(pinia)
  app.use(head)

  return {
    app,
    head,
    pinia,
    router,
  }
}

And in the file server-entry.ts we will add the following:

import { renderHeadToString } from '@vueuse/head'

export const render = async ({
  url,
  req,
  res,
  manifest,
}: {
  url: string
  manifest: Manifest
  req: Request
  res: Response
}) => {
  const { app, router, pinia, head } = createApp()

  // code...

  const ctx: SSRContext = {}
  const html = await renderToString(app, ctx)

  const { headTags, htmlAttrs, bodyAttrs } = renderHeadToString(head)

  const preloadLinks = renderPreloadLinks(ctx.modules ?? [], manifest)

  // code...

  return {
    html,
    initialState,
    preloadLinks,
    headTags,
    htmlAttrs,
    bodyAttrs,
  }
}

In index.html add a comment  at the end of the <head /> tag, and I also recommend adding comments for the <html /> and <body /> tags to insert attributes <html${htmlAttrs}> and <body${bodyAttrs}> accordingly, they will be needed in order to replace them with real tags formed by vueuse/head. Read more in my home repository.

And in server.js it's enough to add the following to the handler:

app.use('*', async (req, res) => {
  try {
    // code...

    const {
      html: appHtml,
      preloadLinks,
      headTags,
      htmlAttrs,
      bodyAttrs,
      initialState,
    } = await render({
      url: req.originalUrl,
      req,
      res,
      manifest,
    })

    const html = template
      .replace('<!--head-tags-->', headTags)
      .replace(' ${htmlAttrs}', htmlAttrs)
      .replace(' ${bodyAttrs}', bodyAttrs)
      .replace('<!--preload-links-->', preloadLinks)
      .replace('<!--app-html-->', appHtml)
      .replace('window.__pinia = {};', `window.__pinia = ${initialState};`)

    res.set({ 'Content-Type': 'text/html' }).end(html)
  } catch (e) {
    // code...
  }
})

Here we are most interested in using replace on our template, it is this that allows us to throw data into index.html .
And now you have the opportunity to display any SEO tags you like.
But there is still one more important topic in the SSR case.

Caching

Server rendering solves some SPA problems, but it has one significant disadvantage, it is INSANELY EXPENSIVE.
Just think about it, you need to initialize an entire JS application every request, despite the fact that Vue is much faster than React in this case, it is not easy to withstand a sharply increased flow of users in the case of a successful advertising company. 😅
Also DDOS attacks will quickly put your server on the shoulder blades, given that SSR is about heavy synchronous computing, which is the weak point Node.js. And caching the server response in the case of SSR helps a lot, and has a positive effect on such a metric as "Time to first byte".

And so in Vue 2 we had such a cool feature as serverCacheKey, this is the thing that allowed caching at the component level.
But there is no such chip in Vue 3, here are issues. However, considering how much the SFC Compiler was optimized, the benefit from serverCacheKey would not be so great.

Therefore, the most convenient way of caching will be to use Redis. There are two ways:

Cache using Redis at the Nginx level by writing a LUA script.
Or use Redis at the Node.js level of the process.

The first option should be faster, but the second is easier to implement.
However, there remains the problem of resetting the cache. Here I will not show a specific implementation, but I will give a couple of tips, including how to reset the cache:

Caching the server response of authorized users does not make much sense.
For "guest" sessions, you can use the url as the cache key.
When restarting Node.the js of the process responsible for SSR should reset the cache. Also, in the case of restarting the Backend, it is also worth resetting the cache, you can simply send a message to Redis Pub/Sub, and Node.the js process responsible for the SSR will already listen to it, and reset the cache itself, so that the Backend does not need to know how the cache works.
But on a large project to reset the cache, you may need to make a more complex cache reset scheme when updating data on the Backend, and send to the front the entity that has been changed, and the front itself will decide which keys it needs to disable.

Well, don't forget about multithreading, it can be covered with Worker threads and the Cluster module, PM2, Docker.

Conclusion

And in the end, let me present a production application that uses Vue 3 and Vite:

A good reason to choose Vue for SSR is it's a very fast hydration process.

Achieving a 90+ performance score on the Lighthouse mobile test is not as difficult as it is with React.
Yeah, Vue Team did a great job 👍

You can find all the code from the article and an example of the project here.

Making Node.js Backend API Localization without i18next

aabdullin — Fri, 05 Aug 2022 03:32:00 +0000

I think many developers sooner or later face the need to localize / internationalize their applications, whether it is localizing texts or simply collecting metrics about different user groups, in this article I will cover the topic of backend localization on Node.js.
In this case, I will cover the topic of sending messages about the failure of the request, at its various stages, starting from the usual messages in the request body, and the localization of error messages at the request body validation stage.

I note right away that all examples will be using the Fastify web framework, but are also fully applicable to Express, Koa, and other web frameworks.

And so, first of all, let's get acquainted with the visualization of the request life cycle, and how the implementation of the localization work will work:

Pay attention to two main parts:

Business logic - localization of errors / texts that will be sent as a result of working with business logic, here you can also include simple errors from preHandlers, for example, authorization
Validation - the logic that is responsible for validating the request body req.body, (checking user authorization is not included here)

Below we will primarily consider working with the business logic layer, and at the end of the article there will be an example of validation localization.

Before reading this article, you should have an understanding of how error handling works in Fastify, Express, etc.

Language Detector strategy

And so, first of all, when we talk about localization, the question arises of a strategy for determining the user's language, in the case of a Backend application, we have two most used methods:

Accept-Language HTTP request header - which the browser automatically sends based on the browser's language settings (recommended method)
GEO IP - determining the location and, accordingly, the user's language based on his IP address

We will use the HTTP header Accept-Language, since in my practice this method gives the greatest accuracy in determining the user's language, and is also the easiest to implement.

Implementation

And so, first of all, we need to determine the language from the Accept-Language header, we need to install the Locale package:



# Install with yarn
yarn add locale

# Install with npm
npm install locale --save

And now I propose to create a directory i18n in the project, which will contain a function helper for determining the language, and a little later we will add dictionaries with texts for localization there:



// i18n/index.ts
import locale from 'locale'

// Constant with the languages that we will support
export enum Language {
  DE = 'de',
  EN = 'en',
}
// fallback language
const defaultLang = Language.DE

const supportedLangs = new locale.Locales(Object.values(Language), defaultLang)

Next, let's add the parseAcceptLanguage function, which will determine the language depending on the header:



// i18n/index.ts
export const parseAcceptLanguage = (acceptLanguage: string): Language => {
  const locales = new locale.Locales(acceptLanguage)
  const language = locales.best(supportedLangs).toString() as Language

  return language
}

Now I propose to create the same dictionaries with texts for different languages.
As an example, let's create two dictionaries for the English language EN and for the German language DE.



// i18n/dictionaries/en.ts
export default {
  EMAIL_ALREADY_IN_USE: 'This Email is already in use!',
  USERNAME_ALREADY_IN_USE: 'This username is already in use!',
  LOGIN_ERROR: 'Wrong Username/Email/Password',
  FILE_LIMIT_MB: 'The file in the \'#fieldName#\' field exceeds the file size limit of #mb# MB',
}

// i18n/dictionaries/de.ts
export default {
  EMAIL_ALREADY_IN_USE: 'Diese E-Mail-Adresse wird schon verwendet!',
  USERNAME_ALREADY_IN_USE: 'Dieser Benutzername wird bereits benutzt!',
  LOGIN_ERROR: 'Falscher Benutzername/E-Mail/Passwort',
  FILE_LIMIT_MB: 'Die Datei im Feld \'#fieldName#\' überschreitet die Dateigrößenbeschränkung von #mb# MB',
}

// i18n/index.ts
import ru from './dictionaries/ru'
import en from './dictionaries/en'

export const dictionaries: Record<Language, typeof en> = {
  ru,
  en,
}

You may have noticed that in some keys there are slots like #fieldName# or #mb#, this is done for a reason, but in order to be able to specify additional arguments at the time of throwing an error that will be entered there dynamically.

And so now let's write our own class for the thrown error, which we will later catch and transform into messages with localization.



// errors.ts
type Slots = Record<string, string | number> | null

export class HttpError extends Error {
  status: number
  slots: Slots

  constructor(status: number, message = '', slots: Slots = null) {
    super()

    this.status = status
    this.message = message
    this.slots = slots
  }
}

And now let's put everything together, and get a lightweight and flexible localization mechanism.
And we will collect everything in place at the time of error handling, since Fastify is already able to handle exceptions out of the box, and using the setErrorHandler we can customize it, which will allow us to check if the error is an instance of the HttpError class, then try to check for slots, and send a message to the user.



// server.ts
app.setErrorHandler((error, req, res) => {
  if (typeof req.lang !== 'string') {
    req.lang = parseAcceptLanguage(req.headers['accept-language']!)
  }

  const dictionary = dictionaries[req.lang]
  let message = dictionary[error.message] ?? error.message

  if (error instanceof HttpError) {
    if (error.slots !== null) {
      const slots = Object.keys(error.slots)

      for (const slot of slots) {
        message.replace(`#${slot}#`, slots[slot])
      }
    }

    return res.status(error.status).send({
      status: error.status,
      message,
    })
  }

  res.status(500).send({
    status: 500,
    message,
  })
})

Also don't forget to add the lang field to the FastifyRequest object in your type declaration files.



// types.ts
declare module 'fastify' {
  interface FastifyRequest {
    lang?: Language
  }
}

And that's it!
Now in the business logic layer, we can throw exceptions that will be localized for each specific user:



// someHandler.ts
const emailInDb = await UserModel.exists({ email })
if (emailInDb) {
  throw new HttpError(400, 'EMAIL_ALREADY_IN_USE')
}

// or an example using slots
if (file.size > MBtoBytes(10)) {
  throw new HttpError(400, 'FILE_LIMIT_MB', {
    mb: 10,
    fieldName: 'photo',
  })
}

Validation messages localization

And now let's move on to validation, for example, I will take a fairly popular library Yup.

I know that Yup has built-in mechanisms for localization, but the purpose of this article is to look at validation not as ready-made errors that the library throws out to us, but as a pair of error key -> value + metadata that all libraries adhere to in one way or another, and having understood this, it will not be a problem to make localization based on any library

Here is an example of a schema that is responsible for validation:



// schemas.ts
import { object, string } from 'yup'

const createSchema = object().shape({
  name: string().required(),
  email: string().min(20).required(),
  sessionId: string().required(),
})

And now let's write a function that will turn the scheme into preHandler automatically:



// errors.ts
export const validateYup = schema => async req => {
  try {
    await schema.validate(req.body, {
      abortEarly: false,
    })
  } catch (e) {
    req.lang = parseAcceptLanguage(req.headers['accept-language']!)

    throw new ValidationError(422, { data: translateYupError(e, req.lang) })
  }
}

And now, when defining a route, we will simply write preHandler: validateYup(createSchema).

Next, we will add types of Yup errors to our dictionary, be it required or min, but I also recommend adding a YUP_ prefix for them so that in which case they can be easily separated from other similar errors related to validation:



// i18n/dictionaries/en.ts
export default {
  YUP_MIN: ({ params }) => `Min ${params.min}`,
  YUP_REQUIRED: 'Required text'
}

Don't be surprised that YUP_MIN is a function, in this case it's the easiest way to pass error metadata, in other cases I recommend sticking to the slot syntax described above.

But I think you noticed that the main magic lies in the translateYupError function, that's actually it:



// errors.ts
const translateYupError = (errors, lang) => errors.inner
  .map(error => {
    const key = `YUP_${error.type.toUpperCase()}`
    const message = dictionary[lang][key] ?? error.type // or fallback to error.message

    return {
      message: typeof message === 'function'
        ? message(error)
        : message,
      field: error.path,
    }
  })

And now in the response with a validation error, we will have all the fields localized, since we will get into setErrorHandler where the ValidationError error will be processed.

And the user will see the error in his native language :)

Repository Pattern with Typescript, Node.js and native PostgreSQL driver

aabdullin — Sun, 20 Mar 2022 11:25:43 +0000

Not too old times i worked with databases like MongoDB, PostgreSQL using Mongoose, TypeORM or Knex wrapped to repository, but... In one of the last projects i will need to build high-load, GEO distributed system.
Interesting task 😋

For this type of systems PostgreSQL not best solution, and for a number of reasons like lack of replication out of the box. And we strictly must not have «Vendor lock», and therefore also did not take modern SQL databases like Amazon Aurora. And end of the ends the choice was made in favor Cassandra, for this article where we will talking about low-lever implementation of Repository Pattern it is not important, in your case it can be any unpopular database like HBase for example.

Okay, database Cassandra chosen, but, how we will organize our Data Layer to interact with database?🤨
We don't able to use Knex, it is just not support CQL, and we don't have good alternatives. And i am clearly understand what to use pure CQL not good idea, because it is significantly make harder to support project in the future.

All source code can be found here.

What are the basic features we want to see from our Data Access Layer?

Provide ready to use CRUD operations
Good TypeScript support
Support transactions
Column aliases (in DB "created_at", in code "createdAt")
Hidden columns
Select specific columns
Where (For simplicity, I will show simple implementation without "or" operator support)
Support relations (For simplicity, I will skip this paragraph within the article, but it is easy to add)
Subscriptions on entity events like BeforeInsert, AfterInsert, BeforeDelete, AfterDelete, and etc. (same as relations)
Ability to easy extend API
Migrations (It is not part of this article)

In the absence of good ready-made solutions, an excellent option would be to implement the repository pattern and query builder like helpers.

Requirements:

Node.js 17.5.0+
PostgreSQL 14.2+

NPM packeges:

TypeScript 4.6.2+
PG 8.7.3+
Node PG migrate 6.2.1+

Why PG?
For the clarity of the article to a large circle of developers, the entire explanation will be built by PostgreSQL and PG package.
And in a real project, the database schema will change over time, and in order to be able to perform migrations, we will use Node PG migrate.

Setting up environment

Before we start we need to install our packages, i will use Yarn.

yarn add pg && yarn add -D typescript @types/pg node-pg-migrate

Low-lever helpers to work with PG driver

First before start implementing out Repository we need to create some helper functions to make work with PG package easier.
We will have a queryRow function for situations where we want to get only one row from the database.

export const queryRow = async <T = any>(sql: string, values: any[] | null, tx?: PoolClient): Promise<T> => {
  // Get connection from PG Pool or use passed connection, will be explained below
  const client = await getConnect(tx)

  // I think will be better to separate handling query with passed values 
  if (Array.isArray(values)) {
    try {
      const res = await client.query(sql, values)

      return res.rows[0] as T
    } catch (e) {
      throw e
    } finally {
      // if we not have passed connection, we need close opened connection
      if (!tx) client.release()
    }
  }

  try {
    const res = await client.query(sql)

    return res.rows[0] as T
  } catch (e) {
    throw e
  } finally {
    if (!tx) client.release()
  }
}

And we will have query function to work with the list of data returned by the database.

export const query = async <T = any>(sql: string, values?: any[] | null, tx?: PoolClient) => {
  const client = await getConnect(tx)

  if (Array.isArray(values)) {
    try {
      const res = await client.query(sql, values)

      return res.rows as T[]
    } catch (e) {
      throw e
    } finally {
      if (!tx) client.release()
    }
  }

  try {
    const res = await client.query(sql)

    return res.rows as T[]
  } catch (e) {
    throw e
  } finally {
    if (!tx) client.release()
  }
}

Any functions responsible for working with the database or responsible for generating SQL can be added to the helpers.

For example getConnect, what will look if we don't have passed connection it will get fresh connection from Pool.

export const getConnect = (tx?: PoolClient): Promise<PoolClient> => {
  if (tx) {
    return tx as unknown as Promise<PoolClient>
  }
  // pool it is global connection variable
  // !!! Warning !!!
  // Be very-very carefully when working with global variables
  // And you should not access this variable from business logic
  return pool.connect()
}

Or here is an example of functions for generating SQL code when working with transactions.

export const startTrx = async (pool: Pool) => {
  const tx = await pool.connect()
  await tx.query('BEGIN')
  return tx
}
export const commit = (pool: PoolClient) => pool.query('COMMIT')
export const rollback = (pool: PoolClient) => pool.query('ROLLBACK')

Or functions what will help to determine error type when we dealing with error handling.

export const isUniqueErr = (error: any, table?: string) => {
  if (table) {
    // 23505 it is one of PostgreSQL error codes, what mean it is unique error
    // Read more here: https://www.postgresql.org/docs/14/errcodes-appendix.html
    return error.code === '23505' && error.severity === 'ERROR' && error.table === table
  }

  return error.code === '23505' && error.severity === 'ERROR'
}

And finally

Repository implemetation

Firstly i will implement just create method to show its looks. Now need create interfaces what will cover our operations like Create and Read.

interface Writer<T, C> {
  create(value: Partial<T>, tx?: C): Promise<T>
}

Where T it is a entity/model typing, and C it is database client type.
And after we need define base interface for any database dialect repository.

export type BaseRepository<T, C> = Writer<T, C>

And here we able to create our database repository, in my case i will use PostgreSQL database with PG driver, but if you use other database you need to implement logic using API of your database.

import type { Pool, PoolClient } from 'pg'
import type {
  BaseRepository,
  ColumnData,
} from './types'
import { buildAliasMapper, insertValues } from './queryBuilder'
import { queryRow } from './utils'

export class PGRepository<T> implements BaseRepository<T, PoolClient> {
  readonly table: string
  readonly pool: Pool
  readonly columnAlias: (col: keyof T) => string
  readonly allColumns: string

  constructor({
    pool,
    table,
    mapping,
  }: {
    table: string
    pool: Pool
    // model/entity alias mapping map, will be explained below
    mapping: Record<keyof T, ColumnData>
  }) {
    // About aliasMapper will be explained below
    const aliasMapper = buildAliasMapper<T>(mapping)

    this.pool = pool
    this.table = `"${table}"`
    // About aliasMapper will be explained below
    this.columnAlias = aliasMapper

    // String with all of columns (SQL - '*'), it is will computed on class initialization
    // Example of output: "id" AS "id", "name" AS "name", "email" AS "email", "created_at" AS "createdAt"
    // It is just for optimization
    this.allColumns = Object.entries(mapping).reduce((acc, [key, value]: [string, ColumnData]) => {
      // skip hidden columns
      if (typeof value === 'object' && value.hidden) {
        return acc
      }

      const sql = `${aliasMapper(key as keyof T)} AS "${key}"`

      return acc
        ? acc += `, ${sql}`
        : sql
    }, '')
  }


  async create(value: Partial<T>, tx?: PoolClient): Promise<T> {
    // Here we will transform JavaScript object, to SQL columns string
    const _cols: string[] = []
    const _values: any[] = []

    for (const key of Object.keys(value) as Array<keyof T>) {
      // Extract from alias mapper original database columns
      _cols.push(this.columnAlias(key))
      _values.push(value[key])
    }
    // End of transform

    const cols = _cols.join(', ')
    // insertValues will create string with value bindings, to prevent SQL-injections
    // Example of output: $1, $2, $3
    const values = insertValues(_values)

    const row = await queryRow<T>(
      `INSERT INTO ${this.table} (${cols}) VALUES (${values}) RETURNING ${this.allColumns}`,
      _values,
      tx,
    )

    return row
  }
}

Warning
Don't use arrow functions like this.
Because in future it will break overriding methods with super.create() calls.

create = async (value: Partial<T>, tx?: PoolClient): Promise<T> => {
  // code...
}

Column alias mapper

Above you able to see magic functions const aliasMapper = buildAliasMapper<T>(mapping) and insertValues, I suggest looking at the code of the buildAliasMapper function.

export type ID = string | number
export type ColumnData = string | {
  name: string
  hidden?: boolean
}

export function buildAliasMapper<T extends AnyObject>(obj: Record<keyof T, ColumnData>) {
  // use ES6 Map structure for performance reasons
  // More here: https://www.measurethat.net/Benchmarks/Show/11290/4/map-vs-object-real-world-performance
  const _mapper = new Map<keyof T, string>()

  for (const [key, value] of Object.entries(obj)) {
    // Create mapping 
    // JS representation property name to PostgreSQL column name
    _mapper.set(key, typeof value === 'string'
      ? value
      : value.name)
  }

  // And return function what will get JS key and output PostgreSQL column name
  return (col: keyof T): string => `"${_mapper.get(col)!}"`
}

export const insertValues = (values: any[]) => values.map((_, index) => `$${index + 1}`).join(', ')

Example how buildAliasMapper works:

export interface User {
  id: number
  name: string
  email: string
  hash?: string
  createdAt: string
}

const aliasMapper = buildAliasMapper<User>({
  id: 'id',
  name: 'name',
  email: 'email',
  hash: {
    name: 'password_hash',
    hidden: true,
  },
  createdAt: 'created_at',
})

aliasMapper('createdAt') // output: "created_at" (with double quotes)

I think now you understand why constructor have property mapping: Record<keyof T, ColumnData> and how alias mapping works.

Now, we create the Repository file to specific entity.

import type { Pool, PoolClient } from 'pg'
import { PGRepository, queryRow, ID } from 'repository'

export interface User {
  id: number
  name: string
  email: string
  hash?: string
  createdAt: string
}

export class UserRepository extends PGRepository<User> {
  constructor(pool: Pool) {
    super({
      pool,
      table: 'users',
      mapping: {
        id: 'id',
        name: 'name',
        email: 'email',
        hash: {
          name: 'password_hash',
          hidden: true,
        },
        createdAt: 'created_at',
      },
    })
  }

  async isTodayCreated(id: ID, tx?: PoolClient) {
    const user = await this.findOne(id, {
      select: ['createdAt'],
      tx,
    })

    if (!user) {
      throw new Error(`User with id '${id}' don't exists`)
    }

    const userDate = new Date(user.createdAt).getTime()
    const todayDate = new Date().getTime()
    const dayOffset = 3600 * 1000 * 24

    return userDate + dayOffset > todayDate
  }
}

Connect to database.

import { Pool } from 'pg'
import 'dotenv/config'

const parsePostgresUrl = (url: string) => {
  const sl1 = url.split(':')

  const firstPart = sl1[1].replace('//', '')
  const splittedFirstPart = firstPart.split('@')

  const host = splittedFirstPart[1]
  const userCredentials = splittedFirstPart[0].split(':')
  const user = userCredentials[0]
  const password = userCredentials[1]

  const splittedSecondPart = sl1[2].split('/')

  const port = Number(splittedSecondPart[0])
  const database = splittedSecondPart[1]

  return {
    host,
    user,
    password,
    port,
    database,
  }
}

// Global connections pool variable
// !!! Warning !!!
// Be very-very carefully when working with global variables
// And you should not access this variable from business logic
export let pool: Pool

export const connectPostgres = async () => {
  const config = parsePostgresUrl(process.env.DATABASE_URL!)
  const newPool = new Pool(config)

  await newPool.connect()

  pool = newPool
  return newPool
}

Now let's go use our created repository.

import { connectPostgres } from 'db'
import { UserRepository } from 'modules/product'

(async () => {
    // connecting to database
    const pool = await connectPostgres()

    // initializing the repository
    const userRepository = new UserRepository(pool)

    // call create method from repository
    const user = await userRepository.create({
      name: 'fyapy',
      email: 'fyapy@gmail.com',
      hash: '123',
    });
    console.log(JSON.stringify(user, null, 2))

    if (user) {
      const isCreatedToday = await userRepository.isTodayCreated(user.id);
      console.log(`is user ${user.name} created today? ${isCreatedToday}`)
    }
})()

Now let's create interfaces for the rest of the CRUD methods.

import type { PoolClient } from 'pg'

export type AnyObject = Record<string, any>
export type ColumnData = string | {
  name: string
  hidden?: boolean
}

export type ID = string | number

interface Writer<T, C> {
  create(value: Partial<T>, tx?: C): Promise<T>
  createMany(values: Partial<T>[], tx?: C): Promise<T[]>
  update(id: ID, newValue: Partial<T>, tx?: C): Promise<T>
  delete(id: ID, tx?: C): Promise<boolean>
}

export interface FindOptions<T, C> {
  select?: Array<keyof T>
  tx?: C
}

interface Reader<T, C> {
  find(value: Partial<T>, options?: FindOptions<T, C>): Promise<T[]>
  findOne(id: ID | Partial<T>, options?: FindOptions<T, C>): Promise<T>
  exist(id: ID | Partial<T>, tx?: PoolClient): Promise<boolean>
}

export type BaseRepository<T, C> = Writer<T, C> & Reader<T, C>

Now, in accordance with the interface, we will write the implementation of the methods.

import { Pool, PoolClient } from 'pg'
import { buildAliasMapper, insertValues } from './queryBuilder'
import {
  BaseRepository,
  FindOptions,
  ID,
  ColumnData,
} from './types'
import { query, queryRow } from './utils'

export class PGRepository<T> implements BaseRepository<T, PoolClient> {
  readonly table: string
  readonly primaryKey: string
  readonly pool: Pool
  readonly columnAlias: (col: keyof T) => string
  readonly cols: (...args: Array<keyof T>) => string
  readonly allColumns: string
  readonly where: (values: Partial<T>, initialIndex?: number) => string

  constructor({
    pool,
    table,
    mapping,
    // variable for storing id/primaryKey, for situations when out 'id' columns have name like 'postId'.
    // by default we think what primaryKey is 'id'
    primaryKey = 'id',
  }: {
    table: string
    pool: Pool
    primaryKey?: string
    mapping: Record<keyof T, ColumnData>
  }) {
    const aliasMapper = buildAliasMapper<T>(mapping)

    this.pool = pool
    this.table = `"${table}"`
    this.columnAlias = aliasMapper
    this.primaryKey = primaryKey

    // select SQL-generator for only specific columns
    // example payload: ['createdAt']
    // output: '"created_at" as "createdAt"'
    this.cols = (...args: Array<keyof T>) => args.map(key => `${aliasMapper(key)} AS "${key}"`).join(', ')
    // Almost the same as this.cols, only predefined and for all columns except hidden columns
    this.allColumns = Object.entries(mapping).reduce((acc, [key, value]: [string, ColumnData]) => {
      if (typeof value === 'object' && value.hidden) {
        return acc
      }

      const sql = `${aliasMapper(key as keyof T)} AS "${key}"`

      return acc
        ? acc += `, ${sql}`
        : sql
    }, '')
    // SQL-generator for WHERE clause
    this.where = (values: Partial<T>, initialIndex = 0) => {
      const sql = Object.keys(values).reduce((acc, key, index) => {
        const condition = `${aliasMapper(key as keyof T)} = $${index + initialIndex + 1}`

        return acc === ''
          ? `${acc} ${condition}`
          : `${acc}AND ${condition}`
      }, '')

      return `WHERE ${sql}`
    }
  }


  async create(value: Partial<T>, tx?: PoolClient): Promise<T> {
    const _cols: string[] = []
    const _values: any[] = []

    for (const key of Object.keys(value) as Array<keyof T>) {
      _cols.push(this.columnAlias(key))
      _values.push(value[key])
    }

    const cols = _cols.join(', ')
    const values = insertValues(_values)

    const row = await queryRow<T>(
      `INSERT INTO ${this.table} (${cols}) VALUES (${values}) RETURNING ${this.allColumns}`,
      _values,
      tx,
    )

    return row
  }

  async createMany(values: Partial<T>[], tx?: PoolClient): Promise<T[]> {
    const _cols: string[] = []
    const _values: any[][] = []

    for (const value of values) {
      const keys = Object.keys(value) as Array<keyof T>

      for (const key of keys) {
        if (_cols.length !== keys.length) _cols.push(this.columnAlias(key))

        _values.push(value[key] as any)
      }
    }

    const cols = _cols.join(', ')
    const inlinedValues = values
      .map((_, index) => `(${_cols.map((_, cIndex) => {
        const offset = index !== 0
          ? _cols.length * index
          : 0

        return `$${cIndex + 1 + offset}`
      })})`)
      .join(', ')

    const rows = await query<T>(`
      INSERT INTO ${this.table} (${cols})
      VALUES ${inlinedValues}
      RETURNING ${this.allColumns}
    `, _values, tx)

    return rows
  }

  update(id: ID, newValue: Partial<T>, tx?: PoolClient): Promise<T> {
    const sqlSet = Object.keys(newValue).reduce((acc, key, index) => {
      const sql = `${this.columnAlias(key as keyof T)} = $${index + 2}`

      return acc !== ''
        ? `${acc}, ${sql}`
        : sql
    }, '')

    return queryRow<T>(
      `UPDATE ${this.table} SET ${sqlSet} WHERE "${this.primaryKey}" = $1 RETURNING ${this.allColumns}`,
      [id, ...Object.values(newValue)],
      tx,
    )
  }

  delete(id: ID, tx?: PoolClient): Promise<boolean> {
    return queryRow<boolean>(
      `DELETE FROM ${this.table} WHERE "${this.primaryKey}" = $1`,
      [id],
      tx,
    )
  }

  async find(value: Partial<T>, options: FindOptions<T, PoolClient> = {}): Promise<T[]> {
    const cols = options.select
      ? this.cols(...options.select)
      : this.allColumns

    const sql = `SELECT ${cols} FROM ${this.table} ${this.where(value)}`

    const res = await query<T>(sql, Object.values(value), options.tx)

    return res
  }

  async findOne(id: ID | Partial<T>, options: FindOptions<T, PoolClient> = {}): Promise<T> {
    const isPrimitive = typeof id !== 'object'
    const cols = options.select
      ? this.cols(...options.select)
      : this.allColumns
    const values = isPrimitive
      ? [id]
      : Object.values(id)

    let sql = `SELECT ${cols} FROM ${this.table}`

    if (isPrimitive) {
      sql += ` WHERE "${this.primaryKey}" = $1`
    } else {
      sql += ` ${this.where(id)}`
    }

    const res = await queryRow<T>(sql, values, options.tx)

    return res
  }

  async exist(id: ID | Partial<T>, tx?: PoolClient): Promise<boolean> {
    let sql = `SELECT COUNT(*)::integer as count FROM ${this.table}`
    const isPrimitive = typeof id !== 'object'
    const values = isPrimitive
      ? [id]
      : Object.values(id)

    if (isPrimitive) {
      sql += ` WHERE "${this.primaryKey}" = $1`
    } else {
      sql += ` ${this.where(id)}`
    }

    sql += ' LIMIT 1'

    const res = await queryRow<{ count: number }>(sql, values, tx)

    return res.count !== 0
  }
}

Usage in real-world project

I suggest to start explain how it is work in real project from main.ts file.
For routing I like to use fastify.
But for example we will use architecture with repositories > handlers layers.
For real project you need to use repositories > services > handlers layers for easier code maintainability in future. All repository calls need to be proxied by services, no direct calls repositories in handlers must not be.

import type { Pool } from 'pg'
import fastify from 'fastify'
import { connectPostgres } from 'db'
import * as users from 'users'

// DI context analog, here repositories dependencies
// In this example I will skip services layer
// but repositories need to be passed to services
// and services will need to be passed to handlers
export interface Repositories {
  pool: Pool
  userRepository: users.UserRepository
}

const main = async () => {
  const app = fastify({
    trustProxy: true,
  })
  const pool = await connectPostgres()


  const repositories: Repositories = {
    pool,
    userRepository: new users.UserRepository(pool),
  }

  // In real project here will be passed services
  app.register(users.setupRoutes(repositories), {
    prefix: '/users',
  })


  try {
    const url = await app.listen(process.env.PORT || 8080, '0.0.0.0')

    console.log(`Server started: ${url}`)
  } catch (error) {
    console.error('Server starting error:\n', error)
  }
}

main()

Let's create Controller/Handler, Fastify handler in my case.
I will skip of UserService Realization, in is will just inject UserRepository, and proxy call [method name].
And validation will be skipped.

import type { FastifyPluginCallback } from 'fastify'
import type { Repositories } from 'types'
import { commit, isUniqueErr, rollback, startTrx } from 'repository'

export const setupRoutes = ({
  pool,
  userRepository,
}: Repositories): FastifyPluginCallback => (fastify, otps, done) => {
  // select all columns
  fastify.get<{
    Params: { id: string }
  }>('/:id/all', async ({ params }) => {
    const user = await userRepository.findOne(params.id)

    return {
      user: user ?? null,
    }
  })
  // select certain columns
  fastify.get<{
    Params: { id: string }
  }>('/:id', async ({ params }) => {
    const user = await userRepository.findOne(params.id, {
      select: ['id', 'name', 'email'],
    })

    return {
      user: user ?? null,
    }
  })

  fastify.post<{
    Body: {
      name: string
      email: string
      password: string
    }
  }>('/', async ({ body }, res) => {
    const tx = await startTrx(pool)
    try {
      const user = await userRepository.create({
        name: body.name,
        email: body.email,
        hash: body.password,
      }, tx)

      await commit(tx)

      res.status(201)
      return {
        user: user ?? null,
      }
    } catch (e) {
      await rollback(tx)

      if (isUniqueErr(e)) {
        res.status(400)
        return {
          message: 'User aleady exist!',
        }
      }

      throw e
    } finally {
      // don't forget to close connection
      tx.release()
    }
  })

  done()
}

Source code

All source code can be found here.
Also for fans of functional programming, which I am, I prepared my own version in folders/files with the prefix fp.

Conclusion

Advice from my side

Strongly recommend for better maintainability, move the base code of the repository into a separate NPM package. Especially if you have several back-end applications or you have a microservice architecture. Because after adding feature, finding and fixing a bug, you will need make changes to all projects, with NPM package you just need to update version of package.
I skipped many features like where or support, limit, subscriptions on entity events like BeforeInsert, AfterInsert, BeforeDelete, AfterDelete, and etc.
Write tests!!! I seriously, because Data Access Layer it is critical thing, you need to be sure what all works as expected after make changes in codebase.
And you able to implement more code optimizations for functions like this.cols or this.where and others, but keep a balance between optimizations and code readability.

In this article I explained how to implement Repository Pattern with low-level database driver.

But I strongly ask you to make sure before using this solution in production in such things as:

You don't have good open source ORM/QueryBuilder/Library alternatives for your database.
You have Experienced Developers who fully understand what they are doing and why.

But what if you can't answer yes to these questions?
I think you have taken on a task that is too difficult for you :)

CSS solutions Battle: Compile time CSS-in-JS vs CSS-in-JS vs CSS Modules vs SASS

aabdullin — Tue, 11 Jan 2022 09:33:38 +0000

In modern frontend development, especially in react, to a lesser extent in vue, these are many different ways to write CSS for our components.

In this article i will not make side-by-side comparison, i will highlight both interesting features and problems of specific solutions that I am guided by in a situation where i am in the position of a person who determines the "CSS architecture" of a project.

SASS (CSS, CSS-preprocessors)

SASS (further just CSS) is easy to learn but very hard to maintain. What is it mean?

Main problem of pure CSS, he don't solve problem of styles isolation per component. And all your styles will leak into other components, and this will create a lot of problems in large projects.
Yeah, this problem is as old as the world, and we have different ways to solve this problem:

BEM methodology
BEM paired with Atomic Design
Other solutions like Atomic CSS, SMACSS, and etc.

But all of this solution it is only a metodologies, this does not remove the need for the developer to think, and this means that we still have such a problem as a banal human inattention.

And second problem, because all of our styles is just abstract global CSS we don't have a TypeScript support to check that our style really exist. And the resulting problem we don't have good IDE intelligence (especially if we have have additionalData that import of some files that contain SASS vars and mixins, in Webpack/Vite config).
Yeah, we have solutions like:

SCSS IntelliSense to have autocompletion for our SASS/SCSS variables, mixins
SCSS Everywhere to have autocompletion for our classes in JSX/TSX files.

But these are just plugins for the IDE and will not be possible to integrate them into your CI/CD pipeline to check if we are using non-existing CSS classes.

CSS Modules

And in this point to solve all problems of having global CSS enters the stage CSS Modules.

Basically CSS Modules = CSS in JS objects.
CSS Modules it is the same as the CSS code structure and all. The main difference is calling methods is too different.

CSS Modules provide some JS Modules representation what contain links to CSS classes. And our classNames will be looks like <div className={style.css_class} />, and our class selector under the hood will be transform to something like [name]__[local]__[hash:base64:5] (more details here), that will solve CSS classes isolation problem.

But, what about TypeScript support?
And here we have some solutions:

TypeScript plugin CSS Modules, it is plugin that provide to TypeScript language service information about class selectors that contain imported CSS Module file. But for VSCode we need setup TypeScript LS to use workspace version. For more information go here or here.

It is solve problem using non-existed class names for TS/TSX files, but that if we use Vue and .vue files?
Here we have problem, because volar for example does not provide support of TypeScript plugin CSS Modules, for more information go here.
And there enters the stage:

Vite plugin sass dts that will generate TypeScript declarations for our CSS Modules.
Or for Webpack CSS Modules TypeScript loader

And we have type checking for Vue project🥳

And what about IDE autocompletion for SCSS/SASS vars, mixins?
Everything is the same here, only SCSS IntelliSense

But CSS not feature rich language. How we can add even more flexibility and improve Development Experience of writing styles?

CSS-in-JS

Also since we write js, we able to write helper functions for our css fragments, what will be fully support TypeScript, which means significantly reduces the number of errors and get IDE intellicence.

For basic example it is a media querys, and js variables for theming.

export const screenSizes = {
  mobile: 767,
  tablet: 1023,
  computer: 1440,
  desktop: 1920,
} as const

export const makeMedia = (from: null | number, to?: null | number) => `@media screen${
  from
    ? ` and (min-width: ${from}px)`
    : ''}${
  to
    ? ` and (max-width: ${to - 1}px)`
    : ''}`

export const media = {
  mobile: makeMedia(null, screenSizes.mobile),
  tablet: makeMedia(null, screenSizes.tablet),
  computer: makeMedia(null, screenSizes.computer),
  desktop: makeMedia(null, screenSizes.desktop),
  largescreen: makeMedia(screenSizes.desktop),
  tabletOnly: makeMedia(screenSizes.mobile, screenSizes.tablet),
  computerOnly: makeMedia(screenSizes.tablet, screenSizes.computer),
  desktopOnly: makeMedia(screenSizes.computer, screenSizes.desktop),
  aboveMobile: makeMedia(screenSizes.mobile),
  aboveTablet: makeMedia(screenSizes.tablet),
  aboveComputer: makeMedia(screenSizes.computer),
  aboveDesktop: makeMedia(screenSizes.desktop),
}

export const color = {
  primary: '#FF6B38',
  primaryOpacity27: 'rgba(255, 107, 56, .27)',
  primaryOpacity35: 'rgba(255, 107, 56, .35)',
  primaryLighten: '#F5F5F5',
  primaryLighten2: '#FDA38A',
  blackOpacity80: 'rgba(0, 0, 0, .8)',
  blackOpacity60: 'rgba(0, 0, 0, .6)',
  blackLight: '#161616',
  blackLightOpacity42: 'rgba(22, 22, 22, .42)',

  backgroundGray: '#161616',
  backgroundGrayLight: '#969696',
} as const

Usage example:

// Component style.ts file
import styled from 'styled-components'
import { media, color } from 'ui/theme'

export const StyledWrapper = styled.div`
    position: relative;
    z-index: 1;

    background-color: ${color.white};
    border-radius: 36px;
    box-shadow: 0 10px 20px ${color.shadowPrimary2};
`

export const StyledTopGutter = styled.div`
    padding: 46px 46px 24px;

    display: flex;
    flex-flow: column wrap;

    ${media.mobile} {
        padding: 24px;
    }
`

But it is not all, because our css code in fact is JavaScript we able to see for user-agent for determine user browser and mixin some styles for some specific browsers.

import { css } from 'styled-components'

// Works only on the client-side
// For SSR we need have some Context to Provide User-Agent from request context to React application context
const USER_AGENT = window.navigator.userAgent;

// More details about browser detect regex
// here - https://github.com/ua-parser/uap-core/blob/master/regexes.yaml
export const checkIsIE10OrOlder = /MSIE /g.test(USER_AGENT);
export const checkIsIE11 = /Trident\//g.test(USER_AGENT);
export const checkIsEdge = /Edge\//g.test(USER_AGENT);
export const checkIsFireFox = /Firefox\//gi.test(USER_AGENT);
export const checkIsChrome = /Chrome\//gi.test(USER_AGENT);
export const checkIsSafari = /Safari\//gi.test(USER_AGENT);
export const checkIsYandex = /YaBrowser\//gi.test(USER_AGENT);

export const styleIE11Browser = (...args) => checkIsIE11 ? css(...args) : null;
export const styleEdgeBrowser = (...args) => checkIsEdge ? css(...args) : null;
export const styleMicrosoftBrowsers = (...args) => checkIsIE11 || checkIsEdge || checkIsIE10OrOlder ? css(...args) : null;
export const styleIsNotMicrosoftBrowsers = (...args) => !checkIsIE11 && !checkIsIE10OrOlder ? css(...args) : null;
export const styleFireFoxBrowser = (...args) => checkIsFireFox ? css(...args) : null;
export const styleSafariBrowser = (...args) => checkIsSafari ? css(...args) : null;
export const styleYandexBrowser = (...args) => checkIsYandex ? css(...args) : null;

export const browser = {
    ie: styleMicrosoftBrowsers,
    ie11: styleIE11Browser,
    edge: styleEdgeBrowser,
    notIE: styleIsNotMicrosoftBrowsers,
    firefox: styleFireFoxBrowser,
    moz: styleFireFoxBrowser,
    safari: styleSafariBrowser,
    yandex: styleYandexBrowser,
};

Or we able use css selectors to determine user browser.

// Works with both client-side and server-side rendering
export const isIECssDetect = (...args) => css`@media all and (-ms-high-contrast:none) {${css(...args)}}`;
export const isFireFoxCssDetect = (...args) => css`@-moz-document url-prefix() {${css(...args)}}`;

export const browser = {
    css: {
        ie: isIECssDetect,
        firefox: isFireFoxCssDetect,
        moz: isFireFoxCssDetect,
    },
};

Usage example:

import styled from 'styled-components'
import { browser } from 'ui/theme'

export const StyledBackground = styled.img`
    position: absolute;
    object-fit: contain;
    object-position: right;
    top: 0;
    left: 0;
    z-index: -2;
    width: 100%;
    height: 100%;

    ${browser.ie`
        width: auto;
        right: 0;
        left: auto;
    `}
`;

And CSS-in-JS very helpful for creating some base components, for example we working with custom design, in too many situations for align some element we need just element with 2 CSS props like display: flex; justify-content: center.
And in this very helpful will be ability to create small helper components like:

import styled, { css } from 'styled-components'

interface LayoutProps {
    flow: 'column' | 'row' | 'column-reverse'
    wrap?: 'wrap' | 'nowrap'
    padding?: string
    margin?: string
    justify?: 'center' | 'flex-start' | 'flex-end' | 'space-between' | 'space-around' | 'stretch'
    align?: 'center' | 'flex-start' | 'flex-end' | 'space-between' | 'space-around' | 'stretch'
    width?: string
    height?: string
    shrink?: string
    'data-name'?: string
    grow?: string
}

export const Layout = styled.div<LayoutProps>`
  display: flex;
  flex-direction: ${p => p.flow};
  flex-wrap: ${p => p.wrap};
  padding: ${p => `${p.padding}`};
  margin: ${p => `${p.margin}`};
  ${p => p.width && css`
    width: ${p.width}
  `};
  ${p => p.height && css`
    height: ${p.height};
  `};
  ${p => p.justify && css`
    justify-content: ${p.justify}
  `};
  ${p => p.align && css`
    align-items: ${p.align}
  `};

  ${p => p.shrink && css`
    & > * + * {
      flex-shrink: ${p.shrink};
    }
  `};
  ${p => p.grow && css`
    flex-grow: ${p.grow};
  `};
`

Layout.defaultProps = {
    wrap: 'nowrap',
    padding: '0',
    margin: '0',
    justify: undefined,
    align: undefined,
    width: '',
    height: '',
    shrink: undefined,
    'data-name': 'layout',
    grow: '',
}

And use it:

import { Layout } from 'ui/atoms'
import { SeparateTitle } from 'ui/molecules'
import { StyledWrapper } from './style'

const OrderResponseForm: FC<Props> = () => {
    // Some code

    return (
        <Layout flow="column" wrap="wrap" margin="40px 0 0">
            <SeparateTitle line={false}>
                {i18n.t('ORDER_DETAILS_FORM_TITLE')}
            </SeparateTitle>
            <StyledWrapper
                flow="row"
                padding="24px 30px 20px 24px"
            >
                {`* Some more JSX *`}
            </StyledWrapper>
        </Layout>
    )
}

In style.ts you have ability to extend Layout component
With saving props Type checking

export const StyledWrapper = styled(Layout)`
    border-radius: 36px;
    box-shadow: 0 4px 20px ${color.shadowBlack2};

    ${media.tablet} {
        padding: 24px;
        margin-bottom: 8px;
    }
`

Or we can also create reusable component for text:

import styled, { css } from 'styled-components'
import {
    color as colors,
    selectWeight,
    WeightType,
} from 'ui/theme'

interface TextProps {
    align?: string
    size?: string
    color?: keyof typeof colors
    weight?: WeightType
    lineHeight?: string
    whiteSpace?: 'pre-wrap' | 'initial' | 'pre' | 'nowrap' | 'pre-line' | 'normal'
    letterSpacing?: string
    transform?: string
    'data-name'?: string
    decoration?: string
}

export const Text = styled.span<TextProps>`
    line-height: ${p => p.lineHeight};
    font-size: ${({ size }) => size};
    color: ${({ color = 'text' }) => colors[color] ? colors[color] : color};
    letter-spacing: ${({ letterSpacing }) => letterSpacing};
    text-align: ${({ align }) => align};
    text-decoration: ${({ decoration }) => decoration};
    font-weight: ${({ weight = 'normal' }) => selectWeight(weight).weight};
    white-space: ${p => p.whiteSpace};

    ${({ transform }) => transform && css`
        text-transform: ${transform};
    `}
`

Text.defaultProps = {
    align: 'initial',
    size: '14px',
    color: 'text',
    weight: 'normal',
    lineHeight: 'normal',
    whiteSpace: 'initial',
    letterSpacing: 'initial',
    decoration: 'initial',
    'data-name': 'text',
}

CSS-in-JS raises to a new level Developer Experience (DX), because solves the problem of isolation of styles, and bring some cool features like defining attrs not in our JSX, but in the style declaration variable, it is looks like:

const StyledPrecheckInner = styled(Layout).attrs<Props>(() => ({
    flow: 'column',
    width: '100%',
}))`
    max-width: 378px;
    margin: 0 auto;

    > ${Text} {
        margin: 8px 0;
    }
`

Or a more specific case:

export const StyledIndicator = styled.button.attrs<Props>(({
    isHasError,
    isLoading,
    isOpen,
    ...props
}) => ({
    ...props,
    type: 'button',
    children: isLoading
        ? (
            <Loader
                width="16px"
                height="16px"
                margin="0"
                inline
            />
        )
        : (
            <IconArrow
                data-dir={props.isOpen ? 'up' : 'down'}
                stroke={isHasError ? 'textDangerExtra' : 'primary'}
                width="16"
                height="16"
            />
        ),
}))`
    // CSS code
`;

And it is support dynamic props (More examples above):

const StyledNotch = styled.div<Props>`
    height: ${p => p.isShowPlaceholder
        ? p.height
        : 'initial'}
`

But... JS will give to us much more power, and we able to make some crazy runtime css transformations:

// A simplified example, but here you may have much more logic inside, you are limited only by JavaScript
const StyledSeparator = styled.div<Props>`
    // Some CSS

    // A function call that returns an object, or it could be a switch case
    ${({ rule }) => ({
        day: css`
            margin: 24px 0 16px;
        `,
        year: css`
            position: relative;

            width: calc(100% - 48px);
            margin: 32px 24px 16px;
        `,
    })[rule]}
`

And it is all support typescript...

And in SRR case css in js give to us ability to generate "critical css" whick will generate css what only need for especially this page, to optimizing time what browser take on parsing our css:

// Some server setup code

server.get("/*", async (req, res) => {
  const sheet = new ServerStyleSheet();

  try {
    const app = renderToString(
      <StyleSheetManager sheet={sheet.instance}>
        <App />
      </StyleSheetManager>
    );

    const styledComponentTags = sheet.getStyleTags();

    const html = renderToStaticMarkup(
      <HtmlTemplate app={app} styledComponentTags={styledComponentTags} />
    );

    res.status(status).send(html);
  } catch (error) {
    logger.error(error);
    res.status(500).send(<ErrorPage />);
  } finally {
    sheet.seal();
  }
});

And it is not that hard to make friends with our bundler, no matter what we use webpack, vite, or rollup and etc.
You just need some JavaScript processor like Babel, ESBuild, SWC, and etc.

It sounds really great!

But firstly, CSS-in-JS styles generated only if the component is on screen, while Sass or other CSS based solutions is included in separated css (do not consider styles in style tags), it is give to us ability to cache our css files.

And secondly... generation of css by the forces of JavaScript operation is not free, and this will eat our runtime 😢
Everything is not as bad as it sounds, styled-components for example very fast even for large projects, if you use styled-components for just static isolated styles for some element, but when use start to use too many dynamic props in reusable components it is will very fast and very noticeable slow down your application 😔

And they go on the stage Compile time CSS in JS solutions (or Zero runtime CSS in JS)

Compile time CSS-in-JS (Zero runtime CSS-in-JS)

I would single out a few players:

Linaria (Most popular, support React and Svelte)
Vanilla extract (very interesting, support more bundlers than Linaria)
Compiled (Compile time CSS-in-JS solution from Atlassian)

I thing from name "Compile time" you understand, what it is way to write CSS-in-JS, but without or very small runtime cost.

Linaria for example, have similar to styled components features, like components with dynamic props:

import { styled } from '@linaria/react';

const StyledTitle = styled.h1<TitleProps>`
    line-height: ${p => p.lineHeight};
    font-size: ${({ size }) => size};
    color: ${({ color = 'text' }) => colors[color] ? colors[color] : color};
    letter-spacing: ${({ letterSpacing }) => letterSpacing};
    text-align: ${({ align }) => align};
`;

Main difference that under the hood Linaria create a wrapper component that for dynamic styles will use css-variables, it is dramatically speed up dynamic props.
More details here or Linaria docs provide guide about how it implement manually

But compilation step bring to us some limitations, like css'' fn so crazy dynamic, it is just like css scoped class.
And your style utils output is more like classes composition:

import { css, cx } from '@linaria/core';

export const selectButtonTheme = (theme: ButtonTheme, ...otherClasses: Array<string | undefined>) => {
  const cssBase = css`
    width: 170px;
    padding: 10px 0;
    display: flex;
  `

  const classes = [cssBase, ...otherClasses]

  switch (theme) {
    case 'outline':
      classes.push(css`
        border: 2px solid ${colors.primary};
      `)
      break
    case 'solid-gradient':
      classes.push(css`
        background: linear-gradient(0deg, ${colors.yellow} -80%, ${colors.orange1} 104.11%);
      `)
      break
  }

  return cx(...classes)
}

And since you write JavaScript you also can use utility functions, but compilation step bring to us some limitations. For example i like to use absolute imports, but Linaria sometimes don't able to import my 'ui/theme' file, and to solve this problem we need to use babel-plugin-import-resolver.

{
  "presets": ["@linaria"],
  "plugins": [
    ["module-resolver", {
      "root": ["./"],
      "alias": {
        "ui/theme": "./src/ui/theme",
        "ui/keyframes": "./src/ui/keyframes"
      }
    }]
  ]
}

But it is not all, before you will start to use Linaria, you need to configure your bundler 😄

Somehow at the interview I was asked "what i think about difficulty of configuring Webpack for Linaria, at that moment I realized, what to find a solution to set up Linaria with SSR is not simple task", but I will show you the final result for example Razzle config:

const path = require('path')
const LoadableWebpackPlugin = require('@loadable/webpack-plugin')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')

module.exports = {
  modifyWebpackConfig: ({ env: { target, dev }, webpackConfig: config }) => {
    if (target === 'web') {
      // Loadable
      config.plugins.push(
        new LoadableWebpackPlugin({
          outputAsset: false,
          writeToDisk: {
            filename: path.resolve(__dirname, 'build'),
          },
        })
      )

      // Linaria
      config.module.rules.push({
        loader: '@linaria/webpack-loader',
        options: {
          sourceMap: process.env.NODE_ENV !== 'production',
          url: false,
        },
      })

      if (!dev) {
        config.plugins.push(
          new MiniCssExtractPlugin({
            filename: 'styles.css',
          })
        )
      }

      config.module.rules = config.module.rules.map(rule => {
        if (rule.test && !Array.isArray(rule.test) && rule.test.test('some.css')) {
          rule.use = rule.use.map(use => {
            if (use.ident === 'razzle-css-loader') {
              return {
                ...use,
                options: {
                  ...use.options,
                  url: false,
                },
              }
            }
            return use
          })
        }
    }

    return config
  },
  plugins: [
    {
      name: 'typescript',
      options: {
        useBabel: true,
      },
    },
  ],
  experimental: {
    newBabel: true,
    newExternals: true,
    reactRefresh: false,
  },
}

NextJS configuration more info here.

And you need to remember what you are tied to Babel, and even you use Vite as a bundler, you will need Babel (Vite by default use only ESBuild, to speed up bundle time). And NextJS 12 also refused Babel. It is not problem, but it is slow down build time, and, accordingly, the development experience deteriorates.

And after setup React with SSR (Razzle) as the project grows i was have some problems with HMR, when my Webpack makes Full-refresh of page, instead of just hot update styles in background. And this behavior was not permanent.

And Linaria have not so good IDE support when compared with the styled-components.

But I admire that people try to create even solutions like a Atomic Compile time CSS-in-JS, this is an amazing engineering idea 🤯

Conclusion

What approach to choose for writing application styles?

I think all depends on what kind of application we are writing.
Each approaches has its own prop and cons.
My throughs on this:

CSS-in-JS - choose when you don't have perfomance critical application with custom design. For example we have many "backoffice" applications what company employees use internally. CSS-in-JS in this case will give elegant and flexible API that will maximaze code readability, boost Developer Productivity and Devepment Experience.
CSS Modules - choose when you have some perfomance critical application. For example you are developing a personal account of a bank client which is used by millions of users. Or just E-Commerce 😝

Repository Pattern with Typescript and Node.js

aabdullin — Mon, 25 Oct 2021 05:14:37 +0000

If you working with Node.js you probably interact with the database (MongoDB, PostgreSQL, and etc) via ORM.

But sometimes typical ORM does not cover our needs.

For example, when we need to write nested queries with aggregation in PostgreSQL. Or when the performance of a generated query using ORM does not suit us.
And here typically we start writing direct queries to database..

But what about solutions what will get to us good developer productivity like ORM, and will get a flexible API to interact with the database like pure SQL code.

If you have encountered such situations, then this post is for you!

Repository Pattern

In most cases we need some abstraction what will give to us typical operations like CRUD (Create, Read, Update and Delete Operations). And Repository pattern will give to us this abstract Data Layer to interact with any database.

Requirements:

Node.js
TypeScript 4.4.0+
PostgreSQL 13.4+
Knex 0.95.11+
VSCode

Why Knex?
For boost our developer productivity and get ability to create predictable queries we will use query builder, it is a cross between ORM and pure SQL queries.
And in real project over time out database schema will change, and Knex provide excellent migrations API with TypeScript support.

Setting up environment

Before we start we need to install our packages, i will use Yarn.

yarn add knex pg && yarn add -D typescript

Implemetation

Firstly i will implement just find method to show its looks. Now need create interfaces what will cover our operations like Create and Read.

interface Reader<T> {
  find(item: Partial<T>): Promise<T[]>
  findOne(id: string | Partial<T>): Promise<T>
}

And after we need define base interface for any database dialect repository.

type BaseRepository<T> = Reader<T>

And here we able to create our database repository, in my case i will use SQL database with Knex in query builder role, but if you want to use MongoDB, just replace Knex with MondoDB package.

import type { Knex } from 'knex'

interface Reader<T> {
  find(item: Partial<T>): Promise<T[]>
}

type BaseRepository<T> = Reader<T>

export abstract class KnexRepository<T> implements BaseRepository<T> {
  constructor(
    public readonly knex: Knex,
    public readonly tableName: string,
  ) {}

  // Shortcut for Query Builder call
  public get qb(): Knex.QueryBuilder {
    return this.knex(this.tableName)
  }

  find(item: Partial<T>): Promise<T[]> {
    return this.qb
      .where(item)
      .select()
  }
}

Warning
Don't use arrow functions like this.
Because in future it will break overriding methods with super.find() calls.

find = async (item: Partial<T>): Promise<T> => {
  // code...
}

Now, we create the Repository file to specific entity.

import { BaseRepository } from 'utils/repository'

export interface Product {
  id: string
  name: string
  count: number
  price: number
}

// now, we have all code implementation from BaseRepository
export class ProductRepository extends KnexRepository<Product> {
  // here, we can create all specific stuffs of Product Repository
  isOutOfStock(id: string): Promise<boolean> {
    const product = this.qb.where(id).first('count')

    return product?.count <= 0
  }
}

Now let's go use our created repository.

import knex from 'knex'
import config from 'knex.config'
import { Product, ProductRepository } from 'modules/product'

const connect = async () => {
  const connection = knex(config)
  // Waiting for a connection to be established
  await connection.raw('SELECT 1')

  return connection
}

(async () => {
    // connecting to database
    const db = await connect()

    // initializing the repository
    const repository = new ProductRepository(db, 'products')

    // call find method from repository
    const product = await repository.find({
      name: 'laptop',
    });
    console.log(`product ${product}`)

    if (product) {
      const isOutOfStock = await repository.isOutOfStock(product.id);
      console.log(`is ${product.name}'s out of stock ${isOutOfStock}`)
    }
})()

Let's implement the remaining methods of CRUD.

import type { Knex } from 'knex'

interface Writer<T> {
  create(item: Omit<T, 'id'>): Promise<T>
  createMany(item: Omit<T, 'id'>[]): Promise<T[]>
  update(id: string, item: Partial<T>): Promise<boolean>
  delete(id: string): Promise<boolean>
}
interface Reader<T> {
  find(item: Partial<T>): Promise<T[]>
  findOne(id: string | Partial<T>): Promise<T>
  exist(id: string | Partial<T>): Promise<boolean>
}

type BaseRepository<T> = Writer<T> & Reader<T>

export abstract class KnexRepository<T> implements BaseRepository<T> {
  constructor(
    public readonly knex: Knex,
    public readonly tableName: string,
  ) {}

  // Shortcut for Query Builder call
  public get qb(): Knex.QueryBuilder {
    return this.knex(this.tableName)
  }


  async create(item: Omit<T, 'id'>): Promise<T> {
    const [output] = await this.qb.insert<T>(item).returning('*')

    return output as Promise<T>
  }
  createMany(items: T[]): Promise<T[]> {
    return this.qb.insert<T>(items) as Promise<T[]>
  }

  update(id: string, item: Partial<T>): Promise<boolean> {
    return this.qb
      .where('id', id)
      .update(item)
  }

  delete(id: string): Promise<boolean> {
    return this.qb
      .where('id', id)
      .del()
  }

  find(item: Partial<T>): Promise<T[]> {
    return this.qb
      .where(item)
      .select()
  }

  findOne(id: string | Partial<T>): Promise<T> {
    return typeof id === 'string'
      ? this.qb.where('id', id).first()
      : this.qb.where(id).first()
  }

  async exist(id: string | Partial<T>) {
    const query = this.qb.select<[{ count: number }]>(this.knex.raw('COUNT(*)::integer as count'))

    if (typeof id !== 'string') {
      query.where(id)
    } else {
      query.where('id', id)
    }

    const exist = await query.first()

    return exist!.count !== 0
  }
}

Now, we just call that repository from our code.

import knex from 'knex'
import config from 'knex.config'
import { Product, ProductRepository } from 'modules/product'

const connect = // See implementation above...

(async () => {
    // connecting to database
    const db = await connect()

    // initializing the repository
    const repository = new ProductRepository(db, 'products')

    // call find method from repository
    const product = await repository.create({
      name: 'laptop',
      count: 23,
      price: 2999,
    });
    console.log(`created product ${product}`)

    const isOutOfStock = await repository.isOutOfStock(product.id);
    console.log(`is ${product.name}'s out of stock ${isOutOfStock}`)
})()

Dependency Injection

In real project we have some Dependency Injection library, in my case it is Awilix.
Now we need realize integration of repository with out DI solution.

// Knex connection file
import knex from 'knex'
import config from 'knex.config'
import { container } from 'utils/container'
import { asValue } from 'awilix'

export default () => new Promise(async (resolve, reject) => {
  try {
    const connection = knex(config)
    await connection.raw('SELECT 1')

    container.register({
      knex: asValue(connection),
    })
    resolve(connection)
  } catch (e) {
    reject(e)
  }
})

Now when we have connection to database, let's change little bit out ProductRepository.

import { asClass } from 'awilix'
import { container, Cradle } from 'utils/container'
import { BaseRepository } from 'utils/repository'

export interface Product {
  id: string
  name: string
  count: number
  price: number
}

// now, we have all code implementation from BaseRepository
export class ProductRepository extends KnexRepository<Product> {
  constructor({ knex }: Cradle) {
    super(knex, 'products')
  }

  // here, we can create all specific stuffs of Product Repository
  isOutOfStock(id: string): Promise<boolean> {
    const product = this.qb.where(id).first('count')

    return product?.count <= 0
  }
}

container.register({
  productRepository: asClass(ProductRepository).singleton(),
})

And we have pretty cool Data Base Abstraction Layout.

Let's call it is in out Controller/Handler, Fastify handler in my case. I will skip of Product service Realization, in is will just inject ProductRepository, and proxy call findOne(id) method.

import { FastifyPluginCallback } from 'fastify'
import { cradle } from 'utils/container'

export const handler: FastifyPluginCallback = (fastify, opts, done) => {
  fastify.get<{
    Params: {
      id: string
    }
  }>('/:id', async ({ params }) => {
    const response = await cradle.productService.findOne(params.id)

    return response
  })

  done()
}

Conclusion

In this article we looked at how to implement Respository Pattern in Node.js with TypeScript. It is very flexible and extensible Data Layer what able use any SQL/NoSQL database.

But that is not all 😄
Becase we need to look how to add features like:

Subscriptions on entity events like BeforeInsert, AfterInsert, BeforeDelete, AfterDelete, and etc.
Select specific fields
Hidden fields for prevent select user password hash for example
Transactions support

But it's more about how to create and develop your own ORM. And that is beyond the scope of an article on the Repository Pattern.

Collection of Modern React Frontend interview questions

aabdullin — Tue, 31 Mar 2020 07:34:51 +0000

Recently, I have been thinking that I want to find a new Frontend (React) job. And after some interviews, I highlighted the main questions and my answers, and make a short note for myself.

This article it is a collection of interesting React interview questions.

1 — What data types have in JavaScript?

Let's start with the primitives:

String — any text values.
Boolean — Boolean type, takes two possible meanings, sometimes called true or false.
Number/Float — Responsible for the numeric type, and Float for non-numeric, it is worth noting Float and Number in JS by viewing through typeof, this is the same type.
NaN — property is a value representing Not-A-Number.
Undefined - we can get it when we try to get an undefined variable.
BigInt — because Number have limitation in his value, for work with big numbers values number will come to the rescue BigInt, maximum value may be getting with call Number.MAX_SAFE_INTEGER.
Symbol — (Added in ES6) allows create value instance whom will be unique and unchangeable. May be used in example upon realization Dependency Injection, for premises dependencies unique identification, instead of interfaces like in Java/C#.

It is also worth continuing:

Null — tells us that the variable is defined, but does not have. By specification is it object(typeof).
Object — simple data structure that can have its own properties and methods. Based on it created another data types such as: Map, Set, WeakMap, WeakSet.
Array — which are high-level, list-like objects.
Function — serves to determine the functions.

Also useful to note:

Proxy — «turns around» other object and may intercept (and, if desired, process it yourself) different actions with him, for example get/set property and other.

And also types Map, Set, WeakMap, WeakSet.

2 — What is Http?

Http it is a one of the protocols that the browser uses to communicate with server. If view him lifecycle, then when entering on page by domain YouTube.com browser make request to server, but to server access can receive only by his IP-address, for example 49.12.15.17. And so they come to DNS servers that store information about the domain whose IP address is assigned, and it is also worth noting that, according to the standard, Http uses the 80th port for the request.

And after browser received a content page, he start to parse HTML/CSS/JS via using blink and V8 engine.

But if you go deeper, then the Http protocol has versions, for example Http 1.1, which are widespread (not statistics, personal opinion of the author). There is also a version of Http 2, which in turn differs from version 1.1 in its improved support for parallel loading of static resources(Multiplexing multiple requests in a single TCP connection). And at the moment there Http 3, it in turn implements UDP-based multiplexing.

3 — Difference between useState and useRef?

Is useState and useRef hooks we may to store our information between re-renders. But main difference it is what react component after change state in useState will re-render, whire useRef not.

For example with useRef we may to realize useUpdate hook. what would work only when component update, not on first render.

const useUpdate = (fn, deps = []) => {
    const isMount = useRef(true)

    return useEffect(() => {
        if (isMount.current) {
            isMount.current = false
        } else {
            fn()
        }
    }, [isMount, ...deps])
}

4 — How to work Event Loop under hood?

JavaScript in the browser runs in single-threaded mode, which has own «Life cycle». For example if we call:

setTimeout(() => calledSecond(), 1000)

calledFirst()

There we wand call a some function after 1000 milliseconds. When the code executing the JavaScript engine arrives at this line and passes our function to Call Stack, and goes continue executing another code, but when 1000 milliseconds will pass and Event Loop checks Call Stack again, it will see that this function is ready, and execute it.

But then he will meet heavy synchronous operation, he will stay and wait until operation will be done. And it this moment Event Loop will be blocked, and dont execute code further, that is Event Loop dont get to use guarantee what we will call function in setTimeout after 1000 milliseconds, he will call it when next time when Event Loop start to check Call Stack on other iteration and will see that function is ready. More details here.

5 — What is Iterable?

JavaScript have so called iterable objects, that is objects content of that we may can sort out. Like for example an array. Enumeration itself, for the most part, is carried out using iterators (for example, the for..of construct uses iterators to enumerate elements). In object we can to define a key Symbol.iterator and in this function should be return object with called next function.

6 — What is generator?

It is a function what can to stop and continue function execution, and return intermediate result and further continue executing in arbitrary moment.

function* generatorFn() {
    yield someFunction()
}

Commonly used as a replacement async/await to work with asynchronous operations. For example Redux-Saga library.

7 — What are the ways in React to pass data from parent component?

In React we may to use just a props drilling or Context API.

const CounterContext = createContext({
    counter: 0,
    handleIncrement: () => {},
})

const useCounter = () => useContext(CounterContext)

const Wrapper = ({ children }) => {
    const [counter, setCounter] = useState(0)

    const handleIncrement = useCallback(() => setCounter(counter + 1),
        [counter])

    /* or */

    const handleIncrement = useCallback(() => setCounter(counter =>
        counter + 1), [])

    return (
        <CounterContext.Provider
            value={{
                counter,
                handleIncrement,
            }}       
        >
            {children}
        </CounterContext.Provider>
    )
}

const Counter = () => {
    const { counter, handleIncrement } = useCounter()

    return (
        <>
            <p>Count: {counter}</p>
            <button onClick={handleIncrement}>+1</button>
        </>
    )
}

const App = () => (
    <Wrapper>
        <Counter />
    </Wrapper>
)

But if our component with data have access to just children from props we may to use React.cloneElement(children, customProps) or we may to use children(customProps) and to parent component we need to pass child component like a function, just like with using LocationContext.Consumer (Render Callback).

const Wrapper = ({ children }) => {
    const [counter, setCounter] = useState(0)

    const handleIncrement = useCallback(() => setCounter(counter + 1),
        [counter])

    return (
        <>
            {children({
                counter,
                handleIncrement,
            })}
            {/* or */}
            {React.cloneElement(
                children,
                {
                    counter,
                    handleIncrement,
                },
            )}
        </>
    )
}

const Counter = ({ counter, handleIncrement }) => (
    <>
        <p>Count: {counter}</p>
        <button onClick={handleIncrement}>+1</button>
    </>
)

const App = () => (
    <Wrapper>
        {props => <Counter {...props} />}
        {/* or */}
        <Counter />
    </Wrapper>
)

8 — When we want to listen a window scroll event, how we may to optimize this?

We may to addEventListener wrap around debounce or throttling function, it is minimize function calls.

Or we can use IntersectionObserver API, when we need to detect what we have in View targetElement. IntersectionObserver API have polyfills, we dont need to worry about cross-browser support.

9 — What are the ways to optimize animations?

In JavaScript we may to methods like requestAnimationFrame/requestIdleCallback.

For CSS we may to use property like will-change, what say to browser that property will changed in future. And if we animate we need to use GPU optimized properties like transform, and dont use position when we animate element position.