In this blog post, we will learn to create an emoji picker for your tiptap-based editor.

Let’s define the EmojiData Model first.

interface EmojiData {
 /**
   Label, name, meaning, descritption of emoji, user search can happen
   on this text.
 **/
 annotation: string;

/**
 power users uses emoji codes example `:cool:` will insert  emoji
**/
shortcodes: string[];

/**
Unicode or actual emoji character: 😁/🥵/💙
**/
emoji: string; 

/**
fallback url to be used in case where current env doesn't support
this emoji character, or it can be used for custom emojis
**/
url?: string;
}

Our Emoji will be a custom node and not a simple character as the env platform may not support that emoji or we want to use custom emojis like slack.

Let’s get our requirement clear for emoji node:

• It should insert actual emoji character (text: inline, atom)

• Emoji should be copied as unicode to clipboard (selectable)

• If unsupported we should render the provided fallback emoji.

// Emoji-Node.ts

import { Node } from "@tiptap/core";
import isEmojiSupported from "is-emoji-supported";




/**
emoji node:
<span data-node="emoji" data-emoji="🥵" data-emoji-url="...">
 <span >🥵</span>
 <img src="..." />
</span>
**/

const EmojiNode = Node.create({
 // name of our node with which this will be registered
 // Node.name
 name: 'emoji',
 // we want it to be inline element
 group: "inline",
 inline: true,
 // we want node to be selectable
 selectable: true,
 // we want it as non editable node
 // https://tiptap.dev/docs/editor/core-concepts/schema#atom
 atom: true,

 // add attributes to the custom node, these appear on the model/schema
 addAttributes() {
    return {
     // EmojiData['emoji']
      emoji: { default: null },
      // EmojiData['url']
      url: { default: null }
    };
 },

 // parse the initial content or/pasted clipboard, parse it to
 // see if the html-node matches to emoji-node schema
 parseHTML() {
    return [
      {
       // all nodes should be identified with some selector,
       // in our case we use `data-node` our each node in schema
       // which is same as `Node.name`
        tag: 'span[data-node="emoji"]',
        // get the required attribute from the node-schema html
        getAttrs(node) {
          let attrs: false | Record<string, any> = false;
          // get the attributes character/emoji and fallback url
          const emoji = node.getAttribute("data-emoji");
          const url = node.getAttribute("data-url");

          if (emoji || url) {
            attrs = {
              emoji,
              url,
            };
          }

          return attrs;
        },
      },
    ];
  },

  // render the schema-node representation to html content
 renderHTML({ HTMLAttributes, node }) {
    // we need to know if the env supports the emoji
    // unicode char, if it doesn't we should render the fallback image
    let renderEmoji = false;

    const isBrowserEnv = isBrowser();

    if (isBrowserEnv) {
      // it is very interesting concept how emoji supported is checked
      // on browser by rendering it on canvas and doing 
      // some color checks, i'm using the package directly here
      renderEmoji = isEmojiSupported(node.attrs.emoji);
    }

    const { emoji, ...restHTMLAttributes } = HTMLAttributes;

    return [
      // root-node <span data-node="emoji" data-emoji="🥵" data-url="...">
      "span",
      mergeAttributes(restHTMLAttributes, {
        // add all html equivalent attributes
        "data-node": "emoji",
        "data-emoji": node.attrs.emoji,
        "data-url": node.attrs.url,
        // styles to make sure emoji works as intended
        // font-family needs to be inorder as firefox differ from chrome
        style: `user-select: text; font-family: "Twemoji Mozilla", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji", "EmojiOne Color", "Android Emoji", sans-serif;`,
      }),
      // <img src="..." fallback or custom emoji
      [
        "img",
        {
          src: node.attrs.url,
          // we will not show image fallback if env supports the emoji
          // also w=1em, h=1em ensures that fallback scales 
          // with font-size of current text
          style: `${
            renderEmoji ? "display: none;" : "display: inline-block;"
          } width: 1em; height: 1em;`,
        },
      ],
      // <span>🥵</span>
      [
        "span",
        {
          role: "img",
          // render the image as inline-block
          style: `${renderEmoji ? "display: inline-block;" : "display: none;"}`,
        },
        node.attrs.emoji,
      ],
    ];
  },

  // we should copy node always as character in clipboard
  // the node schema is specific to use and will not be recognised
  // in any other platform, so make sure you allways copy as unicode
  renderText({ node }) {
    return node.attrs.emoji;
  },

  // allow to programatically insert the emoji
  // user should be able to insert emoji node from editor command
  // create `insertEmoji` command
  addCommands() {
    return {
      insertEmoji({ url, emoji }) {
        return ({ editor, chain }) => {
          // any `atomic` node faces difficulties while selecting
          // in tiptap editor, thus we insert dummy space to allow
          // selections to happen on #Text and in turn on emoji-node
          const shouldInsertSpace = shouldInsertSpaceAfterCurrentCursor(editor);

          return chain()
            .insertContent({
              type: "emoji",
              attrs: {

                url,
                emoji,
              },
            })
            // if next position is alredy a space don't insert anything
            // else insert space for selection sake
            .insertContent(shouldInsertSpace ? " " : "")
            .run();
        };
      },
    };
  },
});

You can checkout the code on my GitHub for emoji node.

Now that we have created the emoji node, it is time to create the emoji picker. In my case I want the picker to be activated as soon as someone presses : and close when they select an emoji or press : back again.

Let’s get requirements clear for picker:

1. Trigger on :

2. Open a emoji list as grid in popup near the cursor.

3. Filter the emoji in the popup list as user types and show matching emojis.

4. If user matched on one emoji and press : insert that emoji by default let the user choose from the list otherwise.

You can have your own emoji database from emoji-base, or for timebeing simpley use

[
  {
    "shortcodes": ["grinning", "grinning_face"],
    "emoji": "😀",
    "annotation": "grinning face"
  },
  {
    "shortcodes": ["grinning_face_with_big_eyes", "smiley"],
    "emoji": "😃",
    "annotation": "grinning face with big eyes"
  }
]

To trigger popup on press of a characater we will use tiptap-suggestion extension and modify it to match our use case.

import { Extension } from "@tiptap/react";
import Suggestion, {
  SuggestionOptions as NativeSuggestionOption
} from "@tiptap/suggestion";
// my emoji-node package published as npm repo,
// same as what we have built above
import { EmojiNode, EmojiData } from "@vtechguys/tiptap-emoji-node";
import { isEmojiSupported } from "is-emoji-supported";
// the rendering depends on end user in my case i have rendred
// as simple dom of grid items.
import { filterEmoji, getRenderItems, RenderItemsProps } from "./utils";

type SuggestionOptions = Pick<NativeSuggestionOption, "char" | "command">;

type Emoji = EmojiData & {
  search?: string;
};

type EmojiPickerOptions = {
  // list of emojis from your database/json
  emojis: Emoji[];
  // default tiptap suggestion options
  suggestion: SuggestionOptions;
  // we we want database/json to be fetched at later instance
  // this saves resource loaded on first render
  fetch?: () => Promise<Emoji[]>;
  // popup is using tippy so tippy config
  tippy: RenderItemsProps["tippy"];
  // callback to trigger whenever emoji is clicked
  onEmojiSelected?: RenderItemsProps["onEmojiSelected"];
  classes: RenderItemsProps["classes"];
};

/**
 add propperty to emoji if it is supported on current env
**/
const populateEmoji = (emojis: Emoji[]) => {
  emojis.forEach((emoji) => {
    emoji.isSupported = isEmojiSupported(emoji.emoji);
  });

  return emojis;
};

export const EmojiPicker = Extension.create<EmojiPickerOptions>({
  name: "emoji-picker",

  /**
   * Picker needs basic extension for rendering emoji node
   */
  addExtensions() {
    return [EmojiNode];
  },
  /**
   We will store the emojis database as a list in  editor's client storage
  **/
  addStorage() {
    return {
      emojis: [],
    };
  },

  onCreate() {
    /**
     * storage is initialized with emojis and make sure
     * emoji is populated with emoji with isSupported flag
     * the flag indicates what in the given list is supported
     */
    this.storage.emojis = populateEmoji(this.options.emojis) || [];

    /**
     * The init didn't provided emojis,
     * thus we will try to fetch from url
     */
    if (this.storage.emojis.length === 0) {
      this.options.fetch?.()?.then((data) => {
        this.storage.emojis = populateEmoji(data);
      });
    }
  },

  addOptions() {
    return {
      tippy: {
       // width of the popup
        maxWidth: 364,
      },
      emojis: [],
      suggestion: {
       // trigger char is :
        char: ":",
        command: ({ editor, range, props }) => {
          props.command({ editor, range, props });
        },
      },
      // picker dom classes
      classes: {
        root: "emoji-picker__container",
        emojiContainer: "emoji-picker__emoji",
        emojiImage: "emoji-picker__emoji__img",
        emojiChar: "emoji-picker__emoji__char",
      },
    };
  },

  addProseMirrorPlugins() {
    return [
      Suggestion({
        editor: this.editor,

        ...this.options.suggestion,

        items: ({ query }) => {
          // when the user starts typing after triggering emoji
          // filter the matching emojis from the list
          // the retuned filtered emojis[] will be renderd in popup
          return filterEmoji(query, this.storage.emojis);
        },
        // don't allow user to type space
        allowSpaces: false,
       // anywhere in the text we should be able to trigger emoji
        startOfLine: false,

        render: () =>
          // from the returned filtered items render the list inside popup
          getRenderItems({
            tippy: this.options.tippy,
            editor: this.editor,
            onEmojiSelected: this.options.onEmojiSelected,
            classes: this.options.classes,
          }),
      }),
    ];
  },
});

Implmentation of filterEmoji is upto you, I will show the render function which is responsible for rendering the emojis.

export const getRenderItems = (args: RenderItemsProps) => {
  /**
   * Maintains the latest list of rendered items,
   * !Note: Should be updated first in every cycle of render
   */
  let currentItems: EmojiData[];

  let component: ReturnType<typeof initNodeView>;
  let popup: any;

  return {
    onStart: (props: SuggestionProps) => {
      // 1. update the current items first
      currentItems = props.items;
      // 2. init the node view
      component = initNodeView(args);
      // 3. init the popup, tippy
      popup = tippy("body", {
        getReferenceClientRect: props.clientRect as GetReferenceClientRect,
        appendTo: () => document.body,
        content: component.root,
        showOnCreate: true,
        interactive: true,
        trigger: "manual",
        placement: "bottom-start",
        maxWidth: args.tippy.maxWidth,
        zIndex: args.tippy.zIndex || 2147483647,
        ...args.tippy,
      });
      // 4. render after init is completed
      component.render(props);
    },

    onUpdate(props: SuggestionProps) {
      // 1. update the list of items
      currentItems = props.items;
      // 2. render the items with updated props
      component.render(props);
      // 3. update popup
      popup[0].setProps({
        getReferenceClientRect: props.clientRect,
      });
    },

    onKeyDown(props: SuggestionKeyDownProps) {
      /**
       * Esc are treated as escape from popup
       */
      if (props.event.key === "Escape") {
        popup[0].hide();
        return true;
      }

      /**
       * Close the suggestion is user press `:` and there was only one matching element in list,
       * example `:cool` will filter and show  🆒  in picker popup list,
       * now as soon as user press `:` again close the popup and insert the matching emoji, here 🆒
       * as :cool: is short code for 🆒
       */
      if (props.event.key === ":" && currentItems.length === 1) {
        args.editor
          .chain()
          .deleteRange(props.range)
          .insertEmoji(currentItems[0])
          .run();
        return true;
      }

      return component.onKeyDown?.(props);
    },

    onExit(props: SuggestionProps) {
      popup[0].destroy();
      component.destroy();
    },
  };
};

Our Native Javascript NodeView will look like:

/**
 * Init the view of the item
 * @param args
 * @returns
 */
const initNodeView = (args: ViewArgs) => {
  /**
   * record current render props
   */
  let renderProps: SuggestionProps | null = null;

  /**
   * create the root level element
   */

  const root = document.createElement("div");
  root.classList.add(args.classes?.root || "");

  /**
   * create click event on emoji popup root, select and insert the 
   * clicked emoji
   */
  const clickBinding = addEvent(root, "click", (event) => {

    if (!renderProps) {
      return;
    }


    let emoji = null;
    // find the clicked emoji
    // find the position(index) in the list
    const position = Number(((event.target as HTMLElement)?.closest("[data-position]") as HTMLElement)?.dataset?.position);
    // get the emoji at the index
    if (!Number.isNaN(position)) {
      emoji = renderProps?.items?.[position];
    }


    if (!emoji) {
      return;
    }

    // the emoji selected callback is called and if the callback
    // returns true we assume the insertion is being handled by callback
    // else we will do the insertion
    const handled = args.onEmojiSelect?.(event, {
        range: renderProps.range,
        editor: renderProps.editor,
        emoji,
      });

    if (!handled) {
      renderProps.
          editor?.chain?.()
      // as user can type after :
      // which is received as query to filter emoji list
      // we need to remove this query text before insertion emoji
      // the text index range is provided by TipTap suggestion plugin
          ?.deleteRange(renderProps.range)
      // insert the emoji node using the command that we created
          ?.insertEmoji?.(emoji)?.run?.();
    }

  });

  /**
   create each emoji element
    <span data-position="index">
        <img [src, alt] /> (fallback if emoji is not supported)
        <span> (emoji-unicode char)
   */
  const createEmoji = (emoji: EmojiData, index: number) => {
    const emojiContainer = document.createElement("span");
    emojiContainer.classList.add(args.classes?.emojiContainer || "");

    emojiContainer.setAttribute("data-position", `${index}`);

    const isSupported = emoji.isSupported;

    const img = document.createElement("img");
    img.classList.add(args.classes?.emojiImage || "");
    img.setAttribute("src", emoji.url || "");
    img.setAttribute("alt", "Emoji of " + emoji.annotation);
    img.style.display = isSupported ? "none" : "inline-block";

    const char = document.createElement("span");
    img.classList.add(args.classes?.emojiChar || "");

    char.setAttribute("role", "img");
    char.ariaLabel = emoji.annotation;
    char.style.display = isSupported ? "inline-block" : "none";
    char.appendChild(document.createTextNode(emoji.emoji));

    emojiContainer.append(img, char);

    return emojiContainer;
  };

  // a custom nodeview object

  return {
    root,
    /**
     * render the view with given props
     */
    render(props: SuggestionProps) {
      renderProps = props;

      root.innerHTML = "";

      const emojis = props.items.map((emoji, index) =>
        createEmoji(emoji, index)
      );
      root.append(...emojis);
    },
    /**
     * destroy view
     */
    destroy() {
      renderProps = null;
      clickBinding?.destroy();
      root.remove();
    },

    onKeyDown(props: SuggestionKeyDownProps) {
      // TODO: move between emojis in the list

      return false;
    },
  };
};

Once you have all that in place, you will have a emoji picker. You may want to go through the emoji picker code on my github @vtechguys/tiptap-emoji-picker

Stay tuned for more such tiptap extensions blog post.

Do you need a state management library?

You don’t realize it, but you may often skip using any state management library in your application. Native state hooks in React and some composition patterns can accomplish the majority of things.

Do you want to communicate changes from one part of the tree to another?

Pull the state up to a common parent and pass it via props or context.

Does my state have too many properties?

useReducer is very powerful; you should pay attention to native stuff.

I have asynchronous stuff going on in my app.

useQuery, useSWR, and useEffect are perfect candidates to solve your problem.

I’m not against state management libraries, but once you do a npm i xyz, you are bound to think in their paradigm, and now you want the library to do everything for you. Things that don’t make sense in the state will be moved to the state; things that are derived from states will see their property in the state. You end up chaining yourself to thinking only in the paradigm of that library.

Questions that matter

• I have a deeply nested leaf item that modifies and affects the entire app.

• I have too many features that are dependent on each other.

• I have other feature states spread out in my own feature, coupling things.

• I find it difficult to communicate between features.

Philosophy

A product manager tries to pack in many features in their application; however, that may be good for the user but is a horror for developers. If you have such a project manager, I feel you, bro! 🥲

But as developers, it is our responsibility that feature addition and deletion should be plug-and-play; even your project manager should be able to do it by pressing the harmless* button, and your code should ensure that it is harmless.

Mind your own business

Your feature should always be independent of any other feature in the app.

It should not directly poke its nose into the business logic of other features and strictly remind them to “Mind their own business” when they try to poke their nose into your stuff.

When you develop something, make sure you write it in such a way that it can run in isolation, that is the core of philosophy.

Make your code in such a way that if one feature speaks English, the other feature should speak Chinese, What I’m stressing is that the features should not have any knowledge of each other; they should not be able to talk to each other directly.

But you need to send messages across, and that is why you need a mediator, translator, or orchestrator.

Say I'm building something similar to notion

I see two main items:

• Sidebar

• Editor

When a page is clicked in the sidebar, it opens up in the editor.

When the editor heading changes, the text also changes in the sidebar.

The context menu in the sidebar allows you to rename the editor headline.

Sidebar state:

state = [
  { 
    id: string; // uniq page id
    label: string; // title of the page
    value: string; // page value
  },
  ...
]

Editor state:

state = {
    id: string;
    title: string;
    content: [
        {
            tag: string;
            content: []
        },
        ...
    ]
}

Note: Each has its state and not a common state so when I update text in the sidebar, that will update its own state and editor state.

A naive implementation would look like this:

onRename = () => {
 // update the state in sidebar
  sidebarDispatch({ 
      type: 'sidebar/update_item', 
        payload: { 
            id: '..', 
            title: '...' 
        } 
    });

    // update the same in editor
    editorDispatch({
        type: 'editor/update_text',
        payload: {
           title: '...'
        }
    })
}

This onRename function would be present in both modules, i.e., editor and sidebar, but this is what causes coupling. Although we want to do exact same thing but not spread dispatch across modules,.

We will pull this into this logicglobalOrchestrator, which acts as a mediator between the two. It may look like this:

globalOrchestrator({ type: 'rename', paylod: { id: '..', title: '...' } })

The globalOrchestrator would exactly consume dispatches but abstract them in a way that two modules only know the globalOrchestrator.

The editor thinks that doing so globalOrchestrator > rename will update the editor's own text and the editor states, it does not know the sidebar.

The same is true of the story of the sidebar, where it only knows globalOrchestrator > rename updates its own state.

That is how cross-communication happens and every feature has its own business in application.

We have eliminated coupling, you may not realize it but let’s say in the future you need to remove the sidebar as a feature as a whole What you will do is delete the sidebar directory and remove the sidebar dispatch from globalOrchestrator > rename

Never show your true self

You, as a feature, should always… always create abstractions over your internal state, hooks, dispatch, useSelector/useAtom/useSlice.

• Never expose your entire state; expose atoms or slices of state in hooks.

const useSidebarOpenState = () => {
 // 1. mark internal state as unsafe
 // 2. your lib specific way to get slice/atom
 return useSidebarState__UNSAFE(state => state.open);
}

• Never expose dispatches or actions

const useSidebarOpenDispatch = () => {
 const dispatch = useSidebarDispatch__UNSAFE();
 const open = () => {
     dispatch(sidebarOpenAction());
 };
 return open;
}

• You may choose to combine the two

const useSidebarOpen = () => [useSidebarOpenState(), useSidebarOpenAction()]

• Expose as little as possible, create and derive values in hooks itself.

const useSidebarHasItemState = () => {
 // instead of having items exposed we should 
 // Start with exactly what was required
 // yes you may need all of the items but that is diff
 return useSidebarState__UNSAFE(state => state.items.length > 0);
}

• Binding at the top

Structure your code in such a way that you create all global bindings, handlers, and complex logic at the root of the feature component and make individual nodes of the tree pure, dumb, and presentational components.

sidebar
 |____ components
 |        |___ search
 |        |___ section
 |               |___ Header.tsx
 |               |___ ItemList.tsx
 |
 |____ hooks
 |      |___ useInfiniteScroll.ts
 |
 |____ views
 |       |___ Root.tsx
 |
 |____ Orchestrator.ts

The above structure is how we would like to visualize and lay out our features.

• Anything inside of components has to be pure and driven by props and may have internal useState, but should in no way be bound to any global/environmental state/handler/actions.

• Anything inside of hooks is hooks used inside our feature directory or may be exposed to the outside world, these may contain hooks with global bindings and pure hooks with internal usage.

  Only hooks with internal usage may be used in the components dir, any hook with global bindings will not be used in the components dir.

  Usually, it is a good idea to localise internal hooks within the component dir,

  for example:
  useInfiniteScroll load sidebar items on the scroll can be within sidebar/components/section and used inside of ItemList.tsx.

• Anything inside of views creates bindings to the environmental state and is distributed as props to underlying components. These are the perfect sites to consume global state and simplify handlers.

  Say our sidebar had two tabs, admin and user, where if switched they would render their own tree in the sidebar. They can have their individual roots in
  views dir.

  A Root is the mounting point of the feature component; it may branch into several roots, for example AdminRoot or UserRoot with only the purpose of simplifying the underlying tree and branching slowly into a simpler tree. Each branch of Root tries to simplify stuff so that underlying trees are super simple.

• These roots are where we may consume our global-bound hooks, handlers, and utils, everything should be passed on as props. Props drilling may be an issue but remember that props usually tend to redistribute themselves as we nest and if 10 props were passed on during the 4–5th nesting or drilling, only 2–3 props may be required. If too props drilling too much, use context here.

• Note that it is not advised to directly bind or use global utils inside components but you may choose to wrap those in a SidebarOrchestrator that will exist to bind global to sidebar local, use this Orchestrator from props, create a SidebarOrchestrator hook, or use simple utils; that is up to you to decide.

In the future, you could just re-export to npm and use the sidebar with your own views and bindings in a different application or for your sister company.

You must have experienced this when you grew your API endpoints and received more traffic. It is okay as the business grows, but the growth brings bad actors into the system, and those actors may send too many requests and slow down your systems, or you may entirely shut them down.

Rate-limiting helps you solve the following:

1. A bad user may send loads of requests, which should not affect any genuine user.

2. A user is sending you low-priority requests that are blocking high-priority requests. The system prioritizes high-priority requests over low-priority requests. This is called load shedding.

3. Sometimes, if the system is wrong internally (a resource crunch) and you cannot serve all your regular traffic, you may want to drop low-priority requests in favor of high-priority requests.

Some common types of rate limiters are:

• Request rate limiter

• Concurrent rate limiter

• Fleet rate limiter

• Worker utilization load shedder

Request Rate Limiter

A rate limiter that limits requests for a user to N times per second. Usually, it is put per API, and the user is trained to send only limited requests per second for that API.

For example, a user can only log in 5 times per minute.

// Limit user to 5 requests in 5 minutes (5 * 60 seconds)
@RateLimit({ threshold: 5, duration: 5 * 60 })
@Post('/login')

What the above @RateLimiter decorator will do is limit a user to being able to log in only 5 times in a minute and reject with 429 if the user tries to log in more than 5 times. Depending on the implementation, it may follow any rate limiter algorithm, for example, token bucket [link here].

API rate limiter will save you most of the time, as these are usually triggered in any system. They also save API endpoints against rouge scripts, which has the potential to bring down the system. It is a good idea to keep some values of threshold and duration in production and development to prevent any surprises.

Websites like Amazon host flash sales where rate limits are relaxed and it is allowed to be leaky, i.e., burst briefly for a short period of time, that may be included in the implementation.

API Rate limiters, limits users to a maximum threshold of request per second.

Concurrent rate limiter

All API endpoints are not the same; some are slow and resource-hungry. Hitting the rate limit on such APIs affects the overall system performance, slowing down every low CPU usage API.

API level rate limits safeguard individual APIs, but this rate limiter makes sure to safeguard a set of APIs together to keep the system running at acceptable performance.

Current rate limiter: "You can only request 50 requests in progress at the same time.".
API Rate Limiter "You can send 1000 requests to our API endpoint."

It also forces users to think about how to manage the API requests.

Concurrent rate limiter, manage resource-contention for CPU intensive API endpoints.

Fleet usage load shedder

Load shedder rate limiting, sheds the load of low-priority endpoints by reserving a fixed fraction of resources to be always available to serve high-priority requests.

For say, it is like reserving 20% of our resources for high-priority requests and low-priority requests get 80% of system resources. In case of increased loads because of low-priority requests, we make sure that we don't compromise with percentage of resources allocated to high-priority requests. So low-priority requests will be dropped if it tries to cross 80% resource allocation with a 503.

Fleet usage load shedder, make sure there are always enough resources for critical high-priority requests.

Worker utilization load shedder

API services are served by a set of worker machines that independently receive and respond to requests. In case of increased loads when many requests are getting queued up on a worker, that worker may choose to drop a low-priority request in favor of any high-priority request in the queue. Worker sheds low-priority load as its utilization limits are challenged.

This is the last defense against increased traffic loads and is rarely triggered, maybe only in major incidents.

As an example, the API endpoints can be categorized in the following fashion:

1. Critical request

2. Post request

3. Get request

4. Test script request

Track the load and utilization of the worker and when we see it is getting challenged and many requests are being queued, the worker will start shedding requests from the bottom i.e requests from test script or automation environments are dropped first with 503, and we go up in the list as required.

It is important to bring back dropped requests with delay, as it may again cause issues to be brought back immediately.

The idea here is to keep on shedding low-priority requests and trying our best to serve critical or high-priority requests as long as possible without a system shutdown, as soon as the incident is resolved we can slowly bring back traffic as per priority order to serve them back again.

Worker utilization load shedders reserve workers for critical requests.

Conclusion

Rate Limiters are the most reliable way to accurately scale your API endpoints. Start small from the API level rate limit and gradually add others when needed.

In the real world, there are many rate limiter implementations that operate on different layers (middleware, application layer, IP layer). There are many different algorithms that rate limiters implement, keeping usage counts in Redis or something similar.

Depending on the scale of the company rate limiter can be in the API gateway, middlewares, or application layer. In any scenario, we should make sure if the rate limiter itself is down it shouldn't affect API as it is.

Intent should be relayed to rate limited/ throttled users, whether a service it is 429 or 503.

Keep metrics up to make sure you are not rejecting genuine requests and tune limits accordingly.

The sheets represent the tables in the database where your data is stored. Data is stored in a grid or tabular format as shown below.

Each row in the grid is an entry in the table.

Creating database

CREATE DATABASE store_database;

The above command creates a database called store_database for us it is the name of the envelope where we will put our store sheets.

Creating Tables

What is data a store manager would like to keep?

• Employee details
• Product details
• Order details

These are called entities, each entity served a specific purpose, you cannot put employee details and product details together. For us, they mean a sheet in an envelope, each sheet in the envelope has particular data written on it. A sheet may be a list of products in the store, another sheet may be a list of employees in the store. In the terms of the SQL, each of these sheets represents a table in the database.

Each of the sheets (table) stores only one kind of data object(entity). Each entity has some attribute associated with it, for example, an employee Aniket has an ID, Name, and Salary whereas a product has an ID, Name, and Price. These attributes or columns are properties of the entity and will vary as the entity varies.

CREATE TABLE employees (
  id bigserial,
  full_name varchar(50),
  salary numeric
);

The above commands create a sheet/table for Employee data with each employee having properties id, full_name, and salary.

If you look at the above command you will notice full_name varchar(50) the full_name is the field or attribute an employee has whereas varchar(50) is the datatype the column/attribute can have, i.e name can only be characters in the same way salary can only be numeric and not a char because 2500qwerty is not a valid salary but 2500 is a valid salary.

Inserting rows into table

Let's start putting the data of employees in the employee table.

INSERT INTO store_database
  (full_name,    salary)
VALUES
  ('Aniket',     2500),
  ('Robert',    2600);

• The above command insert data into store_database.
• If you notice we are specifying the attribute or column names for which data has to be inserted.
• Notice we are inserting multiple values (...), (...) as comma-separated in parathesis.
• Data will appear in order of insertion

The result looks like the following in the PostgresSQL

In this article, we have learned how to create a database and table, and how to insert data into those tables. In the next article, we will learn how to read and query this tables.

const Button = styled('button')(
  {
    backgroundColor:  "blue",
    color: "white"
  }
)

A few things to note when exploring the API are: ```jsx // On breaking into parts: const Button = // <-- Part: 3 styled('button') // <-- Part: 1 ({ backgroundColor: 'blue' }) // <-- Part: 2

- Part 1: The `styled` function takes the `tagName` that has to be created i.e

```jsx
 styled('button') <-- 1

// is equivalent to

<button>

• Part 2: The styled(tagName) returns a function that accepts style-object which will be used to style this tagName element.

({ backgroundColor: "blue" }) <-- Part 2

// is converted to 

css({ backgroundColor: "blue" }) 

// and passed to the component as

<button className={css(...)} />

• The complete call returns a React component Button that renders a button with a given style.

From the above points, we can write a rough husk of our styled function

// Part 1: styled('button'): element of type tagName to render
function styled(tagName) { 
  // Part 2: style('button')({ color: 'white' }) takes in the style object and applies these styles to `tagName=button` component

  return function applyStyles(styleObject) { 
      // Part 3: `Button` react component 
      return function Component(props) { 
          // ...styling and element creation... 
          // Mark: 1
      }
  }
}

Now in place Mark: 1 we need to do the following:

• Create an element using React.createElement of type tagName

• Pass style-object into css function to generate name, as props may already contain some className so compose these className together.

// continue from Mark: 1

const clonedProps = clone(props);
// a copy of props is required as by default react makes props immutable
// and if we want to modify any props we need to make a copy for our use

// compute a className for styleObject
const generatedClassName = css(styleObject);

// compose className 
const className = generatedClassName + props.className ? + ` ${props.className}` : '';

// reassign composed className
clonedProps.className = className;

// create element of type `tagName` with props = `clonedProps` and `style=generateClassName`
const element = React.createElement(tagName, clonedProps);

// The `element` is of type `tagName` and of `styles=styleObject` this is one we want to render

return element;

That is what the style-components version of our CSS-in-JS library looks like. clone function can be as simple as:

const clone = (obj) => Object.assign({}, obj);

More reads on the CSS-in-JS:

• Why CSS-in-JS?

• CSS: Isolation vs Abstraction

• Build your own emotion like CSS-in-JS library

• Styler GitHub

• Styler Codesandbox

There are some brilliant minds working on emotion, we aren't going to recreate emotion with all its complexities and optimization just that we are trying to develop a better understanding of such CSS-in-JS libraries by building one on our own.

Let us start by exploring API and see what emotion does for us.

So the emotion package exports a function called css which takes style-object as an argument and returns a unique className which is used by ourdiv to apply some style.

Another overload signature css function can also take an array of style-object as an argument. For example:

css(
  [  // <-- array of 
    { padding: '32px', backgrounColor: 'orange' }, // <-- style object 1
    { fontSize: '24px', borderRadius: '4px' } // <-- style object 2
  ]
)

In the DOM css function injects a <style> in the document.head where it keeps the compiled CSS created from calling css function on the style-object.

Summarising emotion css function:

• css function takes an object or array of objects as an argument.
• These objects are called style-object which is a way of writing CSS with JavaScript objects.
• It returns a unique className for the given style-object.
• It compiles the style-object into valid CSS and injects a style tag containing our compiled CSS into the document.head

The css Function

Let's break it down is a series of programmatic steps:

1. Convert to a valid style-object.
2. Generate a unique className for the style-object.
3. Parse the style-object to generate valid CSS styles and attach them to className.
4. Inject the parsed CSS into a stylesheet in DOM.

Following our programmatic steps our css function should look like:

function css(styles) {

  // 1. convert to valid style-object
  const _style_object_ = getValidStyleObject(styles);

  // 2. generate unique className
  const className = getClassName(_style_object_);

  // 3. Parse the style-object to generate valid CSS styles and attach them to className
  const CSS = parseStyles(_styles_object_, className);

  // 4. Create or update the stylesheet in DOM
  injectStyles(CSS);

  // return className to be applied on element
  return className;
}

Step 1: Convert to a valid style-object

The css function can accept a style-object or an array of style-object. In the case of the array of style-object we must merge those to generate a single style object.

function getValidStyleObject(styles) {
  let style_object = styles;

  if (Array.isArray(styles)) {
    style_object = merge(styles);
  }

  return style_object;
}

function merge(styles) {
  // (*) shallow merge
  return styles.reduce((acc, style) => Object.assign(acc, style), {}); 
}

It should be noted that this is a shallow merge which will simply replace the properties of the former one with a later one, for the nested properties simple replacement may cause an issue so we out for deep-merge if required

Step 2: Generate a unique className for the style-object

After step 1 we have received a valid style-object and now we can process this object to generate unique className for it.

• Generating a unique className is required makes sure that there are no naming conflicts anywhere in the application;
• Unique className eliminates the need for any naming conventions like BEM, which makes the life of the dev easier.
• For generating names we should make sure that we always come up with the same name for the same structured style object.

const styleObject1 = {
  fontSize: '16px',
  fontWeight: 600
};

const styleObject2 = {
  fontSize: '16px',
  fontWeight: 600
};

styleObject1 === styleObject2; // false: reference is different
getClassName(styleObject) === getClassName(styleObject2); // true: Pure and Idempotent nature

• For maintaining Pure and Idempotent nature of getClassName function we will hash style-object so that it always returns the same output className for the same structured style-object. The hashing function needs input to be a string so we need to convert our style-object into a string. I will simply use JSON.stringify for our case. But there is a catch see below.

const obj1 = { a: 1, b: 2 };
const obj2 = { b: 2, a: 1 };

obj1 == obj2; // false: diff references

// an ideal stringifying function
stringify(obj1) === stringify(obj2) // true: '{ "a": 1, "b": 2 }'

// our JSON.stringify 
JSON.strinfigy(obj1) === JSON.stringify(obj2) // false
// '{ "a": 1, "b": 2 }' === '{ "b": 2, "a": 1 }' // false

• JSON.stringify is not an ideal stringifying utility as for same looking object it gives different string output. So If we plan to use JSON.stringify our hashes will also vary.

// it is a cache map of "serialized-style-object" to "hashed-style-object"
const style_classname_cache = {};

function getClassName(styleObject) {
  const stringified = stringify(styleObject);

  // pick the cached className to optimize and skip hashing every time
  let className = style_classname_cache[stringified];

  // if there is not an entry for this stringified style means it is new
  // so generate a hashed className and register and entry of style

  if (!className) {

    // use any quick hashing algorithm
    // example: https://gist.github.com/jlevy/c246006675becc446360a798e2b2d781

    const hashed = hash(stringified);
    // prefix some string to indicate it is generated from lib
    // it also makes sure that className is valid
    const _class_name_ = `css-${hashed}`;

    // hashing is costly so make an entry for the generated className
    style_classname_cache[stringified] = _class_name_;

    className = style_classname_cache[stringified];
  }

  return className;
}

Now let's proceed to next step where we will parse the style-object to generate CSS string.

// it is a map of "stringified-style-object" to "hashed-classname"
const style_classname_cache = {};

// inside css function
// ...
const className = getClassName(....);

let CSS = classname_css_cache[className];

if (!CSS) {
  CSS = parseStyles(_style_object_, className); // <-- Step 3
  classname_css_cache[classname] = CSS;
}

Step 3: Parse the style-object to generate valid CSS styles and attach them to className

This is the toughest part where we process the style-object and generate valid CSS rule declations from them. Before we proceed let's take an example:

  // style-object
  const styles = { 
    width: '600px',
    fontSize: '16px', // style-rule 1
    fontWeight: 600, // style-rule 2,
    color: 'red',
    '&:hover, &:active': {
        color: 'green',
    },
    '&[data-type="checkbox"]': {
      border: '1px solid black'
    },
    '@media(max-width: 1200px)': {
       width: '200px'
    }
   };

  css(styles)

  // compiled CSS from `style-object`
  .css-123 { 
    font-size: 16px;
    font-weight: 600px;
  }

  // ! NOTE !

  // 1) .css-123 is selector name or class-name here
  // 2) { and } marks style blocks/bound for this selector, each 
  //      block need to be parsed
  // 3) font-size: 16px is processed CSS for`fontSize: '16px'`
  // 4) `&:hover, &:active' are two blocks ideally joined by a `,`
  //      i.e '&:hover' and '&:active'
  // 5)  '&:hover' block is read as `css-123:hover` where
  //      `&` is replaced by current selector name
  // 6) `&[data-type="checkbox"]` attributes based styling is also possible
  // 7) @ rules are specific rule ex: @media screen size rules 
  //      so it should be processed early
  // 8) each nested style (ex: &:hover) need to be parsed 
  //      i.e recursive calling

From the above-gathered notes, we can write our parseStyles as

function parseStyles(style_object, selector) {
  // This collects `@import` rules  which are independent of any selector
  let outer = "";

  // This is for block rules collected
  let blocks = "";
  2;

  // This is for the currently processed style-rule
  let current = "";

  // each property of style_object can be a rule (3)
  // or a nested styling 7, 8
  for (const key in style_object) {
    const value = style_object[key];

    // @ rules are specific and may be further nested
    // @media rules are essentially redefining styles on-screen breakpoints
    // so they need to be processed first
    const isAtRule = key[0] === "@";

    if (isAtRule) {
      // There are 4 main at-rules
      // 1. @import
      // 2. @font-face
      // 3. @keyframe
      // 4. @media

      const isImportRule = key[1] === "i";
      const isFontFaceRule = key[1] === "f";
      const isKeyframeRule = key[1] === "k";

      if (isImportRule) {
        // import is an outer rule declaration
        outer += key + " " + value; // @import nav.css
      } else if (isFontFaceRule) {
        // font face rules are global block rules but don't need a bound selector
        blocks += parseStyles(value, key);
      } else if (isKeyframeRule) {
        // keyframe rule are processed differently by our `css` function
        // which we should see implementation at a later point
        blocks += key + "{" + parseStyles(value, "") + "}";
      } else {
        // @media rules are essentially redefining CSS on breakpoints
        // they are nested rules and are bound to selector
        blocks += key + "{" + parseStyles(value, selector) + "}";
      }
    }
    // beside the At-Rules there are other nested rules
    // 4, 5, 6
    else if (typeof value === "object") {
      // the nested rule can be simple as "&:hover"
      // or a group of selectors like "&:hover, &:active" or
      // "&:hover .wrapper"
      // "&:hover [data-toggled]"
      // many such complex selector we will have to break them into simple selectors
      // "&:active, &:hover" should be simplified to "&:hover" and "&:active"
      // finally removing self-references (&) with class-name(root-binding `selector`)
      const selectors = selector
        ? // replace multiple selectors
          selector.replace(/([^,])+/g, (_seletr) => {
            // check the key for '&:hover' like

            return key.replace(/(^:.*)|([^,])+/g, (v) => {
              // replace self-references '&' with '_seletr'

              if (/&/.test(v)) return v.replace(/&/g, _seletr);

              return _seletr ? _seletr + " " + v : v;
            });
          })
        : key;
      // each of these nested selectors create their own blocks
      // &:hover {} has its own block
      blocks += parseStyles(value, selectors);
    }
    // now that we have dealt with object `value`
    // it means we are a simple style-rules (3)
    // style-rule values should not be undefined or null
    else if (value !== undefined) {
      // in JavaScript object keys are camelCased by default
      // i.e "textAlign" but it is not a valid CSS property
      // so we should convert it to valid CSS-property i.e "text-align"

      // Note: the key can be a CSS variable that starts from "--"
      // which need to remain as it is as they will be referred by value in code somewhere.
      const isVariable = key.startsWith("--")

      // prop value as per CSS "text-align" not "textAlign"
      const cssProp = isVariable
        ? key
        : key.replace(/[A-Z]/g, "-$&").toLowerCase();

      // css prop is written as "<prop>:<value>;"
      current += cssProp + ":" + value + ";";
    }
  }

  return (
    // outer are independent rules
    // and it is most likely to be the @import rule so it goes first
    outer +
    // if there are any current rules (style-rule)(3)
    // attach them to selector-block if any else attach them there
    (selector && current ? selector + "{" + current + "}" : current) +
    // all block-level CSS goes next
    blocks
  );
}

At this point, we have compiled CSS from style_object and all that is left is to inject it into the DOM.

Step 4: Inject the parsed CSS into a stylesheet in DOM

For this step, we will create a <style> tag using document.createElement and inside of that style tag, we will append our styles in thetextNode.

• Create a <style id="css-in-js"> element if doesn't already exist;
• Get the text-node i.e stylesheet.firstChild and append CSS string from parseStyles in it.

// in case the process isn't running in a browser instance 
// so we fake stylesheet-text-node behavior 
const fake_sheet = {
  data: ''
};

// keep track of all styles inserted so that we don't insert the same styles again
const inserted_styles_cache = {};

function injectStyles(css_string) {
  // create and get the style-tag; return the text node directly
  const stylesheet = getStyleSheet();

  // if already inserted style in the sheet we might ignore this call
  const hasInsertedInSheet = inserted_styles_cache[css_string];
  // these styles need to be inserted
  if (!hasInsertedInSheet) {
    stylesheet.data += css_string; // <-- inserted style in sheet
    inserted_styles_cache[css_string] = true; // <-- mark the insertion
  }
}

function  getStyleSheet() {
  // we aren't in the browser env so our fake_sheet will work
  if (typeof window === "undefined") {
      return fake_sheet;
  }

  const style = document.head.querySelector('#css-in-js');

  if (style) {
    return style.firstChild; // <-- text-node containing styles
  }

  // style doesn't already exist create a style-element
  const styleTag = document.createElement('style');

  styleTag.setAttribute('id', 'css-in-js');
  styleTag.innerHTML = ' ';

  document.head.appendChild(styleTag);

  return styleTag.firstChild; // <-- text-node containing styles
}

🎉 Congratulations with that in place we have created our own CSS-in-JS library. 🎉

As for the keyframes, we can use our css function but with little modifications. Let's see the API and how its use first.

const growAnimationName = keyframes({ // <-- argument is called keyframe-style-object
  from: { transform: 'scale(1)' }, 
  to: { transform: 'scale(2)' },
}); // <-- call to keyframe with style-object returns animation-name. eg: (css-987)

// used as
css({  width: '100px', height: '100px',  animation: `${growAnimationName} 2s ease infinite` });

// compiled as
//  @keyframe css-987 {  
//     from: { transform: scale(1) };
//     to: { transform: scale(2) };
//  }

• Keyframes have a similar API where it takes a keyframe-style-object.
• Keyframes return to the animation name; they are not bound to a class/selector scope.
• The css function only needs an animation name to apply styling which means keyframes need not be in css function style object definition.
• Keyframes are global where keyframe-style-object is stringified and hashed to generate animation name same as in the case generating className from any style-object.
• These names are the only scope of keyframes it is global.
• If you note carefully we never write the @keyframes keyword in the keyframes function call so that is something added internally along with the animation-name.
• This conversion from a keyframe-style-object to style-object can look something like:

// keyframe-style-object
{   
  from: { transform: 'scale(1)' }, 
  to: { transform: 'scale(2)' }
}

// converted style-object
{
  [`@keyframes ${animationName}`]: keyframe-style-object 
}

Adding keyframes support to css function can be done simply by telling css function to treat this css call as a keyframe function call and do the above conversion before parsing the style-object.

// adding one more parameter called `options` 
// this can be used to change the behavior of `css` function and
// it should be an optional parameter.
// changing the name to _css_ to indicate this is not exported and passing
// different values of options can yield different variations of _css_ functions
// to suit different requirements example keyframes

function _css_(styles, options) {
  // ...same no change...

  // in the parsing of the style function call

  parseStyles(
    // style-object
    options.hasKeyframes 
      ? 
        // convertion to valid style-object from a keyframe-style-object
        { [`@keyframe ${className}`]: _style_object_ }
     : 
        _style_object_,
    // selector
    className
  )

  // ...same no change...
}

// final exported function from library
export const css = (style_object) => _css_(style_object, {});
export const keyframes = (style_object) => _css_(style_object, { hasKeyframes: true });

With keyframes in place, we have successfully coded our CSS-in-JS library. So as promised we have created our emotion like library; Note that emotion is way more complex and handles many different edge cases with far better optimizations.

Summary of css function

• css function takes style-object or an array of style-object.
• It stringifies this style-object and generates a unique hashed representational string for it, eg:css-123.
• For the keyframe we convert keyframe-style-object to valid a style-object representation of @keyframe keyword.
• These styles are then parsed. Each property in style-object may be on the of the following At(@) rules, &:hoveri.e multiple nested selector rules or fontSize: '16px' simple CSS properties. Each is dealt with differently as some can be block-scoped while others are global. Self-references using & are also handled here. After the correct parsing, we generate a valid CSS string representation of our style-object.
• This CSS string is added into a stylesheet in DOM and appended to document.head.

And now as for naming this library, I will like to call it - Styler

• Styler GitHub
• Styler Codesandbox
• Why CSS-in-JS?
• CSS: Isolation vs Abstraction

This comes as the result of the global nature of CSS where things are leaky and thus component-based UI architectures find it difficult as cascading and global CSS causes leaks in styles across the components. For example:

<!-- Heading1: Component file; applies styles inside itself. -->
<h1>Some heading</h1>
<style>
    h1 {
        font-size: 32px;
        font-weight: bold;
    }
</style>
<!-- 
 The style inside of Heading1.component.js leaks out to global affecting
 all the h1 tags.
-->

Due to the global nature of CSS, h1 which may be inside the Heading1 component has its own style but due to the global scope of CSS, it leaks out to all h1 on the page. The component style is not scoped to the component itself thus giving birth to solutions like BEM, CSS-in-JS, and CSS Modules, which try to solve this problem by applying styles to scoped class names. For example:

<!-- With BEM Naming convention makes sure that styles are scoped -->
<div class="card">
    <div class="card__title">Title</div>
    <div class="card_actions card__actions--hover">actions</div>
</div>
<style>
    .card {
        width: 100%;
        padding: 16px 24px;
        display: flex;
        flex-direction: column;
    }
    .card__title {
        font-size: 16px;
        font-weight: 600;
    }
    .card_actions {
        display: none;
    }
    .card_actions--hover:hover {
        display: flex;
        flex-direction: row;
        justify-content: flex-end;
    }
</style>

Other solutions like CSS-in-JS solve issues by creating a unique class name, you can read more about it here in “Why CSS-in-JS?” With any such solution made for isolation, there are repetitions of rules seen that do add to size but it also ensures that scope styles and prevents unintentional leaking and we should be assured that modern bundlers are smart and will only ship styles required by the page. Be mindful that CSS growth does happen in a total isolation approach.

Total abstraction

This embraces the global nature of CSS by creating generic, global, and reusable classes called utility or atomic classes. The solutions like tailwind focus on using utility classes for styling and has their own build system for mitigating bundling and order issues. Each utility class remains in code forever and the smart bundlers shake off unused utility classes at build time, this makes sure the rise of CSS in the code is slow as their are utility classes covering most of the declarations and making it reusable so the growth of CSS is slow. For example:

<div class="w-full py-4 px-6 flex flex-col">
    <div class="text-base font-semibold">Title</div>
    <div class="hidden hover:flex hover:justify-end">actions</div>
</div>
<style>
    <!-- utility classes -->
    .w-full { width: 100%; }
    .px-6 { padding-left: 24px; padding-right: 24px; }
    .py-4 { padding-top: 16px; padding-bottom: 16px; }
    .flex { display: flex; }
    .flex-col { flex-direction: column; }
    .text-base { font-size: 16px; }
    .font-semibold { font-weight: 600; }
    .hidden { display: none; }
    <!-- hover:flex is written as .hover\:flex -->
    .hover\:flex:hover { display: flex; }
    .hover\:justify-content { justify-content: flex-end; }
</style>

The above example shows how utility classes are small declarations of a rule that can be composed in an infinite number of ways to achieve many different styles without causing repetitions.

Middle ground

The hard truth is that there is no middle ground, these two are on the opposite sides of the same axis and you cannot choose a middle ground for them. Even if you try your best you will not be able to achieve a middle ground; as the team grows there is always some dev there that will break your well-defined architecture and cause a leak or your CSS will grow or specificity wars will.

We should be hopeful though as efforts are being made to have a middle ground, one such effort is by stylex a Facebook which they presented in React conf and I’m waiting for it to be made open-source to enjoy best of the both worlds.

CSS is global by design! It is that way because we want to bring consistency across the website.

html {
    font-family: Roboto, sans-serif;
}

By writing the above code every text on your website has a font-family set. And this is by design instead of setting font-family on each item.

This very nature of being global and cascading creates problems when styles in parents cascade into children. The problem doesn’t end there the devil called “specificity” in CSS is always there to bring you surprises.

<style>
    #wrapper {
        background-color: green;
    }

    .background-red {
        background-color: red;
    }

    .background-orange {
        background-color: orange;
    }

</style>
// case 1
<div id="wrapper" class="background-orange">
    Box 1
</div>
// case 2
<div  class="background-orange background-red">
    Box 2
</div>

1. As the id has higher specificity over class the background color is green.
2. As the occurrence of background-orange is later in the style so it will override even though in class attribute background-red is used later.

Scoping of CSS per component should solve the global issue of CSS. The scoping CSS problem is solved differently by different technologies.

Web components provide scoping CSS into shadow dom which doesn’t leak anything outside and also doesn’t let other things affect it i.e scoping it into the component and closing at the same time. Frameworks like Vue also have scoped style solutions in place. The web components provide a very strict boundary and sometimes we don’t need such a strict boundary.

The architecture naming of CSS classes using BEM i.e .block_element--modifier tries to solve the issue by following naming conventions but this isn’t absolute there are ways in which scope leaks can happen.

A framework like Vue and Angular has its own way of scoping styles to elements/components built in.

What CSS-in-JS does do for you?

It scopes all the styles into a unique class-name thereby solving the problem of global scope. Now each item has its CSS scoped to a unique class-name.

import { css } from "css-in-js";

function Flex(props) {
    return (
        <div className={css({ display: "flex" })}>
            {props.children}
        </div>
    );
}

In the above code:

• The css function from the CSS-in-js lib takes in style-object
• A style-object is nothing but a way of writing CSS with javascript objects.

.text-center 
// following is how css is declartion is written in a .css file -- 1
{
    text-align: center;
}

// the same object as style-object in javascript is written as -- 2
{
    textAlign: 'center' // split on changed casing then joined by "-" and lowercased
}

• The style-object is converted into a valid CSS declaration and is scoped to a unique class-name and css function then returns that unique class-name.

const uniqClassName = css({ textAlign: 'center' });
// is converted as 
// .css-123 { text-align: center; }

console.log(css({ textAlign: 'center' });  // css-123

• The class-name is cached for the given style-object and whenever the same style is passed { textAlign: 'center' } to css function it will always yield css-123 , this is an optimization step.

• On the problem of specificity, it cannot solve for case-1 because using id for styling indicates poor CSS architecture. For the later case-2 it will solve it as:

css([ 
    { display: 'flex', backgroundColor: 'red' }, 
    // conflicting declarations backgroundColor
    { flexDirection: 'column', backgroundColor: 'orange' } 
])

// styles objects in [] are merged and thus resultant style object is

/*

    {
        display: 'flex',
        flexDirection: 'column',
        backgroundColor: 'orange'
    }

*/

The above solves the specificity by applying the last declaration overriding others that came before it.

Problems with CSS-in-JS

• Repetition of styles. Even though the two style-object vary by a very small bit there is an entirely new class-name for two.

css({ display: 'flex', flexDirection: 'row' })
// .css-1234 {
//   display: flex; // <-- same declaration for display
//   flex-direction: row;         
// }
css({ display: 'flex', flexDirection: 'column' })
// .css-9876 {
//   display: flex; // <-- same declaration for display
//   flex-direction: column;         
// }

If you notice, the two declarations vary only in values of flexDirection values but they will have entire different class-name, this is not a problem as it is by design to have all styles scoped uniquely under a unique class-name but the fact that the property display is repeated means something better can be done.

• We generate a unique class-name for a style-object and as the same structured style-object always returns the same class-name.

const styleObject1 = {
    textAlign: 'center'
};

const styleObject2 = {
    textAlign: 'center'
};

styleObject1 === styleObject2 // false: object ref is diff

css(styleObject1) === css(styleObject2) // true: class-name is same

This can be only achieved by when there is a phase of stringifying the style object followed by hashing to generate a unique name.

JSON.stringify(styleObject1) === JSON.stringify(styleObject2); 
// true: same stringified object value for the same structured object
// now hashing will return the same output as the input 
// JSON.stringify(styleObject1), JSON.stringify(styleObject2) are same

Depending on the logic of stringifying the object the complexity & time may vary.

const object1 = { a: 1, b: 2 }; 
const object2 = { b: 2, a: 1 }; // <-- looks same but structerly different

JSON.stringify(object1) === JSON.stringify(object2) // false: diff structure

And so, depending on the logic of stringifying algorithm we can make object1 and object2 string representations look the same. It may or may not be a concern for lib to output the same class-name for same looking object and that will require some work! Most of the time it won’t be a concern as repeating a few class-name doesn’t matter much, but do note that there is always a hashing step involved usually these are quick and insecure hashing algorithms to optimize for speed.

• When using React with CSS-in-JS there is a cost of injecting styles on every render along with the phase of stringifying to generate a class-name that will happen on every render. The new libraries like stitches and vanilla-extract-css are looking promising by making everything build time process so this is not going to be a problem in future. A framework like tailwind with atomic-css is something that is missing in CSS-in-JS world. I’m hopeful for stylex a Facebook internal atomic CSS-in-JS to provide the best of both world.

• Love for preprocessors and pure CSS is not going to die that easily and it shouldn’t for the fact that CSS-in-JS is not needed for every website or it is just hard for UI-dev to wrap their minds around CSS-in-JS or view-encapsulation may just not be a problem for your project or you CSS architecture (or even using BEM naming convention) may just not have a need for it. Also, CSS itself is evolving and I'm hopeful for a future where scoping will be built into CSS.

Conclusion

The CSS-in-JS library solves problems of global nature of CSS and of specificity by providing scoping in a unique class-name. It has some cost attached to it i.e run-time which is being solved by order libs vanilla-extract-css. I'm a big fan of tailwind and I honestly believe it is enough for your project. If you also need dynamic styles then CSS-in-JS is better over tailwind, though there are solutions like twind which provide a flavor of tailwind with the CSS-in-JS approach they do have all cons of any CSS-in- JS libraries. I'm very excited about styles by Facebook and waiting for the day it will be open-sourced or CSS itself evolves to me provide scoping and be more modular, until that day comes I'm betting on CSS-in-JS with stitches and vanilla-extract-css.

Question: Make a input box that accepts digits and spaces only. Also, care for copy-paste (Ctrl +V ) of invalid characters.

The first step is to register an event on the input tag. But what event type? 🤔 We are typing characters into it so keypress the event looks fine.

<input type="text" id="input"/>

const input = document.getElementById('input');  
var currentInputValue = '';  
input.addEventListener('keypress', function inputKeypressHandler(e) {  
    // keypress event on input box is listened here and this function is triggered  
    // which key is pressed, keyPressed = e.which || e.keyCode;   
    const key = e.which || e.keyCode;  
    // key code corresponds to digits 0-9 or space then okay👍🏼  
    // 0-9 key code is 48-57  
    // space keycode is 32  
    const SPACE = 32; // May be just stored somewhere  
    const ZERO = 48;  
    const NINE = 57;  
    // valid digit is b/w 0-9 thus invalid will be lt 0 or gt 9  
    const isNotValidDigit = key < ZERO || key > NINE;  
    // if key is not a space or not a digit prevent this event  
    if (key != SPACE || ( isNotValidDigit ) ) {  
        e.preventDefault();  
    }  
});

This is a pretty good solution but this doesn’t prevent paste cheats. And that is because the keypress event only records key pressed inside the input box. A better event type is required. input it runs on all input ways including copy paste and drag.

var currentInputValue = '';  
input.addEventListener('input', function inputInputEventHandler(e) {  
    // use target of event to get value of input  
    const target = e.target;  
    // we can use regex to check if current input value  
    // is valid input  
    const DIGITS_SPACE_REGEX = /^[0-9\s]*$/;  
    // test if target.value or value of input box now is valid.  
    // if value is valid then update currentInputValue   
    // target.value else its is not value and we will  
    // ignore this target.value and replace it with   
    // previously valid value currentInputValue  
    DIGITS_SPACE_REGEX.test(target.value)   
        ? ( currentInputValue = target.value )   
        : ( target.value = currentInputValue );  
});

This solves our problem of paste but there is one problem here. Say you paste something Ctrl/Cmd + V your current cursor position will be lost and moved to starting. This must not happen and you must be able to retain cursor position.

// Track cursor position  
// cursor position is changed when you type something  
const cursorState = {};  
input.addEventListener('keydown', function inputKeydownHandler(e) {  
    const target = e.target;  
    // record the start and end  
    cursorState.selectionStart = target.selectionStart;  
    cursorState.selectionEnd = target.selectionEnd;  
});

now in input handler

// modify  
DIGITS_SPACE_REGEX.test(target.value)   
        ? ( currentInputValue = target.value )   
        : ( target.value = currentInputValue );  
 // to  
 if (DIGITS_SPACE_REGEX.test(target.value)) {  
     currentValue = target.value;  
 }  
 else {  
    target.value = current.value;  
    // restore cursor state  
    target.setSelectionRange(  
        cursorState.selectionStart,  
        cursorState.selectionEnd  
    );  
 }

Demo 👨‍💻

const name = "aniket";
name.toUpperCase(); // ANIKET

The name is a primitive but we are able to access a method on it as if it were some sort of object. But we know that primitive isn’t an object.
What is the story here?🧐

Primitive are simple values stored in memory, those are lightweight and extremely fast. Whereas an object is a collection of the key, value pairs, it is heavy but it allows to access some utility properties associated with the object that is very useful. The javascript people faced the dilemma where they wanted to put primitive for being lightweight and fast but also wanted to allow access useful methods on primitives.

The solution the came up with was:

As soon as the engine reaches line 2 it sees that you are trying to do property access on primitive, but as primitive itself doesn’t have methods on them. It momentarily wraps the primitive value into a corresponding type wrapper object that has these methods on them and that object exposes us the properties which we can use, as soon as the method is done executing it returns the result of the operation in a new memory space and deletes this wrapper object.

Constructors function

The constructor function String, Number, Boolean is for internal use only. Languages like Java allows us to explicitly creates a wrapper object that is also possible with JavaScript but those are not recommended and are for internal use only. A lot of things can go crazy if we use those.

// Insane Use 🙅‍♂️ Not recommended
const age = new Number(22);
typeof age; // "object" 😱
// Sane Use 😍
const age = Number("22");
// explicit type conversion

Recap with a question

Explain the console output in strict and non-strict mode?

const name = "Aniket";
name.last = "Jha";
console.log(name.last);

In strict mode on line 2, the engine sees that we are trying to create a property on internal momentarily created internal wrapper object so there occurs an error. For a non-strict mode the engine on line 2, allows you to create a property on momentarily created wrapper object but this object is thrown out of memory as soon as line 2 is done executing. On line 3 a new wrapper object is created momentarily but as this is different from previous it doesn't have thelastproperty and thus undefined is the output.

Conclusions

The primitive is indeed a simple value but the engine treats primitive especially if it sees there is property access on it by wrapping it in wrapper object and exposing us with useful methods and properties.

In this example, we are going to load a list of todos. Here we are using react-redux as a state management solution. Below we will see how to create a store and reducer with react-redux. However, you can directly skip to "loadables" if you familiar with react-redux-context store.

Create react-redux context store

Let's start by creating a react-redux-context-store for storing our todos. The following sample is taken from react-redux.

// [filename: todo.store.jsx]

import React from 'react'
import {
  Provider,
  createStoreHook,
  createDispatchHook,
  createSelectorHook,
 from "react-redux";
import { createStore } from "redux";
// reducer for the state
import { reducer } from "./store.reducer"

// react context store
const TodoContext = React.createContext(null)

// create redux state selector and dispatch from context
export const useTodoStore = createStoreHook(TodoContext)
export const useTodoDispatch = createDispatchHook(TodoContext)
export const useTodoSelector = createSelectorHook(TodoContext)

// create redux store from the reducer
const todoStore = createStore(reducer)

// create store provider wrap subtree
export function TodoStoreProvider({ children }) {
  return (
    <Provider context={TodoContext} store={todoStore}>
      {children}
    </Provider>
  )
}

After creating a store provider we are going to create store.reducer.js where we define the reducer and actions for the store.

// [filename: todo.reducer.js]

export const loadNext = () => ({ type: 'load_next' });
export const addTodos = ({ todos, total }) => ({ type: 'add_todos', payload: { todos, total } });
export const setLoading = (loading) => ({ type: 'set_loading', payload: { loading }  });

const InitState = {
 status: 'idle', // idle | pending | resolve | reject 
 todos: [],
 total: 0,
 skip: 0,
 limit: 10
};

export const reducer = (state = InitState, action) => {
  switch (action.type) {
    case 'load_next': {
       if (state.todos.length < state.total && state.status !== 'pending') {
          return {
             ...state,
             status:  'pending'
          };
       }
       return state;
    }
    case 'add_todos': {
      return {
          ...state,
          status: 'resolve',
          todos: [...state.todos, ...action.payload.todos],
          total: state.total + action.payload.todos.length 
      };
    }
    case 'set_loading': {
      return {
          ...state,
          status: action.payload.loading
      };
    }
    default: {
      return state;
    }
  }
};

Loadable

Loadables are react components that wrap all data loading logic in it and update the store.

// [filename: App.js]

const App = () => (
  <div>
    <TodoStoreProvider>
      {/* Loadable holds all data loading logic*/}
      <TodoLoadable>
        {/* Render todos */}
      </TodoLoadable>
     </TodoStoreProvider>
   </div>
 );

Now let's create a loadable:

// [filename: Todo.loadable.js]

function TodoLoadable(props) {
  // react-redux state slice selector
  const skip = useTodoSelector((state) => state.skip);
  const limit = useTodoSelector((state) => state.limit);
  const todoDispatch = useTodoDispatch();
  // load data
  useEffect(() => {
    todoDispatch(setLoading('pending'));
    api({ skip, limit })
      .then((res) => todoDispatch({ todos: res.todos, total: res.total }))
      .catch((e) => todoDispatch(setLoading('reject')));
  }, [skip, limit]);
  // render child
  return <>{props.children}</>
}

The point to note here is that the loading logic is completely placed inside the loadable and the children can utilize the store to sync UI state accordingly. IsVisible is a utility component that can be used to render things conditionally.

// [filename: IsVisible.utility.jsx]

function IsVisible({ visible, unmountOnExit, ...props }) {   
  if (unmountOnExit && !visible) {
    return null;
  }
  return <div {...props} style={{  ...props.style, display: visible ? 'flex' : 'none'  }} />
}

We can use the IsVisible utility component to create state synced UI.

// [filename: Todo.jsx]

const Error = () => <div><h1>Error</h1></div>;
const Loader = () => <CircularProgress size="small" />
const Todos = () => {
  const todos = useTodoSelector((state) => state.todos);
  return <div>{todos.map((todo) => <h1>{todo}</h1>)}</div>
}

function IsErrorVisible(props) {
  const isError = useTodoSelector((state) => state.status === 'reject');
  return <IsVisible {...props} visible={isError} />
}

....more IsVisible for all API status 'reject' | 'resolve' | 'pending' | 'idle'

Now with the help of this IsVisible, we can render UI according to the state of API.

// [filename: App.js]

const App = () => (
  <div>
    <TodoStoreProvider>
      {/* Loadable holds all data loading logic*/}
      <TodoLoadable>
        <IsErrorVisible><ErrorUI /></IsErrorVisible>
        <IsTodoVisible><Todos /></IsTodoVisible>
        <IsLoaderVisible><Loader /></IsLoaderVisible>
      </TodoLoadable>
     </TodoStoreProvider>
   </div>
 );

This is how loadable along with IsVisible utility makes it super easy to load data in react and make a code simple to write and understand. Here is a link to demo Codesandbox.

With this comes using useMemo and useCallback which you may use for memoized computational values, functions, and handlers. This adds to overall code complexity and you may end up running more code for React to determine changed values, compare them and memoize them. Sometimes this might be the only solution but there are approaches that you can try before you memoize things.

Consider the following code sample:

import React, { useState } from "react";

// [App.js]
function App() {
  const [name, setName] = useState('');
  return (
    <div>
      <input type="text" value={name} 
        onChange={(e) => setName(e.target.value)} />
      <SlowSubtree />
    </div>
  );
}

function SlowSubtree() {
  sleep(500); // try increasing time here 💣
  return <p>Artifically Slow subtree</p>;
}

// [utils.js]
function sleep(time) {
  const exitAt = Date.now() + time;
  while (exitAt > Date.now()) {
    // simulate expensive subtree
  }
}

In the code example, we have artificially simulated an expensive sub-tree with <SlowSubtree /> component. Which gets re-rendered on a change in input. As we type in input we set the name state thus causing a re-render of the App component, which then renders <SlowSubtree />. The quick fix here is wrapping SlowSubtreecomponent in a React.memo as shown below:

import React, { memo } from "react";

// [App.js]
function SlowSubtreeComponent() {
  sleep(500);
  return <p>Artifically Slow subtree</p>
}

const SlowSubtree = memo(SlowSubtreeComponent);

React.memo() is a quick fix but can we avoid using it? Following are some approaches:

Debounce set-state

In the example, we are setting the name state with every keystroke and causing re-rendering each time input changes, setting the state on every keystroke is wastage here. What we can do is we can debounce set state calls to prevent rendering with each keystroke. I consider this as a bit of a hacky approach but I’ve put this here to bring this to your notice.

import React, { 
  useState, 
  useMemo, 
  useLayoutEffect, 
  useRef 
} from "react";

// [App.js]
function App() {
  const [name, setName] = useState('');
  const debounceOnChange = useDebounceFn(
    (e) => setName(e.target.value)
  );

  return (
    <div>
      <input type="text" onChange={debounceOnChange} />
      <SlowSubtree />
    </div>
  );
}

function SlowSubtree() {
  sleep(500); // try increasing time here 💣
  return <p>Artifically Slow subtree</p>;
}

// [utils.js]
function sleep(time) {
  const exitAt = Date.now() + time;
  while (exitAt > Date.now()) {
    // simulate expensive subtree
  }
}

// [hooks.js]
import debounce from "lodash.debounce";

function useDebounceFn(callbackFn, delay = 500) {
  const callbackFnRef = useRef(callbackFn);

  useLayoutEffect(() => {
    callbackFnRef.current = callbackFn;
  });

  return useMemo(
    () => debounce(
       (...args) => callbackFnRef.current(...args), delay),
    [delay]
  );
}

State relocation

Note that the SlowSubtree the component renders because of a state change in the parent component. The changing part here is name state with <input/> while SlowSubtree is not changing. We can split and move state down in its separate component like shown below:

import React, { useState } from "react";

// [App.js]
function App() {
  const [name, setName] = useState('');
  return (
    <div>
      <NameInput />
      <SlowSubtree />
    </div>
  );
}

function NameInput() {
  const [name, setName] = useState('');
  return  (
    <input 
      type="text" 
      value={name} 
      onChange={(e) => setName(e.target.value)} 
    />
  );
}

function SlowSubtree() {
  sleep(500); // try increasing time here 💣
  return <p>Artifically Slow subtree</p>;
}

// [utils.js]
function sleep(time) {
  const exitAt = Date.now() + time;
  while (exitAt > Date.now()) {
    // simulate expensive subtree
  }
}

Render as a child

It is not required to move the state down in its own NameInput component we can also move the state up and leverage a pattern called render as child. This pattern is very similar to the render props approach but instead of passing components to a render prop, we use props.children instead. Here we will lift the state up in its own component and wrap SlowSubtree component with it.

import React, { useState } from "react";

// [App.js]
function App() {
  return (
    <NameComponent>
      <SlowSubtree />
    </NameComponent>
  );
}

function NameComponent(props) {
  const [name, setName] = useState('');
  return (
    <div>
      <input 
         type="text" 
         value={name} 
         onChange={(e) => setName(e.target.value)} 
       />
      {props.children}
    </div>
  );
}

function SlowSubtree() {
  sleep(500); // try increasing time here 💣
  return <p>Artifically Slow subtree</p>;
}

// [utils.js]
function sleep(time) {
  const exitAt = Date.now() + time;
  while (exitAt > Date.now()) {
    // simulate expensive subtree
  }
}

When name state changed NameComponent re-render but as it still gets the same children prop as last time so React doesn’t need to visit SlowSubtreesubtree. And as a result <SlowSubtree /> doesn’t re-render.

I have personally used this approach many times to prevent the re-rendering of child subtree. This pattern is also used in layout components where the wrapper decided the layout and styles of its children. For example Material-UI Card component. The layout component may or may not maintain the state but they generally receive the child as a prop or render-props.

Conclusion:

Before you use a React.memo() or useMemo() again you should stop and think to see if you can split part that changes from the parts that don’t change. So take into account if state relocation can help before you settle with the memo.

I have been using CSS-in-JS for most of my projects and I’m in love with it but over time CSS has improved, the browsers have matured and support for CSS is better than before. The cost of implementing theme switching with CSS-in-JS libraries is considerably more than using browser standard CSS variables.

Let’s take the example of CSS-in-JS theme switching.

import { jsx, ThemeProvider } from "@emotion/react";
import styled from "@emotion/styled";
import { useState } from "react";

const themes = {
  light: {
    colors: {
      primary: "#48ff00",
      background: "#fff"
    }
  },
  dark: {
    colors: {
      primary: "#ff0000",
      background: "#000"
    }
  }
};

const Heading1 = styled.h1(({ theme }) => ({
  color: theme.colors.primary,
  backgroundColor: theme.colors.background
}));

const Paragraph = styled.p(({ theme }) => ({
  color: theme.colors.primary,
  backgroundColor: theme.colors.background
}));

const Div = styled.div(({ theme }) => ({
  backgroundColor: theme.colors.background
}));

const Button = styled.button(({ theme }) => ({
  color: theme.colors.primary,
  backgroundColor: theme.colors.background
}));

export default function App() {
  const [isLight, setIsLight] = useState(true);
  const activeTheme = isLight ? "light" : "dark";

  return (
    <ThemeProvider theme={themes[activeTheme]}>
      <Div>
        <Div>
          <Button onClick={() => setIsLight((prev) => !prev)}>
            {activeTheme}
          </Button>
        </Div>
        <Heading1>CSS In JS</Heading1>
        <Paragraph>
          Emotion is a library designed for writing css 
        styles with JavaScript. It provides powerful 
        and predictable style composition in addition 
        to agreat developer experience with features 
        such as source maps, labels,and testing utilities. 
        Both string and object styles are supported.
        </Paragraph>
      </Div>
    </ThemeProvider>
  );
}

That’s the beauty of CSS-in-js it’s just javascript. The developer experience is pretty amazing with such API. However the user experience takes a hit when there are many components on the page, so switching the theme takes a while sometimes a noticeable delay. This leads to a poor user experience which is bad for our brand and business. Here is codesandbox for the CSS-in-JS example.

Now let’s do it with CSS variables.

import { jsx } from "@emotion/react";
import styled from "@emotion/styled";
import { useState, useEffect } from "react";
import "./theme.css";

/*
  theme.css

  body[data-theme="light"] {
    --color--primary: #48ff00;
    --color--background: #fff;
  }

  body[data-theme="dark"] {
    --color-primary: #ff0000;
    --color-background: #000;
  }
*/

const Heading1 = styled.h1({
  color: "var(--color-primary)",
  backgroundColor: "var(--color-background)"
});

const Paragraph = styled.p({
  color: "var(--color-primary)",
  backgroundColor: "var(--color-background)"
});
const Div = styled.div({
  backgroundColor: "var(--color-background)"
});

const Button = styled.button({
  color: "var(--color-primary)",
  backgroundColor: "var(--color-background)"
});

function ThemeToggler() {
  const [isLight, setIsLight] = useState("light");

  useEffect(() => {
    document.body.dataset.theme = isLight ? "light" : "dark";
  }, [isLight]);

  return (
    <Button onClick={() => setIsLight((prev) => !prev)}>
      {isLight ? "light" : "dark"}
    </Button>
  );
}

export default function App() {
  return (
    <Div>
      <Div>
        <ThemeToggler />
      </Div>
      <Heading1>CSS Variable</Heading1>
      <Paragraph>
        Emotion is a library designed for writing css 
        styles with JavaScript. It provides powerful 
        and predictable style composition in addition 
        to agreat developer experience with features 
        such as source maps, labels,and testing utilities. 
        Both string and object styles are supported.
      </Paragraph>
    </Div>
  );
}

Here the developer experience may suffer because of loss of static typing on theme object but the user experience is considerably better. Also, a developer doesn’t need to learn API styled.button(({**theme**}) => ({ ...styles })) where we create a function accepting theme and returning styles. Here is a link to codesandbox.

React profiler matrix⚛️

CSS-in-JS way of theme switching

CSS-in-JS way of theme switching

CSS variables of theme switching

CSS variable way of theme switching

By seeing the above two screenshots it is very clear that using CSS variable is better than using CSS-in-JS way. A better developer experience can be achieved by a hybrid of two. Following gives you the ability for static type on theme object as theme.colors.primary.

import { jsx } from "@emotion/react";
import styled from "@emotion/styled";
import { useState, useEffect } from "react";
import { theme } from "./theme";
import "./theme.css";
/*
  theme.css

  body[data-theme="light"] {
    --color--primary: #48ff00;
    --color--background: #fff;
  }

  body[data-theme="dark"] {
    --color-primary: #ff0000;
    --color-background: #000;
  }
*/

/*
  theme.js
  export const theme = {
    colors: {
      primary: "var(--color-primary)",
      background: "var(--color-background)"
    }
  };
*/

const Heading1 = styled.h1({
  color: theme.colors.primary,
  backgroundColor: theme.colors.background
});

const Paragraph = styled.p({
  color: theme.colors.primary,
  backgroundColor: theme.colors.background
});

const Div = styled.div({
  backgroundColor: theme.colors.background
});

const Button = styled.button({
  color: theme.colors.primary,
  backgroundColor: theme.colors.background
});

function ThemeToggler() {
  const [isLight, setIsLight] = useState("light");

  useEffect(() => {
    document.body.dataset.theme = isLight ? "light" : "dark";
  }, [isLight]);

  return (
    <Button onClick={() => setIsLight((prev) => !prev)}>
      {" "}
      {isLight === "light" ? "dark" : "light"}
    </Button>
  );
}

export default function App() {
  return (
    <Div>
      <Div>
        <ThemeToggler />
      </Div>
      <Heading1>CSS var and CSS in JS</Heading1>
      <Paragraph>
        Emotion is a library designed for writing css 
        styles with JavaScript. It provides powerful 
        and predictable style composition in addition 
        to agreat developer experience with features 
        such as source maps, labels,and testing utilities. 
        Both string and object styles are supported.
      </Paragraph>
    </Div>
  );
}

Conclusion

CSS-in-JS is awesome but it comes with the cost of injecting styles with every render and theme switching using ThemeContext is not performant especially if there are a large number of components on a screen. Theme switching is very performant with CSS variables. Let’s use more CSS variables to develop awesome web apps themes.

Credit: Image by ailonwebs.com

Reflect helps in the creation of Proxy and somewhat allows us to play with internal methods [[Get]] and [[Set]]. Below are some reflect methods:

Let us look at a code example:

let user = {};

Relect.set(user, 'name', 'Aniket Jha'); // [[Set]]

console.log(user.name); // Aniket Jha

Reflect allow us to call operators as functions also there is a reflect method for any proxy traps having the same name and arguments.

let user = {};

user = new Proxy(user, {
  get(target, prop, receiver) {
    console.log(`GET Trap > Target: ${target} Prop ${prop} Receiver ${receiver}`);
    return Reflect.get(target, prop, receiver);
  },
  set(target, prop, value, receiver) {
    console.log(`SET Trap > Target ${traget} Prop ${prop} Value ${value} Receiver ${receiver}`);
    return Relect.set(target, prop, value, receiver);
  },
});

The Reflect methods work nicely with proxy to ensure that traps output and what we expected is the same. Following is an example:

let user = {
  _name: 'User',
  get name() {
    return this._name;
  }
};
let proxyUserObj = new Proxy(user, {
  get(target, prop) {
    return target[prop]; // Note we didn't used reflect here.
  },
});
let admin = {
  __proto__: proxyUserObj,
  _name: 'Admin'
};
console.log(admin.name); // Admin or User 🤔 
// admin.name ?
// `name` is not found on admin obj
// so it will go up in prototype chain
// Note prototype chain is proxyfied object `proxyUserObj`
// it finds `name` property(getter property) on `proxyUserObj`
// resolving for name property trigger proxy `get trap`
// the arguments that are passed to proxy get trap
// target => user
// prop => 'name'
// as trap return traget[prop] i.e user['name'] so `this === user`
// and returned value is `User` 😱 which was not expected
// to prevent it from happening `receiver` argument is requried
// and we can leave it to `Reflect.get(target, props, receiver)` to
// correctly resolve properties for us.

We saw an example of how Reflect is useful for dealing with this Proxy gotcha. I always writereturn Reflect.get(…arguments); 😎. Reflect is awesome to enhance proxy and use it correctly. More on proxy on MDN.

Proxy

Syntax: let proxy = new Proxy(target, handler);

target: the object that has to be proxied.
handler: the proxy configuration object, it may register traps. A trap is a handler for a particular kind of operation. By registering a trap handler it can intercept the operation and do its own thing.

If there is a trap for the operation onhandler only then the operation will be trapped and handled by proxy else operation directly occurs on the object itself.

let user = {}; 
// target object -- object to be proxied
let userProxy = new Proxy(user, {}); 
// proxy for user, note empty handler

// operations on proxy
userProxy.name = 'Aniket'; 
// set operation
// should be intercepted by
// `set` trap on handler
// no `set` trap registerd so 
// operations are performed on object itself 
console.log(userProxy.name); // 'Aniket;
// get opertaion
// should be intercepted by `get` trap
// no `get` trap registerd so opertaion 
// is performed on object directly
console.log(user.name); // 'Aniket'
// Thus we can see name property 
// directly on target itself

For most of the operations on objects, there are “Internal Methods” in JavaScript that describes how operations work at a low level, what proxy trap does is that it can intercept these methods and do its own thing.

Below we show some of the “Internal Methods” and their corresponding proxy traps.

Internal Methods have some rules that our traps must follow, for eg: set the trap must return true if property setting was success else false.[[GetPrototypeOf]] must always return the target’s prototype when applied on proxy as well.

The problem statement

It is common practice to use *_* is in the beginning of the property name to denote a private property. You cannot get/set/loop this property. Write a proxy to achieve this.

let user = {
  name: 'Aniket',
  _password: 'Password', // private property
  isCorrectPassword(pswd) {
    return this._password === pswd;
    // `this` here is a gotcha
  },
};

“set” trap

We will register a set trap on the handler to intercept write operation on the object.

Syntax: set(target, prop, value, receiver).

target : target object.
prop : property name that is being set.
value : the value of the property to be set.
receiver : the object that is utilised as in getters.

let userProxy = new Proxy(user, {
  set(target, prop, value, reciver) { 
    // intercepts property write
    if (prop.startsWith('_')) {
      // check if property name start with `_`
      // then it is a private property so
      // don't allow to write or create a property
      throw new Error("Access denied 💣 ");
    } else {
      target[prop] = val;
      // normally write on object
      return true; // must return true [[Set]] rule
    }
  }
});

“get” trap

We will register a get trap to prevent direct access user._password to private property. Also, we have to ensure that isCorrectpassword works correctly as it does indirect access this._password.

Syntax: get(target, property, receiver).
The arguments mean the same as above.

let userProxy = new Proxy(user, {
  get(target, prop, receiver) {
    // intercept property read
    if (prop.startsWith('_')) {
      // if property name starts with `_` then
      // we don't allow to read and raise an error
      throw new Error("Access denied 💣 ");
    } else {
      // the property value may be a function or something else
      let propValue = target[prop];
      // in case it is a function
      // it may have `this` inside it
      // where `this` will ref to `userProxy` 
      // as it will be invoked as `userProxy.isCorrectPassword(pswd)` 
      // so `this == userProxy` but that will 🔥 our code
      // so we need to make sure that our function `this` ref `user`
      // and so we bind it
      return (
        typeof propValue === "function" 
          ? propValue.bind(target) : propValue
      );
    }
  }  
});

“deleteProperty” trap

We will register deleteProperty so that we can't delete a private property.
Syntax: deleteProperty(target, property)

let userProxy = new Proxy(user, {
  deleteProperty(target, prop) {
    // deleteProperty trap to handle property delete
    if(prop.startsWith('_')) {
      throw new Error("Access denied 💣 ");
    } else {
      // delete property on object
      delete target[prop];
      return true; // successfully deleted
    }
  }
});

“ownKeys” trap

for..in, Object.keys, Object.values and other methods utilise an “Internal Method” called [[OwnPropertyKeys]] to get a list of keys. For eg:
Object.getOwnPropertyNames() to get a list of non-symbol keys,
Object.getOwnPropertySymbols() to get a list of symbol keys,
Object.keys() to get a list of non-symbol enumerable keys, etc.

They all call [[OwnPropertyKeys]] but tweak it a bit to return keys according to their use case. So we will register ownKeys(target) trap to return only public keys.

let userProxy = new Proxy(user, {
  ownKeys(target) {
    // ownKeys will return a list of keys
    // we must get keys on target then filter
    // to remove all private keys
    return Object.keys(target).filter((key)=>!key.startsWith('_'));
  }
});

Note: Our traps must follow the rules defined for “Internal Method”. The rule defined for ownKeys with Object.keys() is that it must return non-symbol enumerable keys. Look at the example below to understand this gotcha.

let userProxy = new Proxy(user, {
  ownKeys(target) {
    // this will return list of keys 
    // and the calling method (Object.keys) tweak this list
    // to select and return a list of 
    // non-symbolic and enumberable: true keys
    // thus for each item in list returned by ownKeys
    // it will only select item which is 
    // non-symbolic and enumberable: true
    return ['email', 'phone'];
  }
});
console.log(Object.keys(userProxy)); // [] empty 😱 gotcha

// solution 
let userProxy = new Proxy(user, {
  ownKeys(target) {
    // Object.keys will check property descriptor
    // for each key returned by ownKeys and see if
    // enumberable: true
    return ['email', 'phone'];
  },
  getOwnPropertyDescriptor(target, prop) {
    // checking for enumberablity of keys
    // is accessing its descriptor and seeing
    // if enumberable is true
    // here we are returning descriptor obj
    // with enumberable true in all cases
    return {
      enumerable: true,
      configurable: true,
    };
  }
});

“has” trap

This trap work with the in operator that intercepts the [[hasProperty]] Internal Method. Let’s register a has(target, property) trap.

let range = {
  from: 1,
  to: 10,
};
// we need to check if 5 in range
// 5 in range if 5 >= range.from && 5 <= range.to
let rangeProxy = new Proxy(range, {
  has(target, prop) {
    // 5 >= 1 && 5 <= 10
    return prop >= target.from && prop <= target.to;
  },
});
console.log(5 in rangeProxy); // true

“apply” trap

Until now all examples we have seen were on objects and now we will see an example of function as target.

Syntax: apply(target, thisArgs, args).
thisArgs : it is the value of this
args : it is a list of arguments for function

// Let us write a function `delay`
// that delay exceution of any 
// function `f` by `ms` milliseconds


// solution 1 closure way
function delay(f, ms) {
   return function (name) { // *
    setTimeout(() => f.bind(this, arguments), ms);
   }
}

var hi = (name) => {
  console.log('Hi! ' + name);
};
console.log(hi.length); // 1
// function.length returns number a params 
hi = delay(hi, 3000);
// hi is now function at line *
console.log(hi.length); // 0 😱
// we lost orignal hi function 
// and function at line * has no params so 0 
hi('Aniket'); // 'Hi! Aniket'
// runs after 3s

// solution 2 proxy way
function delay(f, ms) {
  return new Proxy(f, {
    apply(target, thisArgs, args) {
      setTimeout(() => target.bind(thisArgs, args), ms);
    }
  });
}
var hi = (name) => {
  console.log('Hi! ' + name);
};
console.log(hi.length); // 1
hi = delay(hi, 3000);
console.log(hi.length); // 1 😎
hi('Aniket'); // 'Hi! Aniket'

The End

Now teach the Proxy you learnt here to your friend for whom you have put proxy 😂. Here is the next part of the post Part 2. Stay tuned for more content.

In this article, we will exploit methods like array.map() to produce non-mutating versions. This is not an exhaustive listing, we will keep ourselves limited to basic manipulations.

I will assign array to const to show non-mutating aspect and let as mutating.

Though you can always mutate array assign to const but I like to it that way keep for developer indication.

Add: Mutating

The easiest way to add an item to array is array.push() and array.unshift().

// Note: using `let` here to indicate that this array will be mutated.

let array = [1, 2, 3, 4, 5];  
array.push(6); // [1, 2, 3, 4, 5, 6];  
array.unshift(10);// [10, 1, 2, 3, 4, 5, 6];

array.push() adds an item to the end and array.unshift() adds an item to the front of the array.

Add: Non-Mutating

There are two ways to do so array.concat() and …array spread operator.

// Note use `const` to indicate that this will not be mutated  
// concat
const array1 = [1, 2, 3, 4, 5];  
const array2 = array.concat(6);  // [1, 2, 3, 4, 5, 6];
// spread
const array3 = [...array1, 6]; // [1, 2, 3, 4, 5, 6];  
const array4 = [10, ...array1]; // [10, 1, 2, 3, 4, 5];

array1.concat(item1, item2, …) the concat method will merge all items from array1 and items passed as params and create a new array with them. While the … spread operator will essentially take all items out from array and place them in a new array context.

Remove: Mutating

There are two methods array.pop() and array.shift()

let array = [1, 2, 3, 4, 5];  
array.pop();  // [1, 2, 3, 4] > delete from end and return deleted item  
array.shift();  // [2, 3, 4]  > delete from front and return deleted item

array.pop() delete an item from the end and return deleted item. array.shift() delete an item from the front and return deleted item.

There is one important method to manipulate array i.e array.splice(). It mutates the array. splice() takes 2 important params, first being the starting index and second being the number of items to be removed. splice will remove items from array directly. for eg. splice(0, 2) will remove two items starting from index 0.

let array = [1, 2, 3, 4, 5];  
array.splice(0, 2); // [3, 4, 5];

Remove: Non-Mutating

The removing or any type of filtering is done by array.filter(), the filter() is among the coolest non-mutating method on the array. It takes a function that is called over each item in the array during that it has to do some filtering where if it returns true then the item will be included in new array and return false if items has to be thrown away.

const array1 = [1, 2, 3, 4, 5];  
const array2 = array1.filter((item) => item !== 5);   
// will filter any item i.e not equal to 5

Another very important method is array.slice(). Remember this is not array.splice(), they are different array.slice() will return new array i.e its is not mutating. It is very similar to slice for how its is used. It takes 2 important params, the first is starting index where copying should begin and second is end index where copy should end, it is not inclusive. It copy items between those index and returned them in a new array.

const array1 = [1, 2, 3, 4, 5];  
const array2 = array1.slice(0, 2); // [1,2];  
// if no args provided ti  will copy the whole array

Replace: Mutating

Array splice method is very interesting method because not only it can remove items but also add items to the array directly. The third parameters and onwards basically mean items that need to be inserted to array.

let array = [1, 2, 3, 4, 5];  
array.splice(2, 1, 10, 12); // [1, 2, 10, 12, 4, 5];

splice will remove 1 item starting index 2 and then insert 10 and 12 from the same position.

Replace | Transform: Non-mutating

The mighty method array.map() is very useful as it can transform array. Map method takes a function that is called on each item of the array and it must return an item that has to be put into the new array.

const array1 = [1, 2, 3, 4, 5];  
const array2 = array1.map((item) => {  
  if (item === 3) {  
    return 10;    
  }  
  return item;  
}); // [1, 2, 10, 4, 5];

// Map as transformation  
const mutilpliedByTwo = array1.map((item) => item \* 2);   
// [2, 4, 6, 8, 10];

nvm use 12 // install version 12 - latest@2019  
npm install -g expo-cli // install expo cli globally  
expo init // create a project  
// choose the javascript project with navigation setup

Final product demo

Scanner Screen

In the app, as I am using the minimal setup project I am using the default HomeScreen as ScannerScreen. We are using a React class component you may simply use functional components with hooks for state management.

The Scanner screen is a class-based component. The state has two important properties one hasCameraPermissions for if the screen has permission to access the camera and the second property isisScanned for if something has been scanned or not. Initially, the state of ScannerScreen for hasCameraPermissions is null. Null means that we are requesting for permission. And state isScanned is false means nothing is scanned as of now.

As the scanner requires camera permission thus we need to ask for camera permission from the user.
Permission is an asynchronous task and we must ask for permission as soon as this component is mounted so componentDidMount seems like a good place to start. Note Permission asking is asynchronous so we have to make componentDidMount a async function. If Camera permission is given then hasCameraPermissions is set to true and we may successfully render our barcode scanner and open camera else if permission is declined *hasCameraPermissions* is set to false and we render declined permission message.

Next, we have a function for handling a successfully scanned barcode. If the bar code is scanned this function will be called. Our function *handleBarCodeScanned* is passed as callback to *onBarCodeScanned* prop on *BarCodeScanner* component. In *handleBarCodeScanned* function we receive a scan object as an argument which has two important properties, one is the *type* which means what type of bar code was scanned and the other is *data* which is the encrypted data in our barcode. We will destructure these properties as others are irrelevant to us. In our case of *handleBarCodeScanned* function, we are just navigating to the *DecodeScreen* passing code data as params. The DecodeScreen then displays the data.

import React from 'react';


import { Container, Spinner, TextH3 } from "../UI";

import * as Permissions from 'expo-permissions';

import { BarCodeScanner } from 'expo-barcode-scanner';

import {window} from "../constants/Layout";

class ScannerScreen extends React.Component{
  static navigationOptions = {
    header: null
  }
  // Component State
  state = {
    hasCameraPermission: null, // if app has permissions to acess camera
    isScanned: false // scanned
  }
  async componentDidMount() {
    // ask for camera permission
    const { status } = await Permissions.askAsync(Permissions.CAMERA);
    console.log(status);
    this.setState({ hasCameraPermission: status === "granted" ? true : false });
  }


  handleBarCodeScanned = ({ type, data }) => {
      // Do something here
      this.props.navigation.navigate('Decode', {
        data: data 
      });
  }
  render(){
    const { hasCameraPermission, isScanned } = this.state;
    if(hasCameraPermission === null){
      // requesting permission
      return (
        <Spinner />
      );
    }
    if(hasCameraPermission === false){
        //permission denied
      return ( 
        <Container>
         <TextH3>Please grant Camera permission</TextH3>
        </Container> 
      )
    }
    if(hasCameraPermission === true && !isScanned && this.props.navigation.isFocused() ){
      // we have permission and this screen is under focus
      return <Container style = {{
        flex: 1,
        flexDirection: 'column',
        justifyContent: 'center',
        alignItems: 'center'

      }}>
        <TextH3>Scan code inside window</TextH3>
        <BarCodeScanner
          onBarCodeScanned = { isScanned ? undefined : this.handleBarCodeScanned }
          style = {{
            height:  window.height / 2,
            width: window.height,
          }}
        >
        </BarCodeScanner>
      </Container>
    }
    else{
      return <Spinner />;
    }
  }
}
export default ScannerScreen;

Github Repo: vtechguys/medium