Forem: Nishan Bajracharya

Implementing the Observer pattern in JavaScript

Nishan Bajracharya — Tue, 27 Nov 2018 17:23:14 +0000

Shamelessly borrowed from Wikipedia

The observer pattern is a design pattern that observes an entity and on change, notifies all subscribers of the change. It is very simple to understand and is very effective for when a change in an entity needs to trigger many events.

How does the observer pattern work?

The observer pattern is a combination of two elements, a Subject, and an Observer. The Subject tracks the value of an entity and the Observer listens for changes tracked by the Subject.

When an entity tracked by the Subject changes, the Subject notifies the Observer of the change. One Subject can have many Observers, in which case it notifies all the Observers of the change in the entity. The observers can be subscribed to trigger events when the Subject notifies them.

So how do you implement the observer pattern in JavaScript?

Let’s start with the Subject, which is alternatively called an Observable. The subject contains a state and a collection of observers that it notifies to when the state changes.

The subject provides methods to register and unregister observers and a method to notify all the observers.

Each observer has a notify method which the subject calls when it needs to notify observers for change in state.

Next, let’s look at the Observer. It simply only contains a notify method but we add a subscribe method that is used to subscribe an event to the Observer. When the Subject notifies the Observer of change in state, the Observer triggers the subscribers.

The subscriber is a function that gets called when the Observer’s notify function is called.

How do you use it?

We create a new subject that tracks the value of an entity and an observer for the subject an subscribe to the observer. Then when there is a change in the subject’s state, all the observers are notified and their subscribers are triggered.

The subject has two observers and each observer is subscribed by two functions. When the observable changes the state by calling the setState method, both the observers are notified and each of their subscribers are triggered.

And that is how the observer pattern works and how it is implemented in JavaScript.

An alternate and simpler approach

While the above approach to implementing the observer pattern is more than enough, it requires creating at least one instance of the subject and one instance of the observer to work. So we can simplify the pattern using a single Observer class that maintains the state and also triggers the subscribers of the observer.

What are some practical use cases of the Observer Pattern?

When done correctly, the observer pattern can be very powerful and extremely helpful for broadcasting information across an application. Some use cases of the observer pattern can be like so:

Group Messaging: When a message is sent to a group chat, all the participants of the chat receive the notification of the new message.
Website Newsletters: All subscribers of a website newsletter receive email notifications when the website publishes a new newsletter.
Redux: When a redux action is dispatched, all the subscribers of the store are notified.

References and Further Learning

What I learned from building my own virtualized list library for React

Nishan Bajracharya — Wed, 08 Aug 2018 08:20:26 +0000

Virtualized vs non-virtualized lists

A project I’m working on has a contact list that needs to show 5000 contacts on average. That means 5000 complex DOM elements with lots of nested components need to be rendered on the screen. We knew when we started building this that rendering so many of these elements would be a very taxing operation on the DOM. And React, ever so dilligent, will absolutely render all the DOM elements if we were to map them into our view even if it kills our rendering performance.

{
  LIST_WITH_5000_ITEMS.map(item => <ComplexListItem {...item} />)
}

So we opted for a better approach than this. Our first approach was to use an infinite scroll component that would load 250 contacts at a time and after reaching to the end of the list would load another 250 contacts. This made the initial render performance better but would start to get considerably slower as you scroll to the end. This did not fix the original issue at hand.

Our second approach was to use something called a virtualized list. This fixed the majority of our underlying rendering and performance issues related to the list DOM and scrolling and we could finally focus on optimizing the non-DOM related issues with the contact list logic, like a heavy fetch API request.

What is a virtualized list?

A virtualized list is a technique where a large list of items in a scrollable view is virtually rendered to only show items that are visible within the the scrollable view window. That may sound like a handful but it basically means a virtualized list only renders items that are visible on the screen.

Why the need for this?

Consider an application that deals with a large list of items, say 10000 rows in a list. What is the best and most performant way to render this list? Some would say a paginated list where rows are unmounted when the page is changed. But what about infinite scroll views, ones that add rows to the bottom of the current view once we scroll towards the bottom. Each of the rows are rendered and more rows get rendered as we scroll below.

We could have a view window that can only show 20 items at a time but we are rendering tens of thousands of DOM elements. This is very ineffective and causes a lot of sluggish scrolling and unresponsive lists. This is no good.

Ideally we would only render the items that are visible. The items outside of the view window don’t need the rendering power. Only when they come into the visible window do they need to be rendered. This is where virtualized list comes into view.

Is this a new idea?

react-virtualized by Brian Vaughn

No. In fact, the idea of virtualized lists has been available for quite a while now. Android development has had the Recycler View since 2014, React Native provides VirtualizedList component out of the box and for React developers, we have a highly extensible library called react-virtualized. Each of these libraries and features may have different implementations, but they all try to fix the same issue.

What came next?

I became interested in how a virtualized list works behind the scenes. A virtualized list doesn’t have any scrolling artifacts that you might expect considering it is rendering new items that come into view and un-rendering items that get out of the view on the fly. It works basically the same as a non virtualized list, showing the scrollbar on the side with the same functionality when dragging the scroll bar.

So how does it imitate these behaviors and how is it keeping track of what elements are on the view? These were the burning questions running through my head when I started looking into the inner workings of a virtualized list. I had read a blog about virtualized list I had received from a friend a while back and all I remember from that is that instead of rendering a list as you would normally do, you use position: absolute on the elements and keep track of the scroll position of the list.

So I started to work on my own implementation of a virtualized list in the form of a React library that I brilliantly called react-virtualized-listview . Since I had already worked with react-virtualized , I was heavily inspired by that library’s API. And I also wanted something that a lot more simpler than all the various features that react-virtualized provided. Don’t get me wrong, react-virtualized is definitely among the best libraries of available for React, but it was a little daunting to start with because of all the various features it provides. I wanted something that was much easier to use and in the process of building the library, I would understand how virtualized list worked.

An example of how this would work in code:

const data = [1, 2, 3, 4, 5];

<List
  source={data}
  rowHeight={40}
  renderItem={({ index, style }) => (
    <div key={index} style={style}>
      Hello {index}
    </div>
  )}
/>

So how does it work?

Props of a rendered list item

Let’s take a list with a 1000rows. Say each row is 20pxin height. So we would have a list with a height of 20000px. This is where the virtualized list starts. It creates a DOM element that matches the width dimension of its parent visible window and a height that equals the total item count multiplied by the height of the item (20000px here). This is so that the position of the scrollbar perfectly imitates the behavior of a non-virtualized list. So scrolling the mouse wheel on the list and dragging the scrollbar both work as intended. The DOM element is empty at this point.

Next we keep track of the scroll position within the list. This is the critical part of the virtualization. The scroll position determines which index we’re at in the list. This index coupled with the height of the visible window determines the indices that are visible and need to be rendered. The list item to be rendered is given a position: absolute style and a top value calculated using the index of the item and the row height of the item. So we only render the items that match the calculated indices.

One additional trick we use to imitate a non-virtualized list is the overscan. We render a small number of non-visible items above and below the visible window so that it appears like other items exist when scrolling, as opposed to just popping into view when it enters the visible window.

A codesandbox example of the virtualized list in action

React virtualized listview on Codesandbox

Using SVG Icons Components in React

Nishan Bajracharya — Tue, 13 Mar 2018 14:39:15 +0000

SVGs are cool. They scale up. They scale down. Sometimes they try to kill you in your sleep but you know, necessary evil and stuff.

Photo by NordWood Themes on Unsplash

So what’s good about SVG?

SVG or Scalable Vector Graphics are XML-based image formats that can be scaled to any size while maintaining the quality of the image. So when you need an image that needs to be scaled as big or as small as you want, SVGs are the way to go. They’re basically XML documents so their file sizes also tend to be tiny compared to other image formats.

Also they are effectively XML elements and can be manipulated using CSS. So changing colors and strokes on SVG can be done all via CSS.

Sounds good. What about the bad stuff?

When it comes to images, SVGs are great for simple shapes, full of basic strokes and color. Anything more complex than icons though and they are not worth the hassle. (Unless you’re doing data visualizations, in which case, let me point you towards D3.js.)

It is also more complicated to build SVGs on your own. Since they are structured in XML, building one can be harder than an equivalent raster image, which stores pixels data.

Scaling — Raster vs Vector

Where does React come into all this?

When using SVG in a web document, you have two options. Either render the SVG document as is, or use it as source in the img tag. The preferable option is to use it as is, since SVG in the image tag is rendered as an image and cannot be manipulated beyond the css styles for the image tag.

So when deciding on using SVG in a React project, it is preferable to build a component than render the SVG into the document.

const Svg = () => 
 <svg
 width="100%"
 height="100%"
 viewBox="0 0 32 32"
 xmlns="http://www.w3.org/2000/svg"
 xmlnsXlink="http://www.w3.org/1999/xlink"
 >
   <path d="some path here" fill="#000" />
 </svg>;

This would render a static SVG into the html document. Let’s add some props.

const Svg = ({
 style = {},
 fill = '#fff',
 width = '100%',
 className = '',
 height = '100%',
 viewBox = '0 0 32 32',
}) => 
 <svg
 width={width}
 style={style}
 height={height}
 viewBox={viewBox}
 className={className}
 xmlns="http://www.w3.org/2000/svg"
 xmlnsXlink="http://www.w3.org/1999/xlink"
 >
   <path d="some path here" fill={fill} />
 </svg>;

We can now use this component to render SVG of different colors, classnames and styles. Check out a CodeSandbox demonstration below.

Link to CodeSandbox

OK, so we now have a general idea of how we can create React components for SVG icons. How do we deal with a large plethora of icons then, which is quite common in large projects? Here we have multiple options to go for. We could have a giant component which returns the required SVG icon or create a mapper component that takes in a prop and maps it to the equivalent SVG component.

Let’s take a look at how they can be achieved.

Approach #1

Link to CodeSandbox

TL;DR: We create a single SVG component and pass a name prop to it. The component resolves the viewBox and path values associated with the icon and returns the SVG element.

Lets start with adding the name prop to our SVG component and resolve the path for that name prop.

const getPath = (name, props) => {
 switch(name) {
 case 'icon-1':
 return <path {...props} d="icon-1-path" />;
 case 'icon-2':
 return <path {...props} d="icon-2-path" />;
 default:
 return <path />;
 }
}

const Svg = ({
 name = '',
 style = {},
 fill = '#000',
 width = '100%',
 className = '',
 height = '100%',
 viewBox = '0 0 32 32',
}) => 
 <svg
 width={width}
 style={style}
 height={height}
 viewBox={viewBox}
 className={className}
 xmlns="http://www.w3.org/2000/svg"
 xmlnsXlink="http://www.w3.org/1999/xlink"
 >
   {getPath(name, { fill })}
 </svg>;

Works great. But we haven’t considered that each SVG icons can have their own viewBox values. So we also need to resolve the viewBox based on the name prop.

const getViewBox = name => {
 switch(name) {
 case 'icon-1':
 return 'icon-1-view-box'; // Eg. 0 0 32 32
 default:
 return '';
 }
}

<Svg
 width={width}
 style={style}
 height={height}
 className={className}
 viewBox={getViewBox(name)}
 xmlns="http://www.w3.org/2000/svg"
 xmlnsXlink="http://www.w3.org/1999/xlink"
>
 {getPath(name, { fill })}
</Svg>;

And that’s it. We can add more paths and viewBoxes to this component and use it by adding the name prop for the icon we need.

<Svg fill="#49c" width={100} name="icon-1" />

Approach #2

Link to CodeSandbox

TL;DR: We create separate files for each SVG icon and create an index file that returns the SVG component based on the name prop.

We create separate components for each SVG icon we want.

./icons
--/Phone.js
--/Trash.js
--/Messages.js
--/Envelope.js
--/Wifi.js

Each component is independent of one another and can be used on their own.

import Phone from './icons/Phone';

<Phone width={100} />

We then create an index file that returns the component itself based on the name prop.

./icons
--/Phone.js
--/Trash.js
--/Messages.js
--/Envelope.js
--/Wifi.js
--/...
--/index.js

The index file would look something like this.

import React from 'react';

import Phone from './Phone';
import Messages from './Messages';

const Icon = props => {
 switch(props.name) {
 case "phone":
 return <Phone {...props} />;
 case "messages":
 return <Messages {...props} />;
 default:
 return <div />;
 }
}

export default Icon;

So anytime we need to add new icons into the mix, we create new components and include them in the index file. We use this component by importing a single Icon component and sending the name prop into it.

import Icon from './icons';

<Icon fill="#49c" width={100} name="phone" />

And that’s it. I’ve detailed a few ways to create React components to manipulate SVG images. Of course these aren’t the only ways, or the even best ways to deal with SVGs in React applications. Just like anything in the world of Javascript, there are always other options at our disposal.

Alternate options

Webpack SVG Loader — A webpack loader to import SVG files as components.

React Inline SVG — A react component that takes SVG file paths as prop to render them on the document.

This article was last published in Medium. Using SVG Icons Components in React