DEV Community: Blank

JavaScript magic with Symbols

Marko Marinovic — Tue, 05 May 2020 10:02:10 +0000

Q: How to implement object magic which has the following behavior?

const magic = {};

console.log(2 + +magic); // 42
console.log(5 + magic); // 1337
console.log(`JavaScript is ${magic}`) // "JavaScript is awesome"
console.log(magic.toString()); // "[object magic]"

The question is very interesting and you are probably thinking "what kind of sorcery is this 😱?". To solve this mystery we need to learn about Symbols in JavaScript and see how they can help us in this case.

Symbols in JavaScript

A symbol is a primitive data type introduced in ES6. It's created with Symbol function and globally unique. Symbols can be used as object properties to provide uniqueness level access to objects and as hooks into built-in operators and methods, enabling us to alter the default behavior of JavaScript.

const mySymbol = Symbol('mySymbol');
typeof mySymbol // "symbol"

Symbol('mySymbol') === Symbol('mySymbol') // false

Symbols as object properties

Since symbols are globally unique, they can be used in a situation where there is a risk of property name collision. Imagine you are working on a library and need to attach your lib metadata to the supplied object.

const magic = {};

function someLibFunction(obj){
   obj.meta = 'MyLibMeta';
}

someLibFunction(magic);

console.log(magic); // { meta: 'MyLibMeta' }

There is a problem with this code because the meta property could be overwritten by the user code or other library.

const magic = {};

function someLibFunction(obj){
   obj.meta = 'MyLibMeta';
}

function userFunction(obj){
   obj.meta = 'I use this for my code';
}

someLibFunction(magic);
userFunction(magic);

console.log(magic); // { meta: 'I use this for my code' }

Now, userFunction has overwritten the meta property and lib is not working properly. Lib writers can use symbols for property names to avoid name collisions with other code.

const magic = {};

const libMetaSymbol = Symbol('meta');

function someLibFunction(obj){
   obj[libMetaSymbol] = 'MyLibMeta';
}

function userFunction(obj){
   obj.meta = 'I use this for my code';
}

someLibFunction(magic);
userFunction(magic);

console.log(magic[libMetaSymbol]); // 'MyLibMeta'
console.log(magic.meta); // 'I use this for my code'

Symbols as properties are not available through Object.keys, but rather through Reflect.ownKeys. This is for the purpose of backward compatibility because the old code doesn't know about symbols.
Keep in mind that Reflect.ownKeys returns all property names and symbols. If you need to read only symbols, use Object.getOwnPropertySymbols().

const magic = { id: 1 };
const metaSymbol = Symbol('meta');

magic[metaSymbol] = 'MyMeta';

console.log(Object.keys(magic)); // ["id"]
console.log(Reflect.ownKeys(magic)); // ["id", [object Symbol] { ... }]
console.log(Object.getOwnPropertySymbols(magic)); // [[object Symbol] { ... }]

Well-known symbols

Well-known symbols are defined as static properties on Symbol object.
They are used by built-in JavaScript functions and statements such as toString() and for...of. toString() method uses Symbol.toStringTag and for...if uses Symbol.iterator. There are many more built-in symbols and you can read about them here.

To solve the magic object question, we need to look closer at Symbol.toPrimitive and Symbol.toStringTag symbols.

Symbol.toPrimitive

JavaScript calls the Symbol.toPrimitive method to convert an object to a primitive value. The method accepts hint as an argument, hinting at what kind of conversion should occur. hint can have a value of string, number, or default. There is no boolean hint since all objects are true in boolean context.

Symbol.toStringTag

Property used internally by Object.prototype.toString() method. You would assume that string template literals also call Symbol.toStringTag under the hood, but that's not the case. Template literals call Symbol.toPrimitive method with a string hint.

Answering the question

Now when we know a lot about symbols, let's see the answer to the magic object question.

const magic = {
  [Symbol.toPrimitive](hint) {
    if (hint == 'number') {
      return 40;
    }
    if (hint == 'string') {
      return 'awesome';
    }
    return 1332;
  },

  get [Symbol.toStringTag]() {
    return 'sorcery';
  }
}

console.log(2 + +magic); // 42
console.log(5 + magic); // 1337
console.log(`JavaScript is ${magic}`) // "JavaScript is awesome"
console.log(magic.toString()); // "[object sorcery]"

First console.log converts magic to a number and adds 2. Conversion to number internally calls Symbol.toPrimitive function with hint number.

Second console.log adds magic to 5. Addition internally calls Symbol.toPrimitive function with hint default.

Third console.log uses magic with string template literals. Conversion to string, in this case, calls Symbol.toPrimitive function with hint string.

Final console.log calls toString() method on magic object. toString() internaly calls Symbol.toStringTag property.

Conclusion

Symbols are globally unique primitive types which allow us to avoid property name collision and hook into JavaScript internals. If you want to read more about symbols, visit EcmaScript specs and Mozzila docs.

Do you find symbols to be useful in your everyday programming?

Preloading React components

Marko Marinovic — Sun, 19 Apr 2020 11:33:11 +0000

In previous post I wrote about code-splitting and how it improves application performance.
This works great, but what about user experience? A loader is displayed each time the app needs to load additional code to run. This can get annoying, especially on slower connections. What we can do to improve this is to assume the user's next action. Is user scrolling thought the blog list and hovering over a specific post? If yes, then a user is likely to click on that post to get more info.
Making this assumption allows us to preload content for the post, rendering preloaded content on the actual click.

Preloading implementation

I created a simple function lazyWithPreload to help in this case. It's a wrapper around React.lazy with additional preloading logic that returns special PreloadableComponent.

Code for lazyWithPreload and PreloadableComponent is available down here:

import { ComponentType } from 'react';

export type PreloadableComponent<T extends ComponentType<any>> = T & {
  preload: () => Promise<void>;
};

import { lazy, ComponentType, createElement } from 'react';
import { PreloadableComponent } from 'shared/types/component';

const lazyWithPreload = <T extends ComponentType<any>>(
  factory: () => Promise<{ default: T }>
) => {
  let LoadedComponent: T | undefined;
  let factoryPromise: Promise<void> | undefined;

  const LazyComponent = lazy(factory);

  const loadComponent = () =>
    factory().then(module => {
      LoadedComponent = module.default;
    });

  const Component = (props =>
    createElement(
      LoadedComponent || LazyComponent,
      props
    )) as PreloadableComponent<T>;

  Component.preload = () => factoryPromise || loadComponent();

  return Component;
};

export default lazyWithPreload;

lazyWithPreload take a single argument, factory and returns a special component that acts in two different ways. When preload is initiated, factory gets called, loading the component.
Loaded component is stored and rendered when the app renders PreloadableComponent. Another case is when component is not preloaded via preload, then PreloadableComponent acts like a regular React.lazy component.

Using it with blog list

The idea is to preload content for a post on post title hover. IBlogPost has a property PreloadableContent which utilizes lazyWithPreload.

import { IBlogPost } from 'shared/types/models/blog';
import lazyWithPreload from 'shared/components/lazy-with-preload';

const post: IBlogPost = {
  id: 2,
  title: 'Whole year of reading (2019)',
  description: 'Complete list of my 2019 reads.',
  date: '2020-01-10',
  slug: 'whole-year-of-reading-2019',
  PreloadableContent: lazyWithPreload(() => import('./content.mdx')),
};

export default post;

BlogListItem displays preview for single post in the list. Hovering on post title link initializes the content preload. Now the content is loaded and loader will not appear
when navigating to the post details.

import React from 'react';
import { Link } from '@reach/router';
import { IBlogPost } from 'shared/types/models/blog';
import { StyledContent } from './BlogListItemStyles';

interface IProps {
  post: IBlogPost;
}

const BlogListItem = ({ post }: IProps) => {
  const { title, description, date, slug, PreloadableContent } = post;
  const preloadPost = () => PreloadableContent.preload();

  return (
    <StyledContent>
      <Link to={`/${slug}`} onMouseEnter={preloadPost}>
        {title}
      </Link>
      <span>{date}</span>
      <p>{description}</p>
    </StyledContent>
  );
};

export default BlogListItem;

Happy coding 🙌

How to use React Suspense for Code-Splitting?

Marko Marinovic — Sat, 18 Apr 2020 08:45:49 +0000

React 16.6 shipped an interesting feature called Suspense. Suspense allows React to suspend rendering while waiting for something. Loading indicator is displayed during wait time.

This post shows an example of how I used suspense on my simple blog site markomarinovic.com .

Why is this important to us?

We bundle our React apps using tools like webpack and rollup.
Our bundle grows as our application grows, especially when we include different third party libraries. Over time, our bundle will be huge and impact loading time of our application.
To prevent this from happening, we can start splitting our big bundle into multiple smaller bundles with a process called code-splitting. Code-Splitting is supported by tools such as webpack and rollup. These tools can generate multiple bundles that we can load on demand in runtime. I'll focus on webpack since it's used in this project.

With code-splitting we can give to the user only the code he currently needs, loading additional code as user navigates though the app.

How can Suspense and lazy help us?

Suspense will display the fallback component while bundle is dynamically loaded. It works together with lazy function.

lazy takes a single argument called factory (function returning a promise) and creates a new component of type LazyComponent. LazyComponent will call a factory function on the first render and resulting promise will be used by Suspense to show/hide the fallback component. In the case of code-splitting, we will pass a dynamic import of our component module.

import { lazy } from 'React';

const Home = lazy(() => import('./pages/Home'));
const BlogDetails = lazy(() => import('./pages/BlogDetails'));

webpack will see a dynamic import and create a promise that will resolve once the bundle is loaded. You can read more about webpack dynamic imports here.

Keep in mind that lazy only supports default exports, so make sure your component module has a default export. If you have a named export, you can re-export it as default to work around this.

Lazy loading pages and blog content

This is the App.ts for this blog project. Each page is dynamically loaded the first time we navigate to it.

import React, { Suspense, lazy } from 'react';
import { Router } from '@reach/router';
import { ErrorBoundary } from 'shared/components/ErrorBoundary';
import SuspenseFallback from 'shared/components/SuspenseFallback';
import { posts } from 'data/blog';

const Home = lazy(() => import('./pages/Home'));
const BlogDetails = lazy(() => import('./pages/BlogDetails'));

const App = () => (
  <React.StrictMode>
    <ErrorBoundary>
      <Suspense fallback={<SuspenseFallback />}>
        <Router>
          <Home path="/" />
          {posts.map(post => {
            const { id, slug } = post;
            return <BlogDetails post={post} key={id} path={`/${slug}`} />;
          })}
        </Router>
      </Suspense>
    </ErrorBoundary>
  </React.StrictMode>
);

export default App;

<SuspenseFallback /> will be displayed while we wait for the bundle to load. You can test this by throttling your internet connection and refreshing the page.

import React from 'react';

const SuspenseFallback = () => (
  <span>Suspended. Loading data...</span>
);

export default SuspenseFallback;

Lazy loading blog post content

The interesting thing is that we don't have to use this concept just for routing. Lazy loading is used in this blog project for content fetching as well.
Content for each blog post is in the form of .mdx file.

BlogDetails component will be loaded the first time we click on the blog post. Each blog post has a separate content which will be loaded separately.
This allows us to load BlogDetails component once and separately load content depending on the post.
Without lazy loading the content, we would have to bundle all .mdx files in the main bundle, drastically increasing our bundle size. mdx files replace database calls in this case.

Blog post data looks like this:

import { lazy } from 'react';

interface IBlogPost {
  id: number;
  title: string;
  description: string;
  date: string;
  slug: string;
  Content: React.LazyExoticComponent<any>;
}

const post: IBlogPost = {
  id: 4,
  title: 'How to use React Suspense for Code-Splitting?',
  description: 'Suspense allows React to suspend rendering while waiting for something.',
  date: '10.02.2020 @ 21:30',
  slug: 'how-to-use-react-suspense-for-code-splitting',
  Content: lazy(() => import('./content.mdx')),
};

export default post;

Content is our lazy component which dynamically imports content.mdx file.

BlogDetails component renders lazy Content component, initiating .mdx file load.

import React from 'react';
import { RouteComponentProps } from '@reach/router';
import Layout from 'shared/components/Layout';
import { StyledHeader } from 'shared/styles/components';
import { IBlogPost } from 'shared/types/models/blog';
import MDXWrapper from 'shared/wrappers/MDXProvider';
import { StyledContent, StyledPublishedOn } from './BlogDetailsStyles';

interface IOwnProps {
  post: IBlogPost;
}

type IProps = IOwnProps & RouteComponentProps;

const BlogDetails = (props: IProps) => {
  const { post } = props;
  const { title, date, description, slug, Content } = post;
  const pageMeta = {
    title,
    description,
    slug,
    date,
  };

  return (
    <Layout meta={pageMeta}>
      <StyledHeader>
        <h1>{title}</h1>
        <StyledPublishedOn>Published on {date}</StyledPublishedOn>
      </StyledHeader>
      <StyledContent>
        <MDXWrapper>
          <Content />
        </MDXWrapper>
      </StyledContent>
    </Layout>
  );
};

export default BlogDetails;

If you open the network tab in dev tools you will see that the first time you visit a blog post it loads multiple bundles.
Visiting other blog posts will initiate a load of additional content.mdx bundles.

Conclusion

Suspense for code-splitting is a very powerful tool for improving application performance. This is something you can start implementing right now to greately improve performance of your web app. There are more Suspense related things comming in the new concurrent mode for React which is currently in experimental phase.