Let's see how we evaluate JavaScript code and check if the output matches the corresponding solution.

Synchronous code

For a simple synchronous code, the first thing we need to check is if everything logged by the user is the same as that of the solution code. What we do here is aggregate all the logs to an array and then compare that array with the array generated by the solution code. This is done by transforming the code using an AST library

Take this exercise as an example.

Now let's see the transformed code.

Here pushTologs replaces the console.log function and logsAggregator is an array that stores all the logs. We also replace throw statements with pushToLogs to evaluate exceptions.

We also perform serialization to make comparison easier. The transformed code is then ran as an IIFE and the result is used for comparison.

We run the user submitted code in an iframe so that any bug in the submitted code doesn't mess up the page.

How code is transformed

Let's see how this "code transformation" works. We mentioned the use of an AST library. AST(abstract syntax tree) is a tree representation of the code which helps the compiler to understand the structure of the code. Let's use a tool called AST Explorer to see how the AST looks like for the below code.

const priceOfPencil = 5;

console.log("Price of 1 pencil:");
console.log(priceOfPencil);

Here, MemberExpression is a node and in that node we can use object.name. See the underline highlights using pink color.

Using object.name we can get to value console. See the green arrow.

Similarly using property.name we can get to log.

Now our goal is to walk the tree and replace all console.log statements with pushToLogs statement. For walking and replacing the value we will use the replace function provided by the library.

replace(tree, node => {
  const { callee } = node;

  // create the node that needs to be put instead of console.log
  const pushToLogsExpression = parse("pushToLogs()").body[0].expression;

  // check for the console.log node
  if (
    callee?.type === "MemberExpression" &&
    callee?.object?.name === "console" &&
    callee?.property?.name === "log"
  ) {
    pushToLogsExpression.arguments = node.arguments;
    node = pushToLogsExpression;
  }

  return node;
});

Here we are creating a new node by parsing the string "pushToLogs()". We are then adding the arguments of the console.log to the pushToLogs node. When we return this new node, the code transformation is complete.

Asynchronous code

Evaluating async code is a bit tricky since we won't get the output of the code right away. What we do in this case is transform the code to make it synchronous. For evaluating the output, these are the information we need:

1. Console logs
2. Exceptions
3. The order in which the code needs to be executed

We will transform the code in such a way that this information are available to us. Let's see how the code is transformed in the following cases:

SetTimeout / SetInterval

In this case the function that needs to be executed after the specified timeout is executed inline. And the delay value is just added to the logsAggregator for record keeping. There will be no delay in the evaluation.

We do the same for setInterval.

In both the cases we evaluate the function "inline" and then compare the console.log outputs.

What if we want an exercise involving clearTimeout ? We simply add Timeout cleared to the logsAggregator.

Promises

Without going too much in details, to evaluate Promises all we did was move the callbacks from the then method of the promise to the arguments of a function.

We handle async/await code in a similar style.

What happens in the case of promise chaining?

Here, if we detect that there are more than one then calls, then the second body of then is passed as resolveFn to the function that the first then returns. This can go multiple levels based on the chaining.

In other words, we go back to adding "callbacks".

This is how we evaluate JavaScript in NeetoCourse. We evaluate HTML, CSS and SQL similarly on the browser. We have also recently added the evaluation of HTML Canvas. Evaluation of HTML Canvas animations is on the roadmap. But these can be a story for another day.

Want to see code evaluation in action. Checkout this question from our JavaScript course.

Interested to know more about NeetoCourse? Follow @NeetoCourse to see what we're up to.

For example, with modern JavaScript, we might use arrow functions like this:

const add = (a, b) => a + b;

This code works in modern browsers but not in older ones, like Internet Explorer, which does not support arrow functions. Without Babel, we would need to use older syntax to ensure compatibility, which limits our use of modern features. Babel solves this problem by transforming the modern code into an older syntax that more browsers can handle. For example, Babel converts the arrow function code above into the standard function syntax shown below, which is compatible with all browsers.

var add = function add(a, b) {
  return a + b;
};

With Babel, we can write modern JavaScript code without worrying about browser compatibility. Babel uses several presets and plugins to achieve this.

Plugins and Presets

Plugins are individual components that handle specific tasks in JavaScript code. For example, there are plugins for converting Arrow Functions to ES5 Functions, JSX to React functional calls and so on.

There are two main types of plugins:

• Syntax Plugins: These plugins help Babel understand new syntax that it doesn’t recognize otherwise. For example, Babel doesn’t understand JSX syntax by default, so we need a plugin to enable this. @babel/plugin-syntax-jsx is a syntax plugin that allows Babel to recognize and parse JSX syntax.

• Transformation Plugins: This type of plugins help Babel convert code written in modern syntax into format more widely supported by different browsers. For instance, @babel/plugin-transform-react-jsx is a transformation plugin that converts JSX into React functional calls.

Presets make things easier by bundling related plugins together. Instead of setting up each plugin separately, we can use a preset that includes all the necessary plugins. For instance, @babel/preset-react includes both @babel/plugin-syntax-jsx and @babel/plugin-transform-react-jsx, handling both JSX recognition and transformation in one go.

Plugin and Preset Order in Babel Configuration

Babel processes plugins in the order they are listed in the Babel configuration file. This is important because the output of one plugin can affect the input of another. For example, if we want to convert JSX to React functional calls, we need to ensure that the JSX syntax is recognized first. So, we should list the syntax plugin before the transformation plugin in the configuration file.

{
  "plugins": ["@babel/plugin-syntax-jsx", "@babel/plugin-transform-react-jsx"]
}

Babel process presets in reverse order. This means that the last preset listed will be the first to be processed.

{
  "presets": ["@babel/preset-env", "@babel/preset-react"]
}

For example, let's look at the configuration mentioned above. In this case @babel/preset-react preset will be applied first, followed by @babel/preset-env, ensuring that React-specific transformations are handled before general environment compatibility transformations.

Custom Babel Plugin

While Babel offers a wide range of plugins and presets, it's true potential lies in the ability to create custom plugins tailored to our project's specific needs. In the final section of this blog, we will explore a use case we encountered at Neeto and how we solved it with a custom Babel plugin. For now, let's focus on creating a simple plugin. Before we begin, it's important to understand a key concept called an AST (Abstract Syntax Tree).

Abstract Syntax Tree (AST)

An AST is a tree representation of the structure of a program. It breaks down the code into its constituent parts and represents them as nodes in a tree. Each node in the tree represents a different part of the code, such as a variable declaration, a function call, or a loop. Babel uses ASTs to analyze and transform JavaScript code. For example, consider the following code:

const sum = (x, y) => x + y;

This is how its AST looks:

In this example, the root node is the File node, which represents the entire code file. Within it, there are several nested nodes like, VariableDeclarator, ArrowFunctionExpression and so on, each dedicated to different parts of the code. As shown in the animation, hovering over each node highlights the corresponding code segment on the left-hand side. To explore and interact with both the code and its AST, the AST Explorer tool can be used.

Babel transpile stages

Now that we have a basic understanding of ASTs, let's see at how Babel works. It has three main stages:

• Parse Stage: In this stage, the code that is passed to Babel as input is converted into an AST. This is done using the @babel/parser package.
• Transform Stage: This is the stage where Babel traverses and modifies the AST using @babel/traverse package. This is where plugins come into play to apply specific transformations. It’s important to note that this is the only step we can influence. In the next section, we'll see how to create a custom Babel plugin.
• Generate Stage: Once the AST has been modified, it needs to be converted back into code. This is done using @babel/generator package.

Creating a Babel Plugin

As mentioned in the previous section, Babel plugins are used to apply transformations to the AST, and this is the only step we can influence. So, let’s see how to create a simple Babel plugin. We will create a plugin that converts all == operators in the code to ===. This is a common transformation that developers often use to ensure strict equality checks in their code.

First, let's set up the project structure for our plugin.

• Step 1: Create a new directory and initialize a new npm package for the plugin. Let's prefix the package name with babel-plugin-. This naming convention clearly indicates that the package is a Babel plugin, making it easier for others to identify its purpose.

  mkdir babel-plugin-strict-equality
  cd babel-plugin-strict-equality
  npm init -y
  

• Step 2: Create a file named index.js in the root of the plugin directory. This file will contain the logic for the plugin.

  touch index.js
  

Now that we have set up the project structure, let's start writing the plugin code.

To transform the code, we need to traverse the AST generated from the parse stage. We can do this by creating a visitor object that defines the transformations to be applied to the AST. The visitor object contains methods that correspond to different types of nodes in the AST. When Babel encounters a node of a particular type, it calls the corresponding method in the visitor object to apply the transformation.

To understand this better, let's look at a code example that we want to transform:

a == b;

We want to transform this code into:

a === b;

First, let's examine the AST representation of the original code:

{
  "type": "File",
  "program": {
    "type": "Program",
    "body": [
      {
        "type": "ExpressionStatement",
        "expression": {
          "type": "BinaryExpression",
          "left": {
            "type": "Identifier",
            "name": "a"
          },
          "operator": "==",
          "right": {
            "type": "Identifier",
            "name": "b"
          }
        }
      }
    ]
  }
}

Here, our goal is to modify the BinaryExpression node with the operator == to ===. To achieve this, we need to create a visitor method for the BinaryExpression. When Babel encounters a BinaryExpression node with the operator == in the AST, it will call our visitor method to apply the transformation.

So, let's write the code for our plugin. Open the index.js file we created earlier and add the following code:

module.exports = function () {
  return {
    visitor: {
      BinaryExpression(path) {
        if (path.node.operator === "==") {
          path.node.operator = "===";
        }
      },
    },
  };
};

This plugin will traverse the AST, identify BinaryExpression nodes with the == operator, and replace them with ===, ensuring strict equality checks are used throughout the code.

Now that we have written the plugin code, let's see how to test it.

Adding tests for the plugin

To ensure that our plugin works as expected, we need to write tests. For this, we can use the babel-plugin-tester and jest packages. babel-plugin-tester is a utility that makes it easy to test Babel plugins, while jest is a popular testing framework for JavaScript. Let's see how we can add tests for our plugin.

• Step 1: Install the required packages:

  yarn add --dev babel-plugin-tester jest
  

• Step 2: Create a folder named tests in the project directory. Inside this folder, create a test file named strict-equality.spec.js with the following content:

  const pluginTester = require("babel-plugin-tester");
  
  const plugin = require("../index");
  
  pluginTester({
    plugin,
    tests: {
      "should convert == to ===": {
        code: "a == b;",
        output: "a === b;",
      },
      "should not modify == inside a string or comment": {
        code: `
          const str = "a == b";
          // comparison: a == b
        `,
        output: `
          const str = "a == b";
          // comparison: a == b
        `,
      },
    },
  });
  

  In the code above, we are passing an object to the pluginTester function with two keys: plugin and tests. The plugin key specifies the Babel plugin we want to test, while the tests key contains an object defining our test cases. Each test case includes a code key with the input code and an output key with the expected result after the plugin is applied. The pluginTester function runs each test case, comparing the actual output with the expected output. If they match, the test passes; if they don’t, it fails.

• Step 3: Now to run the tests, use the following command:

  yarn jest
  

  This will run the tests and display the results in the terminal. If the test passes, it means our plugin is working as expected.

  

Testing the plugin in a real project using yalc

While pluginTester helps cover many edge cases, it’s challenging to anticipate all possible scenarios. For this, we need to run our rules in real projects and we will have to achieve this without publishing our package to the remote registry right away.

To achieve this, we can use the yalc package. yalc is a tool that allows us to work on the npm packages as if they were published, but without actually publishing them. It creates a symlink to our local package in the global npm registry, allowing us to install and use it in other projects. Let's see how we can use yalc to test our plugin.

• Step 1: Install yalc globally.

  yarn global add yalc
  

• Step 2: Publish the plugin using yalc by running the following command in the plugin directory.

  yalc publish
  

  This creates a symlink to the local package in the global npm registry.

• Step 3: Install the plugin in the project using yalc by running the following command in the project directory.

  yalc add babel-plugin-strict-equality
  

  This will add the plugin to the project as if it were installed from npm registry.

• Step 4: Include the plugin in the Babel configuration.

  {
    "plugins": ["babel-plugin-strict-equality"]
  }
  

After testing the plugin in a real project and being satisfied with the results, it can be published to the npm registry.

Creating a Babel preset

If we have multiple plugins that we want to bundle together, we can create a Babel preset. As mentioned earlier, presets make it easier to configure Babel by bundling related plugins together. Here is an example of how we can create a Babel preset that includes the babel-plugin-strict-equality plugin:

• Step 1: Create a new directory for the preset and initialize a new npm package for the preset. Let's prefix the package name with babel-preset- to indicate that it is a Babel preset.

  mkdir babel-preset-strict-equality
  cd babel-preset-strict-equality
  npm init -y
  

• Step 2: Create a folder named plugins in the root of the preset directory. This folder will contain the plugins that we want to include in the preset. In our case, we have only one plugin, so create a file named strict-equality.js inside the plugins folder and add our plugin code to it.

  module.exports = function () {
    return {
      visitor: {
        BinaryExpression(path) {
          if (path.node.operator === "==") {
            path.node.operator = "===";
          }
        },
      },
    };
  };
  

• Step 3: Create a file named index.js in the root of the preset directory. This file will contain the logic for bundling the plugins together.

  const strictEquality = require("./plugins/strict-equality.js");
  
  module.exports = function () {
    return {
      plugins: [strictEquality],
    };
  };
  

  Here we are returning an object with a plugins key that contains an array of plugins to be included in the preset. If there are multiple plugins, we can list them all in this array. We can now publish this preset to the npm registry and use it in our Babel configuration.

• Step 4: To use the preset in the Babel configuration, include it like this:

  {
    "presets": ["babel-preset-strict-equality"]
  }
  

Here we have created a simple Babel plugin and preset. This is just the tip of the iceberg when it comes to creating custom Babel plugins. We can create plugins to handle a wide range of tasks, from optimizing code to adding new features. To know more about the functions and methods available in Babel, you can refer to the Babel handbook. In the next section, we will see the use case we encountered at Neeto and how we solved it using a custom Babel plugin.

Motivation behind babel-preset-neeto

At Neeto, we build our own custom plugins and presets to streamline and simplify our development workflow. Let's look into one of the specific plugins we've designed and implemented and see how it enhances our development process.

We use Zustand for global state management. Zustand provides shallow function, which allows us to construct a single object with multiple state-picks inside. This helps prevent unnecessary re-renders by using shallow equality to check if the selected state values have changed. Let's consider the following example:

import { shallow } from "zustand/shallow";

const { id, name } = useSessionStore(
  store => ({
    id: store[sessionId]?.user.id,
    name: store[sessionId]?.user.name,
  }),
  shallow
);

In this example, the component only re-renders if id or name changes. If any other state in the store changes, the component will not re-render. This significantly improves performance. To know how this works, you can refer to this blog post. However, when dealing with many state selections, the code can become verbose and repetitive. For example, consider the following code:

import { shallow } from "zustand/shallow";

const {
  id,
  name,
  email,
  notifications,
  theme,
  language,
  isAuthenticated,
  apiToken,
  appVersion,
  darkModeEnabled,
} = useSessionStore(
  store => ({
    id: store[sessionId]?.user.id,
    name: store[sessionId]?.user.name,
    email: store[sessionId]?.user.email,
    notifications: store[sessionId]?.user.notifications,
    theme: store[sessionId]?.user.theme,
    language: store[sessionId]?.user.language,
    isAuthenticated: store[sessionId]?.user.isAuthenticated,
    apiToken: store[sessionId]?.user.apiToken,
    appVersion: store[sessionId]?.user.appVersion,
    darkModeEnabled: store[sessionId]?.user.darkModeEnabled,
  }),
  shallow
);

This is really repetitive, for each state, we need to add a line on left and right side of the code. Then we thought, what if we can infer the right side from the left side of the code. This will make the code more readable and less error-prone. But this is not possible with the custom functions or hooks because they operate at runtime and cannot modify the structure of the code during transpilation. This is where custom Babel plugins come into play. We have built a Zustand pick transformer capable of generating the boilerplate at the time of transpiling the code.

If this plugin is added to the babel configuration, we can rewrite the previous example as:

const {
  id,
  name,
  email,
  notifications,
  theme,
  language,
  isAuthenticated,
  apiToken,
  appVersion,
  darkModeEnabled,
} = useSessionStore.pick([sessionId, "user"]);

The array inside pick() is the path of the nested object to be accessed. You might also notice that we don't have the import { shallow } from "zustand/shallow" statement in this piece of code. We don't need that. The plugin will automatically add it for us at the time of transpiling.

The plugin detects that id, name, email, and other properties are to be accessed from the store[sessionId].user in useSessionStore, and it generates code for it. It will also add optional chaining for all the nested properties automatically to make the picks free from null-pointer errors.

For more information about the plugin, refer to the documentation. To see the implementation of the plugin, check the source code

We've open-sourced this preset package so that it's accessible for use in your projects as well. To include this preset, install it using the following command:

yarn add -D @bigbinary/babel-preset-neeto

And then include it in the Babel configuration:

{
  "presets": ["@bigbinary/neeto"]
}

Why Type Definitions

We considered using TypeScript. However, in the end, we opted against it since most of our clients use plain JavaScript. Still, we added type definitions for our JavaScript packages to:

• Reduce Ambiguity and Improved Clarity: Type definitions shed light on the expected input and output of functions and components, eliminating ambiguity and allowing developers to understand the code without needing to constantly refer to separate documentation.
• Enhance Productivity and Efficiency: By providing clear insights into the structure of our libraries, including information about arguments, props, and data types, type definitions significantly boost developer productivity and facilitate efficient coding practices.
• Seamless Code Editor Integration: Popular editors like VSCode leverage type definitions to offer powerful features like IntelliSense, further streamlining the development process and minimizing errors.

Unifying Documentation with JSDoc Comments

Although type definitions offered a valuable structural understanding, comprehensive documentation remained a challenge. Here is a typical example of our documentation of an exported function inside a Markdown file:

Navigating between code and Markdown files scattered across the package repository was cumbersome and time-consuming.

To address this pain point, we incorporated JSDoc comments alongside type definitions. This allowed us to:

• Consolidate Essential Documentation: Instead of relying on separate files, we embedded detailed usage instructions, examples, and additional information directly within the JSDoc comments, providing developers with readily available context within their IDE environment.
• Improve Accessibility and Transparency: By integrating documentation with the code itself, JSDoc comments eliminate the need for context switching and offer immediate access to critical information, enhancing the developer understanding and decision-making.

Optimizing Documentation Workflow

Maintaining two separate documentation sets – Markdown files and JSDoc comments – proved inefficient. To ensure consistency and to eliminate redundancy, we automated the generation of JSDoc comments from existing Markdown documentation.

This involved:

• Standardization for Efficiency: We implemented a standardized structure and format for the Markdown documentation, facilitating easier readability for a developer as well as parsing for an automated parser.
• Building a Custom Script: A dedicated script was developed to parse the Markdown files, extract relevant documentation for each function or component, and automatically prepend it to the corresponding type definitions.
• Integration with Build Process: To ensure automatic updates and maintain a single source of truth, we integrated the JSDoc generation script into the package build process, seamlessly generating up-to-date documentation alongside the code itself.

Below snippet shows a minimized version of the JSdoc generation script:

import fs from "fs";
import path from "path";

import _generate from "@babel/generator";
import _traverse from "@babel/traverse";
import * as babelTypes from "@babel/types";

const traverse = _traverse.default;
const generate = _generate.default;

const buildJsdoc = () => {
  const fileNamesInsideDocs = getFileNameList(path.resolve(DOCS_FOLDER_NAME));
  const typeFileNames = fs.readdirSync(path.resolve(TYPES_FOLDER_NAME));

  syncTypeFiles(EXPORTED_TYPES_FOLDER_NAME);

  const entityTitleToDescMapOfAllFiles = {};

  fileNamesInsideDocs.forEach(docFileName => {
    const fileContent = getFileContent(docFileName);
    const markdownAST = parseMarkdown(fileContent);

    buildEntityTitleToEntityDescMap(
      markdownAST.children,
      entityTitleToDescMapOfAllFiles
    );
  });

  typeFileNames.forEach(typeFileName => {
    const typeFileContent = getFileContent(
      path.join(EXPORTED_TYPES_FOLDER_NAME, typeFileName)
    );
    const typeFileAST = parseTypeFile(typeFileContent);

    typeFileTraverser({
      typeFileName: `${EXPORTED_TYPES_FOLDER_NAME}/${typeFileName}`,
      typeFileAST,
      entityTitleToDescMapOfAllFiles,
      babelTraverse: traverse,
      babelCodeGenerator: generate,
      babelTypes,
    });
  });

  console.log("Successfully added JSDoc comments to type files.");
};

Let's dive deep into the above snippet to understand how the JSDoc generation script works.

Initial Setup and Imports

The script starts with essential imports and variable initializations. This section sets up the necessary tools and libraries to work with file systems and Abstract Syntax Trees (AST).

import fs from "fs";
import path from "path";

import _generate from "@babel/generator";
import _traverse from "@babel/traverse";
import * as babelTypes from "@babel/types";

const traverse = _traverse.default;
const generate = _generate.default;

Gathering File Information

We created a buildJsdoc function to encapsulate the JSDoc generation process. The buildJsdoc function begins by collecting file names from the documentation (DOCS_FOLDER_NAME) and type definitions (TYPES_FOLDER_NAME) folders. It then copies the type definition files to the EXPORTED_TYPES_FOLDER_NAME.

const fileNamesInsideDocs = getFileNameList(path.resolve(DOCS_FOLDER_NAME));
const typeFileNames = fs.readdirSync(path.resolve(TYPES_FOLDER_NAME));
syncTypeFiles(EXPORTED_TYPES_FOLDER_NAME); // copying the files

Building Entity Descriptions Map

The script parses Markdown documentation files to construct a map linking entity titles to their descriptions. This map serves as a bridge between the documentation and the type definitions. We use unified package and remarkParse plugin for parsing Markdown.

const entityTitleToDescMapOfAllFiles = {};
fileNamesInsideDocs.forEach(docFileName => {
  const fileContent = getFileContent(docFileName);
  const markdownAST = parseMarkdown(fileContent);
  buildEntityTitleToEntityDescMap(
    markdownAST.children,
    entityTitleToDescMapOfAllFiles
  );
});

Updating Type Definitions

Next, the script traverses the AST of each type definition file. For each entity, it finds the corresponding description from the map and adds it to the type definition file. The typeFileTraverser function is responsible for traversing the AST of a type definition file and looks for ExportNamedDeclaration nodes. It then prepends the corresponding JSDoc comment to the node.

typeFileNames.forEach(typeFileName => {
  const typeFileContent = getFileContent(
    path.join(EXPORTED_TYPES_FOLDER_NAME, typeFileName)
  );
  const typeFileAST = parseTypeFile(typeFileContent);

  typeFileTraverser({
    typeFileName: `${EXPORTED_TYPES_FOLDER_NAME}/${typeFileName}`,
    typeFileAST,
    entityTitleToDescMapOfAllFiles,
    babelTraverse: traverse,
    babelCodeGenerator: generate,
    babelTypes,
  });
});

The script concludes by logging a success message, indicating the completion of the JSDoc generation process.

Once everything was set up and released, we were able to access both types and documentation from the code editor itself.

Conclusion

By leveraging the power of type definitions and JSDoc comments, we were able to provide easy access to documentation and significantly enhance the developer experience and streamline the development process. The automated generation of JSDoc comments from Markdown documentation further optimized our workflow, ensuring clarity, consistency and eliminating redundancy.

When we write code, we split parts of code into different files to manage complexity. However, the web application requires all of its JavaScript files in order for the application to function properly. On the surface, it might seem like loading all the separate JavaScript files is easy, but it gets very complicated very fast.

Let's assume that we have three different JavaScript files in our codebase that we are referencing directly from the HTML.

<head>
  <script src="/assets/js/script_1.js"></script>
  <script src="/assets/js/script_2.js"></script>
  <script src="/assets/js/script_3.js"></script>
</head>

Now, what if we find that script_1.js has a dependency on script_2.js and script_2.js needs to be loaded first? We will have to rearrange the ordering such that all the dependencies are satisfied. Doing this iteratively for hundreds of files can quickly become a nightmare.

One could argue why can't we write all the code in a single JavaScript file in order to avoid this dependency issue. Modern web applications require a lot of JavaScript code, so having all the JavaScript code in a single file is just not practical.

Another issue with referencing hundreds of JavaScript files is that browsers can fetch only four to eight files at a time. If we have hundreds of JavaScript files then the browser will take a long time to load all the JavaScript files.

Solution to all these problems is packing all those JavaScript files into one large file that can be downloaded in one shot. This large file will also have all the code in the right order, which will satisfy the dependency requirement. This process of packing all the JavaScript files into one big file is called bundling. We can use tools like Webpack or Rollup to achieve bundling. These tools that help us achieve bundling are typically called bundlers.

It's obvious that when we use a bundler, it allows us to keep our code in any hierarchy we want for development purposes. After all, the bundler will figure out the dependency. So is the job of the bundler to only stitch all the JavaScript files into one large JavaScript file in the right order?

No. During bundling, a bundler can be configured to apply different transformations and optimizations to our source code. It allows us to write our code using modern syntax while transforming it to a format more commonly supported by different browser implementations during the bundling process. Another common task is the minification of our JavaScript files by removing all unwanted whitespace characters and comments.

We have discussed only a few optimizations and transformations here. Bundlers support many more types of optimizations and transformations.

Loading JavaScript files faster by bundle splitting

Bundle splitting is the process of splitting up this single bundle into multiple chunks. We just talked about the advantages of bundling. Then why are we talking about bundle splitting. As we will see, there are some advantages of splitting the bundle as long as it's done strategically.

Most commonly, bundle splitting splits the code into three separate chunks. A vendor chunk holds every code inside the node_modules folder, an application chunk holds all the code we have written, and a runtime chunk is added by the bundler that enables all other chunks to be loaded properly. If we are using webpack to bundle our application, the default bundle splitting configuration can be found in their documentation. If we use CRA to scaffold our application, an optimal configuration is already in place.

There are different ways in which we can benefit from this process. Thanks to HTTP 2.0, the browsers are now able to fetch resources from the server in parallel. Because of this, instead of waiting for a single huge bundle to be loaded, the browser can load multiple smaller chunks in parallel for a better load time.

On top of that, we can ask the browser to cache a specific JavaScript file. This will make the application load those JavaScript files faster the next time around. Usually, the contents in the vendor chunk are not expected to change frequently and can be reused from the browser cache, cutting down on load time significantly. This is usually achieved by encoding the chunk name with the content hash. This tells the browser: "If the hash changed, assume the content changed, ignore the cache, and fetch the updated chunk from server".

// webpack.config.json

module.exports = {
  //...
  output: {
    filename: "[contenthash].js",
  },
};

Now the question is what factors determine if the bundle should be split into multiple chunks. One such factor is the file location. As mentioned above, files from the node_modules folder are generally kept in the vendor chunk while the application code goes into the application chunk. We can also specify a maximum chunk size in the bundler configuration which creates an additional chunk whenever the current chunk exceeds the size limit.

// webpack.config.json

module.exports = {
  //...
  optimization: {
    splitChunks: {
      maxSize: 15000000, // 15MB in static size, before compression
    },
  },
};

We can take this a step further by loading only those chunks that are necessary to render the content that should be made visible to the user. Other chunks are loaded only when they are truly needed. This is also called lazy loading.

For example, suppose we have an application that offers two pages - a Dashboard page, and a Settings page. A user, after logging in, directly lands on the Dashboard page. Normally, the loaded JavaScript bundle will also include code related to the Settings page, which is not required to render the current Dashboard page. The Settings code just sits there, waiting for the user to navigate to the Settings page.

This is the problem that lazy loading attempts to resolve. The easiest way to achieve this is to import the code during runtime using an inline import statement. React offers a wrapper for integrating lazy-loaded components using Suspense.

import React, { Suspense } from "react";

const LazyComponent = React.lazy(() => import("./LazyComponent"));

const Component = () => (
  <Suspense fallback={<div>Loading LazyComponent</div>}>
    <LazyComponent />
  </Suspense>
);

It means, during the bundling process, whenever a lazy import is encountered by the bundler, the code in the required module will be kept as a separate "async" chunk which is loaded only on demand. In the prior example, we can have the Settings component is lazily imported so that when a user goes to the Dashboard page, the Settings-related code will not be part of this bundle, resulting in a lower initial bundle size.

We can verify the results using tools like Bundle Analyzer Plugin that allow us to visualize and inspect the size and contents of each chunk in the bundler output.

The lazy loading above may seem very promising, and we may be tempted to split every part of the application into different chunks, expecting a more efficient loading experience. However, this may not always be the case. Unlike other methods, lazy loading requires careful evaluation of different parts of the application and their dependencies to determine which parts can be effectively lazy-loaded.

Let's bring back the above example. Suppose our Settings page requires API calls to load data and render the content. If the code for the Settings page is part of the same initial bundle, as soon as we navigate to the Settings page, the API requests are fired, data is fetched, and content is rendered. Point to note that the JavaScript code for the Settings page is already loaded, so the API call was instantly made.

Now, what if the Settings code was split into a different on-demand chunk and not part of the initial bundle? No, when we navigate to the Settings page, the browser needs to fetch the Settings chunk from the server, execute, send network requests, and then render the content. An additional delay is introduced here for fetching chunks, which may add to the slowness. In a way, this brings down the benefits offered by a single-page application (SPA).

When splitting up the bundle for our product NeetoChat, we chose to split the Settings related code into a separate, on-demand chunk. The Settings was not a random choice. It took up a large part of the bundle and one interesting feature was that the Settings page didn't require data from the server to render. In this case Settings page contains a predefined set of category tiles that allow us to navigate to other settings-related pages.

For the reasons mentioned above, the Settings appeared to be a good candidate for lazy-loading, and therefore, all the related code was extracted to a few separate asynchronous bundles. After this change, when a user loads the dashboard page of NeetoChat, the loaded bundles do not contain code related to any of the Settings page,s thereby having a smaller overall initial asset size.

Later, when the user navigates to the Settings page, the related JavaScript chunks are fetched, and the UI is rendered immediately without the need for API data. From the Settings page, the user can choose any of the Settings categories to navigate to the inner pages. The inner pages require API data to render the content. However, the required JS assets are already loaded and available to execute as part of the last asset request on the landing page, thereby reducing the network latency.

For more fine-grained control over lazy-loading implementation in our app, we are using the react-loadable library. Video below walks you through the bundle splitting process and results in the NeetoChat web application.

Watch on YouTube

The backend code was fairly clean because of the convention-over-configuration philosophy of the Ruby on Rails framework. But, since React is just a JS library, developers have the complete freedom to write code in all possible ways JavaScript would allow.

In the initial stages, when we were building only 4-5 products, the only enforcement mechanism we had was pull request reviews, apart from basic linting using ESLint and code formatting using Prettier. PR reviews quickly turned inefficient as the number of products grew. The code reviewers started missing some of the new changes to the coding standards and continued suggesting the outdated standard. This led to inconsistent code and behavior between products.

At that time, we thought of building our custom ESLint plugin. Initially, we expected it to be very hard because of the need to deal with the language AST to identify the code that didn't follow our standards. However, after some research, we discovered a FOSS tool, astexplorer, which shows a visual representation of JavaScript AST. With that, writing ESLint plugins for non-standard code became easy.

The custom plugin was a huge success during the POC itself. It helped us significantly in improving the quality of the front-end code. At the time of writing this blog, we have 50 custom ESLint rules enforced by the plugin.

The plugin was named eslint-plugin-neeto, adhering to ESLint's plugin naming conventions. Later, we namespaced it under @bigbinary, to be consistent with our other frontend packages. Now the plugin is available as @bigbinary/eslint-plugin-neeto.

Enforcing ESLint at neeto

In the overall development flow, ESLint will run on three levels.

1. IDE extension (optional)

   Even though BigBinary doesn't have any IDE preference, the majority of developers use Visual Studio Code here. The popular ESLint extension on VS Code runs ESLint while the developer is writing code and gives immediate visual feedback with squiggly lines.

   

   The use of IDE extension is completely optional. We have enforcement mechanisms at other levels to ensure the code quality & standards.

2. Pre-commit hook

   There are some ESLint rules like sort-imports that are only meant to keep code consistency. Even though functionality-wise, there is nothing wrong with keeping the imports in any order, this rule would throw an error if the imports are not correctly sorted.

   Secondly, developers will see this error frequently because most IDEs add the new import statement to the bottom of the imports list during auto-import.

   

   But, we believe that developers should not be concerned about errors like these. They should be focusing on the business logic rather than spending time on things that are auto-correctable. At the same time, we need this rule to be auto-fixed at some point to keep consistency.

   So, we chose Git's pre-commit hooks for automatically fixing such errors. We used husky to add eslint --fix command to the pre-commit hook. Also, we used lint-staged to run the commands only on the files that are included in the current commit. Thus, we automated lint-fixing and formatting of the files that we are going to commit.

   If any rule violations aren't auto-fixable, the commit would fail with an error. Developers can get the details of the rule violation from the error message, make corrections themselves, and commit again.

   

3. CI checks

   VS Code extension and pre-commit hooks are great tools to warn developers early and it saves time. However, VS Code extensions and pre-commit hooks are not something we can rely on fully. That's because the developer can skip these if they prefer to.

   Here are some cases where things might not work out:

   • Lint checks from both the pre-commit hook and VS Code extension won't run if the developer forgets to run yarn install while setting up the repository. This is because the installation and setting up of all the npm packages in a repository is done by yarn install command. So, the packages eslint, husky, and lint-staged won't be available to run until yarn install is run.
   • Developers can manually skip Git's pre-commit hooks by running git commit --no-verify. The --no-verify flag indicates that I want to commit the changes, but I don't want the hooks to run and block me.

   To ensure that the code that goes into the repository is lint-free, we need to implement continuous integration (CI) checks. With CI checks in place, the PR (Pull Request) reviewer can know whether a PR meets the quality standards just by looking into this section of the PR:

   Passing CI checks

   Failing CI checks

   From the CI checks, we will run ESLint without the --fix flag. The goal of CI checks is to detect and report lints and not correct them.

   For CI, currently, we are using an in-house developed tool named NeetoCI.

Challenges we faced

neeto is building a lot of products. All these products had a lot of code written in a non-standard way. It meant that when we got started with the code standardization task, we had to deal with a large amount of code to fix.

Some of the non-standard codes were auto-correctable. For such cases, we published ESLint rules withan auto-fixer. Whenever anyone makes any changes in a file containing that non-standard code pattern, it would get auto-corrected during the pre-commit hook execution. It was easy.

But some cases weren't auto-fixable. For such patterns, we published the ESLint rule and then asked a few engineers to go through all projects and run the command eslint app/**/*.{js,jsx,json}. It would reveal all pieces of code that violate the new rule. Those errors had to be fixed manually. We named this process rollout.

While doing this, we realized that we were not thinking much about false positives and true negatives. We started encountering them a lot during the rollout. It forced us to make fixes, publish the updates again to npm, and redo the rollout. This was inefficient.

After facing such incidents, we decided to clone all repos locally and test the changes in all products before raising PR. Even though it was hard at the beginning, it proved to be quite effective in detecting all possible edge cases of a rule.

Later, we began developing rules for more complex, abstract standards. It was impossible to detect and flag all non-standard code patterns for them. If we stressed covering more cases, we would start getting several false positives along with it.

A good example would be the hard-coded-strings-should-be-localized rule. The aim was to force people to use i18next based localization instead of hardcoding strings in English. In other words, all the strings that are supposed to be rendered on the DOM should come from the translation files.

If we were to flag all string literals as errors in the code, we would have more false positives than real errors. There were several strings like enum keys that were used only in the application logic. They will never be rendered on UI. There is no point in applying localization to them.

As you might guess, there is no way an ESLint plugin could tell if a string is going to be rendered in the UI or if it is used only in the application logic. To circumvent this, we decided to raise an error if the string contains a space character in it. Since enum keys didn't contain spaces, it eliminated a lot of false positives. But, it created a lot of true negatives. We were missing all one-word strings that were rendered in the UI.

Also, even with that change, we didn't fully eliminate false positives. There were several cases where we used space-separated strings in the application logic. An example is classNames prop. It usually contains a space-separated string of CSS classes (like classNames="flex justify-center").

To minimize such edge cases, we added a whitelist for property names like classNames which should always be ignored, and a blacklist for properties like label which should always be flagged even if it is a single word. With that change, we were able to lower the false positives and true negatives to a great extent.

Even with all this logic in place, we weren't confident that we have eliminated false positives fully. So we decided to publish this rule as a warning. ESLint warnings are less strict than errors. VS Code extension would still show yellow squiggly lines and we would still get warning statements while running pre-commit hooks. But the pre-commit hook won't fail when a warning is encountered. The same applies to the CI checks.

Lessons learned

In the case of ESLint rules, false positives are more harmful than true negatives. If a false positive error is raised, it would confuse the developers. Even though they are writing code in the right way, the plugin would complain that it is an error. Some developers might even write some tricky code to circumvent the ESLint error, thinking that it is genuine.

We always try to minimize false positives by testing the rule with the existing code in several repos before publishing it. In some cases, we can't avoid very rare false positives to favor a large number of true negatives. If a developer encounters false positives for such rules, they are advised to disable the rule for that specific line of code.

Building ESLint rules not only helped us improve the code quality but also gave us exposure to AST parsing and manipulation. With the help of that new knowledge, we were able to accomplish several other achievements. As an example, we have built a custom Babel plugin that could generate the boilerplate code of fetching values from a Zustand store at compile time. You can read about how you can build your own ESLint and Babel plugins on our upcoming blogs. Stay tuned.

ESLint is a widely adopted JavaScript linter that analyzes and enforces coding rules and guidelines. ESLint empowers developers by detecting errors, promoting best practices, and enhancing code readability. This blog explores the fundamental concepts of ESLint, from installing the necessary dependencies to customizing rules, and integrating these custom rules into your host projects.

Configure ESLint on a project

To set up ESLint in your host project, install the ESLint package under devDependencies as it is only used for development and not in production:

  npm install -D eslint
  #or
  yarn add -D eslint

Now, you need to provide the required ESLint configurations. You can generate your ESLint config file using any of the below commands:

  npx eslint --init
  #or
  yarn run eslint --init

This will prompt multiple options. You can proceed by selecting options that suit your use case. This generates a config file called .eslintrc in the format you selected (.json, .js, etc). Here is an example of .eslintrc.js:

module.exports = {
  root: true,
  env: {
    node: true,
    browser: true,
    es2021: true,
  },
  parserOptions: {
    ecmaVersion: 2021,
    sourceType: "module",
  },
  extends: ["eslint:recommended", "plugin:react/recommended"],
  plugins: ["react"],
  rules: {
    "no-console": "warn",
    "no-unused-vars": "error",
  },
  settings: {
    react: {
      version: "detect",
    },
  },
};

• The root property is set to true to indicate that this is the root configuration file and should not inherit rules from parent directories.

• The env property specifies the target environments where the code will run, including node, browser, and es2021 for ECMAScript 2021 features.

• In parserOptions, we specify JavaScript options like JSX support or ECMA version.

• The plugins property specifies the ESLint plugins to be used. Let us say you are working on a React project. You want your code to follow some React best practices and React-specific rules. You can achieve this by adding eslint-plugin-react.

• The extends property includes an array of preset configurations to extend from, like eslint:recommended and plugin:react/recommended.

• The settings property includes additional settings for specific plugins. In this case, we set the React version to detect for the React plugin, so that the React version is detected from our package.json.

• In rules, we specify custom rule configurations for the codebase. For instance, the rule no-unused-vars helps identify and throw errors for unused variables in your code, while no-console warns against using console.log() statements in production code. All pre-existing rules are available in this documentation by ESLint. Rules have three error levels:

  rules: {
    "no-console": "warn", // Can also use 1
    "no-unused-vars": 2, // Can also use "error"
    "no-alert": "off", // Can also use 0
  }
  

  • “error” or 2: This will turn on the rule as an error. This means that ESLint will report violations of this rule as errors. Rules are typically set to error to enforce compliance with the rule during continuous integration testing, pre-commit checks, and pull request merging because doing so causes ESLint to exit with a non-zero exit code.

  • “warn” or 1: If you don’t want to enforce compliance with a rule but would still like ESLint to report the rule’s violations, set the severity to warn. This will report violations of this rule as warnings.

  • “off” or 0: This means the rule is turned off and will not be enforced. This can be useful if you want to disable a specific rule temporarily throughout your project or if you don't find a particular rule relevant to your project.

Custom rules

While ESLint comes bundled with a vast array of built-in rules, its true potential lies in the ability to create custom rules tailored to your project's unique requirements.

At the heart of every ESLint rule lies a well-crafted JavaScript object that defines its behavior. But, before we dive into the basic structure of a custom ESLint rule, there is something you need to get familiar with, called an AST (Abstract Syntax Tree).

Abstract Syntax Tree (AST)

AST can be thought of as an interpreter that dissects your code and represents it in a tree-like structure of interconnected nodes. An ESLint parser converts code into an abstract syntax tree that ESLint can evaluate. Consider the following JavaScript code snippet:

const sum = (x, y) => x + y;

This is how its AST looks:

In this example, the root node is the Program node, which represents the entire code file. Within it, there are several nested nodes, VariableDeclarator, ArrowFunctionExpression, and so on, each dedicated to different parts of the code. As demonstrated in the animation, when hovering over each node, the corresponding code segment on the LHS is highlighted. To explore and interact with both code and its AST, you can utilize the AST Explorer tool.

Basic structure of a custom rule

Now that you know what AST is, let us learn how these trees help us in creating a custom rule. You will need to analyze the code's tree structure to find out which node is to be chosen as the visitor node. A visitor node represents the target node that is visited or traversed during the linting process.

To understand further, let us take into account a simple rule and try to build it. Let us implement no-var rule. This rule encourages the use of let and const keywords, instead of var keyword to declare variables. This usage promotes block scoping and prevents any re-declarations.

The AST for a code snippet containing var would look like this:

So, the node we are interested in examining is the VariableDeclaration node. Hence, this will be our visitor node. This node contains an attribute called kind, which contains the value var, let, or const depending on the keyword used. All we have to do is verify whether it is a var and then throw an error for that particular node.

We want this logic to run on all VariableDeclaration nodes:

if (node.kind === "var") {
  // raise error
}

Let us embed that logic inside an ESLint rule object:

module.exports = {
  meta: {
    type: "problem", // Can be: "problem", "suggestion" or "layout".
    docs: {
      description: "Disallow the use of var.",
      category: "Best Practices",
    },
  },
  create: context => ({
    VariableDeclaration(node) {
      if (node.kind === "var") {
        context.report({ node, message: "Using var is not allowed." });
      }
    },
  }),
};

• The meta object provides metadata about your rule, including its type, description, category, etc.
• The create function is the entry point for your rule implementation. It is called by ESLint and provides the context object, which allows you to interact with the code being analyzed.
• Within the create function, you can define one or more visitor methods that target specific node types in the AST. The rule logic will be defined inside the visitor methods. In our example, the logic needs to be run only on all VariableDeclaration nodes. Thus VariableDeclaration is the only visitor method defined.
• You can check for violations and report errors using context.report().

This is an example of how your rule would throw an error to that particular node, once integrated into your project:

Testing ESLint rules

Rule testing in ESLint involves verifying the behavior of custom rules by providing sample code snippets that should trigger violations (invalid cases) and code snippets that should pass without violations (valid cases). RuleTester is an ESLint utility that simplifies the process of defining and running such tests.

Configuring RuleTester

First, you need to create a RuleTester instance. You can fine-tune the parser options, environments, and other configurations when you create the instance:

const { RuleTester } = require("eslint");

const ruleTester = new RuleTester({
  parserOptions: {
    ecmaFeatures: { jsx: true },
    ecmaVersion: 2020,
    sourceType: "module",
  },
});

Writing test cases

Now, you can use RuleTester's run() method to craft scenarios in the valid and invalid arrays to cover all possible code variations, which will be tested against your rule. Also, you can provide the expected error message, as the message property in errors. Your basic test will look something like this, for the no-var rule you implemented:

const { RuleTester } = require("eslint");

const rule = require("../rules/no-var");

const ruleTester = new RuleTester({
  parserOptions: {
    ecmaFeatures: { jsx: true },
    ecmaVersion: 2020,
    sourceType: "module",
  },
});

ruleTester.run("no-var", rule, {
  valid: ["let x = 10;", "const x = 10;"],
  invalid: [
    {
      code: "var x = 10;",
      errors: [{ message: "Using var is not allowed." }],
    },
  ],
});

console.log("Completed all tests for no-var rule");

Diving deeper into custom rule creation

Let us create another rule, that enforces the use of strict equality (===) over loose equality (==). Strict equality provides more accurate comparison results and helps prevent potential bugs caused by type coercion.

Basic implementation

1. Create a new file called strict-equality.js.

2. Define the rule by providing a type, description, and create function to implement our logic.

   module.exports = {
     meta: {
       type: "problem",
       docs: {
         description: "Enforce the use of strict equality.",
         category: "Best Practices",
       },
     },
     create: context => ({
       //Implementation logic.
     }),
   };
   

3. Now we need to figure out the visitor node we need. This is where you can use AST Explorer. Let us consider the below example:

   if (a == b) {
     //Do something
   }
   

   We can see that the AST notation for the same looks something like this:

   {
     "type": "Program",
     "body": [
       {
         "type": "IfStatement",
         "test": {
           "type": "BinaryExpression",
           "operator": "==",
           "left": {
             "type": "Identifier",
             "name": "a"
           },
           "right": {
             "type": "Identifier",
             "name": "b"
           }
         },
         // Remaining attributes
       }
     ]
   }
   

   From this, it is evident that the node we are interested in has the type BinaryExpression. All we have to check is whether the operator for this node is "==" and then throw an error for that particular node.

4. Let us write this logic into our create function, and report the error with a suitable message:

   create: context => ({
     BinaryExpression(node) {
      if (node.operator !== "==") return;
   
      context.report({
        node,
        message: "Use strict equality instead of loose equality.",
      });
     },
   }),
   

Implementing automatic fix

Right now, all our rule does is detect any loose equalities and show the error message for that line. Let us add some logic to provide an automatic fix for the detected errors. To achieve this, include the fix attribute in the context.report() method. We can create a string representing the corrected code and utilize the replaceText function provided by the context.fixer object to replace the specific node with the modified string. To know about all such functions offered by the fixer object, please check this documentation, on applying fixes.

Now, we need to create a string to replace the node with. Inspect this portion of the AST we generated earlier:

"type": "BinaryExpression",
"operator": "==",
"left": {
  "type": "Identifier",
  "name": "a"
},
"right": {
  "type": "Identifier",
  "name": "b"
}

The LHS and RHS of the operands can be accessed as, node.left and node.right respectively. The value of these operands can be fetched from the name attribute and our fix string can be constructed like this:

`${node.left.name} === ${node.right.name}`;

Hence adding this logic to our rule:

module.exports = {
  meta: {
    // Other properties
    fixable: "code", // Include this, when your rule provides a fix.
  },
  create: context => ({
    BinaryExpression(node) {
      if (node.operator !== "==") return;

      context.report({
        node,
        message: "Use strict equality instead of loose equality.",
        fix: fixer => fixer.replaceText(
          node,
          `${node.left.name} === ${node.right.name}`
        );
      });
    },
  }),
};

But, what if the LHS or RHS contains expressions, like these:

if(array[index].type == a)

In that case, node.left will have more nested nodes:

Now, we can't just proceed by using node.left.name. So, how do we make sure that we don't lose any data? The getSourceCode() function is a utility provided by ESLint that allows you to retrieve the source code corresponding to a specific node in the context. We can obtain the source code as a string by using getText() function on the node. So for the above example, we can write:

context.getSourceCode().getText(node.left); // Returns `array[index].type`

Now, let us modify our create function to handle this edge case and our completed rule would look like this:

module.exports = {
  meta: {
    type: "problem",
    docs: {
      description: "Enforce the use of strict equality.",
      category: "Best Practices",
    },
    fixable: "code",
  },
  create: context => ({
    BinaryExpression(node) {
      if (node.operator !== "==") return;

      context.report({
        node,
        message: "Use strict equality instead of loose equality.",
        fix: fixer => {
          const leftNode = context.getSourceCode().getText(node.left);
          const rightNode = context.getSourceCode().getText(node.right);

          return fixer.replaceText(node, `${leftNode} === ${rightNode}`);
        },
      });
    },
  }),
};

Adding tests for the rule

In our earlier sections, you saw how to write tests for your custom rule. Now, let us implement the same for our strict-quality rule. We need to add valid and invalid cases as strings to the respective arrays. Inside, the invalid array, you can make use of the output attribute to provide the expected fixed code for that particular invalid case. So our tests will look like this:

const { RuleTester } = require("eslint");

const rule = require("../rules/strict-equality");

const ruleTester = new RuleTester({
  parserOptions: {
    ecmaFeatures: { jsx: true },
    ecmaVersion: 2020,
    sourceType: "module",
  },
});

const message = "Use strict equality instead of loose equality.";

ruleTester.run("strict-equality", rule, {
  valid: [
    "if (a === b) {}",
    "if (a === b) alert(1)",
    "if (a === b) { alert(1) }",
  ],
  invalid: [
    {
      code: "if (a == b) {}",
      errors: [{ message }],
      output: "if (a === b) {}",
    },
    {
      code: "if (getUserRole(user) == Roles.DEFAULT) grantAccess(user);",
      errors: [{ message }],
      output: "if (getUserRole(user) === Roles.DEFAULT) grantAccess(user);",
    },
  ],
});

console.log("Completed all tests for strict-equality rule");

Custom ESLint plugins

In real-world scenarios, we will have multiple custom rules and configurations that we want to enforce consistently across our projects. This is where custom ESLint plugins become invaluable, as they allow us to bundle and package all these elements into a single plugin. In the Neeto ecosystem, we use our custom plugin, eslint-plugin-neeto, to maintain a uniformly structured codebase.

In this section, we will create a custom ESLint plugin for the custom rules we created, and learn how to integrate it into our projects.

Getting started with a custom plugin

1. Create a new directory and initialize a new npm package for your plugin. The package name should always follow the naming format, eslint-plugin-* :

   mkdir eslint-plugin-custom
   cd eslint-plugin-custom
   npm init -y
   

2. Arrange our previously defined rules and tests in this folder structure:

   eslint-plugin-custom
   ├── package.json
   ├── index.js
   ├── src
   │   └── rules
   │     └── no-var.js
   │     └── strict-equality.js
   │   └── tests
   │     └── index.js
   │     └── no-var.js
   │     └── strict-equality.js
   └── README.md
   

3. Let us add ESLint as a devDependency in our plugin.

   npm install -D eslint
   

Adding and exporting custom rules

Copy the rules we created into no-var.js and strict-equality.js. Now, how do we help the plugin find our rules? You can add the following to index.js in the plugin's root directory:

module.exports = {
  rules: {
    "no-var": require("./src/rules/no-var"),
    "strict-equality": require("./src/rules/strict-equality"),
  },
};

By configuring the index file in this way, you ensure that ESLint recognizes and associates your custom rule with the specified name, making it accessible in ESLint configurations.

Adding test files

In a similar manner to how rules are handled, we can establish a unified entry point for our tests in src/tests/index.js:

require("./no-var.js");
require("./strict-equality.js");

You can either set up any test framework of your choice to run the tests or run them directly using:

node src/tests

Explore the complete code for the custom plugin, containing both the rules and their corresponding tests that we have developed this far, in eslint-plugin-custom.

Integrating the custom plugin

You saw in earlier sections that, it is possible to test your rules using RuleTester. While this method helps you specify all the edge cases and test your rules against them, it is not that easy, to think of all possible edge cases. For this, we need to run our rules in real projects and we will have to achieve this without publishing our package to the remote registry right away.

• Integrate and test locally using yalc

  Yalc acts as a very simple local repository for your locally developed packages that you want to share across your local environment. Let us see how we can use yalc to test our custom plugin on host projects.

  1. Install yalc globally:

     npm install -g yalc
     

  2. Navigate to the root directory of your custom plugin and publish it to the local yalc store:

     cd eslint-plugin-custom
     yalc publish
     

  3. Navigate to the root directory of the host project. Add the custom plugin using yalc:

     cd my-host-project
     yalc add eslint-plugin-custom
     

  4. Update your ESLint configuration in the host project to include the plugin and its rules in .eslintrc.js:

     module.exports = {
       //Other configurations
       plugins: ["custom"],
       rules: {
         "custom/no-var": "error",
         "custom/strict-equality": "error",
         //Other rules
       },
     };
     

     Here, we have excluded the prefix eslint-plugin-, while specifying the plugin name and used only the word custom. ESLint automatically recognizes plugins without the eslint-plugin- prefix when specified in the configuration file. Trimming off this prefix is a common practice to simplify the plugin name and make it more user-friendly in the context of the host project.

     We also namespaced the rule under their respective plugins. By doing so, we ensure that ESLint can distinguish between conflicting rule names if any, and apply the correct rules based on your configuration.

  5. Testing the custom plugin in the host project:

     • This can be done by running ESLint rules for a specific file:

       npx eslint <file_path>
       #or to apply and test fixes
       npx eslint --fix <file_path>
       

     • You can use a glob pattern, such as **/*.js, to run ESLint on the entire project by specifying the file path pattern that matches the desired files to be linted:

       npx eslint "./app/javascript/src/**/*.{js,jsx,json}"
       

     • You can integrate ESLint to VSCode by installing the ESLint extension. Once installed, to apply any changes made to ESLint configurations, simply restart the ESLint server, by opening the Command Palette (Ctrl+Shift+P or Cmd+Shift+P) and search for "ESLint: Restart ESLint Server". This will help you see red squiggly lines under the code containing the error. It is a good visual representation of our ESLint rule.

       

     Do not forget to note down any edge cases you come across, so that you can refactor your rule's logic to cover those cases.

  6. Every time you make a change in your plugin, you can push those changes to your host projects by running the following command from your ESLint plugin's root directory:

     yalc push
     

  7. Once you are done with testing your plugin locally, remove it from the package.json of your host project by running the following command from your host project's root directory:

     yalc remove eslint-plugin-custom
     

• Integrating published plugin package

  Once you publish the plugin into the remote registry, you can integrate it into your host projects.

  1. Add the custom plugin as a devDependency to your project using the command:

     yarn add -D "eslint-plugin-custom"
     

  2. Configure ESLint to enable your custom rules. We have already added the necessary configurations in step 6, of integrating using yalc.

Adding a recommended configuration

When dealing with multiple host projects, it becomes a repetitive task to include the same rules and error levels in each project. Any updates or adjustments to these rules would then need to be applied across all projects individually. To streamline this process, the recommended configuration lets us keep all those configs within the ESLint plugin itself. This way, we can easily maintain and modify the rules without the need for duplicating efforts in every project.

Imagine we want to recommend using our current rules as warnings. In that case, we can add a recommended config in our eslint-plugin-custom's index.js:

module.exports = {
  rules: {
    "no-var": require("./src/rules/no-var"),
    "strict-equality": require("./src/rules/strict-equality"),
  },
  configs: {
    recommended: {
      rules: {
        "custom/no-var": "warn",
        "custom/strict-equality": "warn",
      },
    },
  },
};

In the host project, where you want to use your custom plugin, you can install the plugin and configure ESLint to extend the recommended configuration in .eslintrc.js:

{
  "extends": [
    "eslint:recommended",
    "plugin:custom/recommended"
  ],
  // Other ESLint configurations for your project.
  "rules": {
    // Other project-specific rules.
  }
}

General tips on using ESLint

In this section, we will explore some general tips and tricks that will empower you to navigate through false positives, troubleshoot common pitfalls, and handle ESLint warnings well.

Handling false positives

Sometimes, ESLint can be overzealous and flag code as incorrect even when it's acceptable. Alternatively, there may be instances where we intentionally choose to adopt a particular coding style and wish to prevent ESLint from throwing errors. Here are a couple of strategies to address these errors:

1. Disabling ESLint rules:

   You can temporarily disable the rule responsible for the false alarm by adding a comment above the code, like this:

   // eslint-disable-next-line <rule_name>
   

   Example:

   // Reason for disabling the rule.
   // eslint-disable-next-line no-console
   console.log("All tests were executed");
   

   Do not forget to specify the reason why you have disabled that particular rule for that line, to avoid any future confusion.

2. Altering configuration:

   ESLint provides an option to configure a rule as per your needs. Some rules accept additional options to customize its behavior. An example is, camelcase. It enforces the use of camel case for variable names. It accepts options to disable enforcing camel casing for specific cases. In a case where, you want to use a different naming convention, such as snake case, for object keys, you can set the properties option to never:

   // .eslintrc
   {
     "rules": {
       "camelcase": ["error", { "properties": "never" }]
     }
   }
   

   This configuration tells ESLint to exclude properties (object keys) from the camel case requirement.

   We can accept options in our custom rules and access them inside our rules via context.options. Then, you can perform the necessary logic to handle such cases.

Common reasons for ESLint checks to crash

While using ESLint, you might encounter situations where ESLint checks crash or fail unexpectedly. Keep these in mind to avoid such crashes:

1. If you update or switch ESLint configurations, make sure to run yarn install or npm install to install any missing dependencies.

2. Ensure that your ESLint configuration has accurate parser options, like the language version and ECMAScript features, as they are crucial for ESLint to parse and analyze your code correctly.

Should we consider ESLint warnings?

As we've seen in previous sections, ESLint allows us not only to report errors but also to show warnings. When creating a rule, it may not always be possible to cover every edge case and eliminate all false positives. In such situations, we can configure these rules as warnings instead. Additionally, there are cases where we don't want to enforce a specific coding style but rather suggest a more optimized approach to the developer. In such scenarios as well, we avoid throwing errors.

While ESLint warnings don't necessarily require disabling through comments, it's recommended to review and address them whenever feasible. This practice improves code quality, helps prevent future errors, and enhances the overall robustness of the codebase. However, if you find that the suggestion does not apply to your specific situation, you have the flexibility to disregard it or disable it by including a comment.

Conclusion

Throughout this blog, we explored various aspects of ESLint, including understanding its purpose and benefits, configuring rules on a project, writing custom rules and plugins, and testing them effectively. We also discussed general tips for using ESLint, such as handling false positive errors, dealing with crashes, and considering warnings.

Remember to periodically review and update your ESLint configurations as your project evolves, and stay up-to-date with the latest ESLint releases and rule updates to take advantage of new features and improvements. To know more about functionalities of ESLint, you can refer the ESLint documentation.

At BigBinary, we are always looking to improve our code. Ramda's focus on functional-style programming with immutable and side-effect-free functions aligns with this goal, making it our preferred choice.

While working on neeto, we found the need for specific functions that could be applied across a range of products but were not already included in Ramda. We extended Ramda's functions to meet this need and created our own pure utility functions.

In this blog, we'll explore our motivation for creating these functions and the benefits they provide, showcasing how they can be generally applicable to a wide range of products.

The matches function: the core of our pure utility functions

During the development of Neeto, we encountered instances where long conditional chains were used to search for objects with deeply nested properties.

For example, consider this userOrder object:

const userOrder = {
  id: 12356,
  user: {
    id: 2345,
    name: "John Smith",
    role: "customer",
    type: "standard",
    email: "john@example.com",
  },
  amount: 25000,
  type: "prepaid",
  status: "dispatched",
  shipTo: {
    name: "Bob Brown",
    address: "456 Oak Lane",
    city: "Pretendville",
    state: "Oregon",
    zip: "98999",
  },
};

We can check if this order is deliverable like this.

const isDeliverable =
  userOrder.type === "prepaid" &&
  useOrder.user.role === "customer" &&
  userOrder.status === "dispatched";

This approach works but it can be simplified.

Our goal was to simplify the process by focusing on comparing all the keys of the pattern to the corresponding keys in the data. If the pattern matches with the object, the function should return true. With that in mind, we developed a function named matches to determine if a given object matches a specified pattern.

With matches we should be able to rewrite isDeliverable as:

const isDeliverable = matches(DELIVERABLE_ORDER_PATTERN, userOrder);

Here the DELIVERABLE_ORDER_PATTERN is defined as:

const DELIVERABLE_ORDER_PATTERN = {
  type: "prepaid",
  status: "dispatched",
  user: { role: "customer" },
};

This is how we implemented the matches function:

const matches = (pattern, object) => {
  if (object === pattern) return true;

  if (isNil(pattern) || isNil(object)) return false;

  if (typeof pattern !== "object") return false;

  return Object.entries(pattern).every(([key, value]) =>
    matches(value, object[key])
  );
};

Here, we noticed a limitation in this implementation of the matches function. It compared the keys and values in the data and the pattern only for strict equality. We were not able to use the matches function for a situation like the one mentioned below.

To check if the userOrder is being shipped to the city of Michigan or Oregon, we were not able to call matches function on the key state. Instead, we had to use the following approach along with other conditions.

const isToBeShippedToMichiganOrOregon =
  ["Michigan", "Oregon"].includes(userOrder.shipTo.state) &&
  // other long chain of conditions

To cover that, we decided to allow functions as key values in the pattern object. With this change, we should be able to write the same as the following.

matches(
  {
    shipTo: { state: state => ["Michigan", "Oregon"].includes(state) },
    // ...other properties
  },
  userOrder
);

Here is the modification we have made to the matches function to accomplish this feature:

const matches = (pattern, object) => {
  if (object === pattern) return true;

  if (typeof pattern === "function" && pattern(object)) return true;

  if (isNil(pattern) || isNil(object)) return false;

  if (typeof pattern !== "object") return false;

  return Object.entries(pattern).every(([key, value]) =>
    matches(value, object[key])
  );
};

As a result of these improvements, the matches function can now handle a wider range of patterns.

const user = {
  firstName: "Oliver",
  address: { city: "Miami", phoneNumber: "389791382" },
  cars: [{ brand: "Ford" }, { brand: "Honda" }],
};

matches({ cars: includes({ brand: "Ford" }) }, user); //true
matches({ firstName: startsWith("O") }, user); // true

Here, both includes and startsWith are methods from Ramda and they are both curried functions. We will be talking about currying of functions in the upcoming section.

Neeto's pure utility functions for array operations

With the help of the matches function, it became easier for us to work on our next task at hand: building utility functions that simplify array operations.

*By functions

Let's say we have an array of users:

const users = [
  {
    id: 1,
    name: "Sam",
    age: 20,
    address: {
      street: "First street",
      pin: 123456,
      contact: {
        phone: "123-456-7890",
        email: "sam@example.com",
      },
    },
  },
  {
    id: 2,
    name: "Oliver",
    age: 40,
    address: {
      street: "Second street",
      pin: 654321,
      contact: {
        phone: "987-654-3210",
        email: "oliver@example.com",
      },
    },
  },
];

If we need to retrieve the details of user with the name Sam, we will do it like this in plain vanilla JS:

const sam = users.find(user => user.name === "Sam");

Since we already have the matches function, we could easily create a utility function that would return the same result as above while removing extra code.

That's how we came up with the findBy function that can be used to find the first item that matches the given pattern from an array.

We defined findBy like this:

const findBy = (pattern, array) => array.find(item => matches(pattern, item));

Now we were able to rewrite our previous array operation as:

const sam = findBy({ name: "Sam" }, users);

It was also now possible for us to write nested conditions like these:

findBy({ age: 40, address: { pin: 654321 } }, users);
// returns details of the first user with age 40 whose pin is 654321
findBy({ address: { contact: { email: "sam@example.com" } } }, users);
// returns details of the first user whose contact email is "sam@example.com"

We adopted the concept of currying from Ramda to shorten our function definitions and their usage.

Currying is a technique in functional programming where a function that takes multiple arguments is transformed into a sequence of functions, each taking a single argument. Simply said, currying translates a function from callable as f(a, b, c) into callable as f(a)(b)(c). You can learn more about currying and Ramda from our free Learn RamdaJS book.

We wrapped the definition of matches inside the curry function from Ramda as shown below:

const matches = curry((pattern, object) => {
  //...matches function logic
});

With this update, the findBy function could be simplified to:

const findBy = (pattern, array) => array.find(matches(pattern));

We also used curry wrapping for findBy function for the same reason:

const findBy = curry((pattern, array) => array.find(matches(pattern)));

Similar to findBy we also introduced the following functions to simplify development:

• findIndexBy(pattern, data): finds the first index of occurrence of an item that matches the pattern from the given array.
• filterBy(pattern, data): returns the filtered array of items based on pattern matching.
• findLastBy(pattern, data): finds the last item that matches the given pattern.
• removeBy(pattern, data): removes all items that match the given pattern from an array of items.
• countBy(pattern, data): returns the number of items that match the given pattern.
• replaceBy(pattern, newItem, data): replaces all items that match the given pattern with the given item.

Here are some example usages of these functions:

findIndexBy({ name: "Sam" }, users);
//returns the array index of Sam in "users"

filterBy({ address: { street: "First street" } }, users);
//returns a list of "users" who lives on First street

removeBy({ name: "Sam" }, users); // removes Sam from "users"

countBy({ age: 20 }, users);
// returns the count of "users" who are exactly 20 years old.

findLastBy({ name: includes("e") }, users);
// returns the last user whose name contains the character 'e', from the array.

const newItem = { id: 2, name: "John" };
replaceBy({ name: "Sam" }, newItem, users);
/*
[
  { id: 2, name: "John" },
  { id: 2, name: "Oliver", age: 40,
  //... Oliver's address attributes },
];
*/

*ById functions

Applications frequently rely on unique IDs for data retrieval. As a result, when using By functions, pattern matching for the ID becomes necessary.

const defaultUser = findBy({ id: DEFAULT_USER_ID }, users);

To shorten this code, we developed a set of utility functions that can be invoked directly based on the ID. Let us call them ById functions. With ById functions, we can rewrite the previous code as:

const defaultUser = findById(DEFAULT_USER_ID, users);

Here are some of the ById functions we use:

• findById(id, data): finds an object having the given id from an array.
• replaceById(id, newItem, data): returns a new array with the item having the given id replaced with the given object.
• modifyById(id, modifier, data): applies a modifier function to the item in an array that matches the given id. It then returns a new array where the return value of the modifier function is placed in the index of the matching item.
• findIndexById(id, data): finds the index of an item from an array of items based on the id provided.
• removeById(id, data): returns a new array where the item with the given id is removed.

Here are a few examples:

findById(2, users); // returns the object with id=2 from "users"

const idOfItemToBeReplaced = 2;
const newItem = { id: 3, name: "John" };
replaceById(idOfItemToBeReplaced, newItem, users);
//[ { id: 1, name: "Sam", age:20, ...}, { id: 3, name: "John" }]

const idOfItemToBeModified = 2;
const modifier = item => assoc("name", item.name.toUpperCase(), item);
modifyById(idOfItemToBeModified, modifier, users);
//[{ id: 1, name: "Sam", ... }, { id: 2, name: "OLIVER", ... }]

const idOfItemToBeRemoved = 2;
removeById(idOfItemToBeRemoved, users);
// [{ id: 1, name: "Sam", ... }]

assoc is a function from Ramda that makes a shallow clone of an object, setting or overriding the specified property with the given value.

Null-safe alternatives for pure functions

The By and ById functions proved to be invaluable to us in improving the code quality. However, when working with data in web applications, it is quite common to come across scenarios where the data being processed can be null/undefined. The above-mentioned implementations of the By and ById functions will fail with an error if the users array passed into them is null/undefined.

In such a case, to use the filterBy function, we need to adopt a method like this:

users && filterBy({ age: 20 }, users);

So we needed a fail-safe alternative that could be used in places where the data array can be null/undefined. This null-safe alternative should avoid execution & return users if users is null/undefined. It should work the same as filterBy otherwise.

Hence we created a wrapper function that would check for data nullity and execute the child function conditionally. This is how we did it:

const nullSafe =
  func =>
  (...args) => {
    const dataArg = args[func.length - 1];

    return isNil(dataArg) ? dataArg : func(...args);
  };

With the help of this nullSafe function, we created null-safe alternatives for all our pure functions.

const _replaceById = nullSafe(replaceById);
const _modifyById = nullSafe(modifyById);

But with the nullSafe wrapping, currying ceased to work for these null-safe alternative functions. To retain currying, we had to rewrite nullSafe using the curryN function from Ramda like this:

const nullSafe = func =>
  curryN(func.length, (...args) => {
    const dataArg = args[func.length - 1];
    return isNil(dataArg) ? dataArg : func(...args);
  });

Some other useful functions

keysToCamelCase

Recursively converts the snake-cased object keys to camel case.

const snakeToCamelCase = string =>
  string.replace(/(_\w)/g, letter => letter[1].toUpperCase());

const keysToCamelCase = obj =>
  Object.fromEntries(
    Object.entries(obj).map(([key, value]) => [
      snakeToCamelCase(key),
      typeof value === "object" && value !== null && !Array.isArray(value)
        ? keysToCamelCase(value)
        : value,
    ])
  );

keysToCamelCase({
  first_name: "Oliver",
  last_name: "Smith",
  address: { city: "Miami", phone_number: "389791382" },
});
/*
{ address: {city: 'Miami', phoneNumber: '389791382'},
  firstName: "Oliver", lastName: "Smith",
}
*/

isNot

Returns true if the given values (or references) are not equal. false otherwise.

const isNot = curry((x, y) => x !== y);

Say, you have a task at hand - finding details about users, but specifically excluding the user named "Sam". In such a scenario, you can retrieve the information as shown below:

filterBy({ name: name => name != "Sam" }, users);

But this could be made more readable and concise if we have a function that finds the non-identical matches from users list. For this, you can use the isNot function.

filterBy({ name: isNot("Sam") }, users);
// returns an array of all users except "Sam"

Earlier, pagination looked like this:

Here, loading the next set of data required the user to click on the next page button.

These days, we use the infinite scroll technique, which automatically loads the next set of data when the user scrolls to the bottom of the list. This is more user-friendly:

Several JS libraries are available to facilitate infinite scroll. But to quench our curiosity about how things work under the hood, it is best to try to implement it from scratch.

To implement infinite scroll, we need to know when the user has scrolled to the bottom of the list to load the next page's data. To know if the user has reached the bottom, we can watch the last element of the list. That is, when the list is scrolled and the last element becomes visible, we know that we are at the bottom.

Detecting the visibility of elements during scroll was a hard problem until recently. We had to hook onto onscroll events of the element and check the boundaries of the elements using getBoundingClientRect function.

Since onscroll event gets fired around 40-50 times per second, performing the operations inside it will become expensive. Moreover, the onscroll function gets executed from the main UI thread. All these together make our web application sluggish.

But now, we have a much more performant alternative for this problem. All popular web browsers support a new API named IntersectionObserver from 2019 onwards.

The advantages of IntersectionObserver API are:

• It doesn't grab the resources from the UI thread. It accepts a callback function that will be fired asynchronously.
• The supplied callback is triggered only when a change in visibility is detected. We can save 40-50 repetitions per second during the scroll.
• We don't need to worry about maintaining boilerplate code for detecting the boundaries & calculating the visibility. We get all useful data as a parameter to the callback function.

The introduction of IntersectionObserver simplified a whole set of requirements like:

• Infinite loading.
• Improving page load time by not fetching resources (like images) that aren't visible until the user scrolls to it. This is called lazy loading.
• Track whether the user has scrolled to and viewed an ad posted on the web page.
• UX improvements like dimming animation for the components that aren't fully visible.

In this blog, we are going to discuss how we can use IntersectionObserver in a React application as hooks.

Creating a hook for detecting visibility changes

We will create a custom hook that will update whenever the specified component scrolls into view and scrolls out of view. Let us name the hook useIsElementVisible. Obviously, it will accept a reference to the component of which visibility need to be monitored as its argument.

It will have a state to store the visibility status of the specified element. It will have a useEffect hook from which we will bind the IntersectionObserver to the specified component.

Here is the basic implementation:

import { useEffect, useState } from "react";

const useIsElementVisible = target => {
  const [isVisible, setIsVisible] = useState(false); // store visibility status

  useEffect(() => {
    // bind IntersectionObserver to the target element
    const observer = new IntersectionObserver(onVisibilityChange);
    observer.observe(target);
  }, [target]);

  // handle visibility changes
  const onVisibilityChange = entries => setIsVisible(entries[0].isIntersecting);

  return isVisible;
};

export default useIsElementVisible;

We can use useIsElementVisible like this:

const ListItem = () => {
  const elementRef = useRef(null); // to hold a reference to the component we need to track

  const isElementVisible = useIsElementVisible(elementRef.current);

  return (
    <div ref={elementRef} id="list-item">
      {/* your component jsx */}
    </div>
  );
};

The component ListItem will get updated whenever the user scrolls to see the div "list-item". We can use the value of isElementVisible to load the contents of the next page from a useEffect hook:

useEffect(() => {
  if (isElementVisible && nextPageNotLoadedYet()) {
    loadNextPage();
  }
}, [isElementVisible]);

This works in theory. But if you try it, you will notice that this doesn't work as expected. We missed an edge case.

The real-life edge case

We use a useRef hook for referencing the div. During the initial render, elementRef was just initialized with null as its value. So, elementRef.current will be null and as a result, the call useIsElementVisible(elementRef.current) won't attach our observer to the element for the first time.

Unfortunately, useRef hook won't re-render when a value is set to it after DOM is prepared. Also, there are no state updates or anything that requests a re-render inside our example component. In short, our component will render only once.

With these in place, useIsElementVisible will never get a reference to the "list-item" div in our previous example.

But there is a workaround for our problem. We can force render the component twice during the first mount.

To make it possible, we will add a dummy state. When our hook is called for the first time (when ListItem mounts), we will update our state once, thereby requesting React to repeat the component render steps again. During the second render, we will already have our DOM ready and we will have the target element attached to elementRef.

Force re-rendering the component

To keep our code clean and modular, let us create a dedicated custom hook for managing force re-renders:

import { useState } from "react";

const useForceRerender = () => {
  const [, setValue] = useState(0); // we don't need the value of this state.
  return () => setValue(value => value + 1);
};

export default useForceRerender;

Now, we can use it in our useIsElementVisible hook this way:

const useIsElementVisible = target => {
  const [isVisible, setIsVisible] = useState(false);

  const forceRerender = useForceRerender();

  useEffect(() => {
    forceRerender();
  }, []);

  // previous code to register observer

  return isIntersecting;
};

With this change, our hook is now self-sufficient and fully functional. In our ListItem component, isElementVisible will update to false and trigger component re-render whenever our "list-item" div goes outside visible zone during scroll. It will also update to true when it is scrolled into visibility again.

Possible improvements on useIsElementVisible hook

The useIsElementVisible hook shown in the previous sections serves only the basic use case. It is not optimal to use in a production world.

These are the scopes for improvement for our hook:

• We can let in configurations for IntersectionObserver to customize its behavior.
• We can prevent initializing observer when the target is not ready yet (when it is null).
• We can add a cleanup function to stop observing the element when our component gets unmounted.

Here is what the optimum code for the hook should look like:

import { useEffect, useState } from "react";

export const useForceRerender = () => {
  const [, setValue] = useState(0); // we don't need the value of this state.
  return () => setValue(value => value + 1);
};

export const useIsElementVisible = (target, options = undefined) => {
  const [isVisible, setIsVisible] = useState(false);
  const forceUpdate = useForceRerender();

  useEffect(() => {
    forceUpdate(); // to ensure that ref.current is attached to the DOM element
  }, []);

  useEffect(() => {
    if (!target) return;

    const observer = new IntersectionObserver(handleVisibilityChange, options);
    observer.observe(target);

    return () => observer.unobserve(target);
  }, [target, options]);

  const handleVisibilityChange = ([entry]) =>
    setIsVisible(entry.isIntersecting);

  return isVisible;
};

While working on an app that generates image from a tweet and lets you save it, I wanted to add the ability to let users copy the image directly to clipboard. The implementation seemed simple until I started working on it. The problem is that browsers have different specs for writing a blob to the clipboard.

In this article, we'll learn to write a function that generates an image from an element and saves it in the clipboard. Also since browsers handle things differently, we'll see how to copy an image to the clipboard work on Safari and Chrome(and its variants).

Things to know before we start

• Unfortunately, there's no way(or I haven't found one) to copy a blob image to clipboard in Firefox.
• There's no way to copy multiple images in one go.

Creating an image from an element

Below is a function that utilises domtoimage library to return an image blob from the element screenshotRef.current.

We can use yarn add dom-to-image to install the package.

Instead of screenshotRef.current used in the function, we can pass the id or className of the element we want to generate the image from. More about how domtoimage works can be learned here.

const snapshotCreator = () => {
  return new Promise((resolve, reject) => {
    try {
      const scale = window.devicePixelRatio;
      const element = screenshotRef.current; // You can use element's ID or Class here
      domtoimage
        .toBlob(element, {
          height: element.offsetHeight * scale,
          width: element.offsetWidth * scale,
          style: {
            transform: "scale(" + scale + ")",
            transformOrigin: "top left",
            width: element.offsetWidth + "px",
            height: element.offsetHeight + "px",
          },
        })
        .then((blob) => {
          resolve(blob);
        });
    } catch (e) {
      reject(e);
    }
  });
};

Copying an image to clipboard in Safari

First, we'll need a check to see if the browser is Safari. You can use below check to detect Safari.

const isSafari = /^((?!chrome|android).)*safari/i.test(
  navigator?.userAgent
);

Now that we have the check, we can use the function to copy the image to clipboard.

const copyImageToClipBoardSafari = () => {
  if(isSafari) {
    navigator.clipboard
      .write([
        new ClipboardItem({
          "image/png": new Promise(async (resolve, reject) => {
            try {
              const blob = await snapshotCreator();
              resolve(new Blob([blob], { type: "image/png" }));
            } catch (err) {
              reject(err);
            }
          }),
        }),
      ])
      .then(() =>
        // Success
      )
      .catch((err) =>
        // Error
        console.error("Error:", err)
      );
  }
}

We're using navigation.clipboard.write property to write an image blob to clipboard. Inside it, we're creating a new ClipboardItem from the blob of the element which is generated from snapshotCreator() function which we created in first step.

Copying an image to clipboard in other browsers

Since this method doesn't work in Firefox, we'll need a check to make sure we're not running it on Firefox. Below condition takes care of that.

const isNotFirefox = navigator.userAgent.indexOf("Firefox") < 0;

Now that we have the check, we'll use the same technique as we used for Safari, but this time we'll need to ask the browser for the navigator permissions.

Below is the function that does that and then copies the blob image to the clipboard in Chrome browser and its variants.

const copyImageToClipBoardOtherBrowsers = () => {
  if(isNotFirefox) {
    navigator?.permissions
      ?.query({ name: "clipboard-write" })
      .then(async (result) => {
        if (result.state === "granted") {
          const type = "image/png";
          const blob = await snapshotCreator();
          let data = [new ClipboardItem({ [type]: blob })];
          navigator.clipboard
            .write(data)
            .then(() => {
              // Success
            })
            .catch((err) => {
              // Error
              console.error("Error:", err)
            });
        }
    });
  } else {
    alert("Firefox does not support this functionality");
  }
}

The difference is not much except that Chrome and its variants require asking for navigator.permissions before we can write the blob content to clipboard. The above function uses the same snapshotCreator() function from the first step to create an image from the element.

We can combine both the functions together to have this functionality work in Safari and Chrome browser. You can check how it works on this page, just click on "Copy Image" button and then you'll be able paste the image anywhere.

1. Install Docker Extension for VSCode

This extension will be responsible for VSCode to debug an app inside the Docker container. It will also enable us to manage Docker images and containers.

2. Expose port 9229 in the docker-compose.yml

Port 9229 is the default node.js debugging port.

This will bind the port of the container with that of the host machine enabling the VSCode debugger to attach to the port.

version: "3.9"
services:
  backend:
    container_name: nodejs
    restart: always
    build:
      context: .
    ports:
      - "80:3000"
      - "5678:5678"
      - "9229:9229"
    command: yarn dev

OR

If you are directly running the app from command line, then you can append: -p 9229:9229 to the docker-run command. Example:

docker run -d -p 80:3000 -p 9229:9229 node:15.0.1-alpine

3. Add the inspect switch to the npm script

nodemon --inspect=0.0.0.0:9229 --watch server server/bin/www

Make sure you add the address and port to the inspect switch. When started with the --inspect switch, a node.js process listens for a debugging client. By default, it will listen to the host and port 127.0.0.1:9229. For Docker, we would have to update it to 0.0.0.0:9229.

4. Create a VSCode launch.json

You can generate a launch.json from the Debug tab of VSCode. Click on the drop down and select Add Configuration.

This action would generate a default JSON configuration. Replace the content with the below:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Docker: Attach to Node",
      "type": "node",
      "request": "attach",
      "restart": true,
      "port": 9229,
      "address": "localhost",
      "localRoot": "${workspaceFolder}",
      "remoteRoot": "/usr/src/app",
      "protocol": "inspector"
    }
  ]
}

5. Start the docker container and attach the debugger.

After your Docker container has been successfully launched, you can attach the debugger to it at any time by clicking the play button in the same Debug tab where we built the launch.json configuration.

VSCode will now adjust the color of its bottom status bar to indicate that it is in debugging mode, and you are ready to go.

You can put breakpoints anywhere in your file and get your work done faster and better than before.

Bonus Tip

Since the debugger has full access to the Node.js execution environment, a malicious agent who can bind to this port will be able to execute arbitrary code on the Node.js process's behalf. It is important to understand the security implications of exposing the debugger port on public and private networks. Make sure you are not exposing the debugging port in production environment.

Also, with the upcoming Babel 8.0.0 release, the team is aiming to ship Babel as native ES Modules. With this goal in mind, the team is shifting all CommonJS imports/exports to ESM ones. This is where I got the opportunity to contribute to Babel recently.

Why ES Modules though?

For a very long time, JS (or ECMAScript) did not have a standardized module import/export syntax. Various independent packages introduced formats to help work with modules in JS. Most browsers used the AMD API (Asynchronous Module Definition) implemented in the Require.js package, which had its own syntax and quirks.

CommonJS on the other hand was the standard used by Node.js, and it was no less quirky. Inconsistent formatting and poor interoperability between packages irked JS developers enough to demand a standard format.

Lately, the ECMAScript Standardization body (TC39) has adopted ESM (ECMAScript modules) as the standard format for Javascript. Most web browsers already support this format and Node.js 14 now provides stable support for it.

The task at hand

The next task was to convert all internal top-level scripts from using CommonJS to ESM. The finer details of the implementation, along with interoperability issues with non-ESM files, would trouble CommonJS for some time though.

The simplest of changes was to replace require() statements in each file with import statements. For example, files starting like:

"use strict";

const plumber = require("gulp-plumber");
const through = require("through2");
const chalk = require("chalk");

would be modified like here:

import plumber from "gulp-plumber";
import through from "through2";
import chalk from "chalk";

to allow modules to be imported as ES modules.

In the above example also note that because ES modules are in strict mode by default, so "use strict"; declarations were removed from the beginning of these top-level scripts.

Almost all current NPM packages are CommonJS packages, exposing their functionalities using the module.exports syntax.

In case a file/package exports more than one value, we need to use named imports instead:

import { chalk } from "chalk";

Where the default export object from a CommonJS module was named differently, it had to be aliased during import to avoid breaking pre-existing variables' names in the files being converted to ESM. For example,

const rollupBabel = require("@rollup/plugin-babel").default;

had to be replaced with:

import { babel as rollupBabel } from "@rollup/plugin-babel";

so we could keep using the variable rollupBabel in the file.

For instances where require() statements needed to be replaced by the dynamic import() statements

const getPackageJson = (pkg) => require(join(packageDir, pkg, "package.json"));

// replaced by
const getPackageJson = (pkg) => import(join(packageDir, pkg, "package.json"));

the subsequent calls everywhere now needed to be awaited:

   .forEach(id => {
      const { name, description } = getPackageJson(id);
   })

   //await added
   .forEach(id => {
      const { name, description } = await getPackageJson(id);
   })

Other things like importing JSON modules are currently only supported in CommonJS mode. Those imports were left as-is.

Blockers

With all the changes made and committed, we bumped into the next big roadblock: package dependencies. Babel uses Yarn 2 internally, and particularly the PnP feature of Yarn 2. Unfortunately, the ESM loader API was experimental at the time and not being used by PnP. The Babel and Yarn teams coordinated to implement it soon after.

Similarly, Jest has its own custom loader for ESM, which meant it could not support testing ESM modules with Babel. That issue was side-stepped for the time being.

Network effects

The good thing about the whole grind of shifting from CommonJS to ESM is that a lot of other major packages are also considering and implementing ESM support. The shift to ESM-only by Babel is already building confidence in others to do the same. Special thanks to the Babel maintainers for setting a great example and encouraging others to move to ESM.

Conclusion

All told, it was a great experience adding a new feature into a well-maintained and widely-used package. The biggest lesson from this has to be how changes made in Babel affect and influence other major packages, and how maintainers of various major open source packages work in tandem to avoid breaking each other's code. It is a very open and collaborative ecosystem with people discussing and working through github issues, comments, and even twitter threads.

Check out the pull request for more details.

• "always" - Wrap prose if it exceeds the print width.
• "never" - Do not wrap prose.
• "preserve" - Wrap prose as-is. (First available in v1.9.0)

Now, this does not exactly give a clear idea on what each feature does, and it could be a little confusing especially between the "never" and "preserve" options.

In the below video we walk you through these options and tries to get you a clear idea on Prettier's Prose Wrap and its use-case.

Links to the pages mentioned in the above video

• Prose Wrap Documentation
• Prettier's Philosophy
• Prettier's Playground
• Github comments not compliant with GFM soft line breaks?

This application is a JavaScript-heavy application as most consumer-oriented applications are these days. We recently changed the JavaScript build system for Gumroad from RequireJS to webpack. We'd like to talk about how we went about doing this.

Gumroad's web application is built using Ruby on Rails. The project was started way back in 2011 as this hacker news post suggests. When we began working on the code it was building JavaScript assets through two systems Sprockets and RequireJS. From what we could tell, all the code which was using a new(at the time) frontend framework was processed by RequireJS first and then sprockets whereas the JavaScript files which are usually present under app/javascrips/assets and vendor/assets/javascripts in a typical Rails application were present as well but they were not being processed by RequireJS. Also, there were some libraries which were sourced using Bower.

We were tasked with the work of migrating the RequireJS build system over to webpack and replacing Bower with NPM. The reason behind this was that we wanted to use newer tools with wider community support. Another reason was that we wanted to be able to take advantage of all the goodies that webpack comes with though that was not a strong motivation at that point.

We decided to break down the task into small pieces which could be worked on in iterations and, more importantly, could be shipped in iterations. This would enable us to work on other tasks in the application in parallel and not be blocked on a big chunk of work. Keeping that in mind we split the task in three different steps.

Step 1: Migrate from RequireJS to webpack with the minimal amount of changes in the actual code.

Step 2: Use NPM packages in place of Bower components.

Step 3: Use NPM packages in place of libraries present under vendor/assets/javascripts.

Step 1: Migrate from RequireJS to webpack with the minimal amount of changes in the actual code

The first thing we did here was create a new webpack.config.js configuration file which would be used by webpack. We did our best to accurately translate the configuration from the RequireJS configuration file using multiple resources available online.

Here is how most JavaScript files which were to be processed by RequireJS looked like.

"use strict";

define(["braintree", "$app/ui/product/edit", "$app/data/product"], function (
  Braintree,
  ProductEditUI,
  ProductData
) {
  // Do something with Braintree, ProductEditUI, and ProductData
});

As you can see, the code did not use the newer import statements which you'd see in comparatively newer JavaScript code. As we've mentioned earlier, our goal was to have minimal code changes so we did not want to change to import just yet. Luckily for us, webpack supports the define API for specifying dependencies. This meant that we would not need to change how dependencies were specified in any of the JavaScript files.

In this step we also changed the build system configuration (The webpack.config.js file in this case) to use NPM packages where possible instead of using libraries from the vendor/ directory. This meant that we would need to have aliases in place for instances where the package name was different from the names we had aliased the libraries to.

For example, this is how the 'braintree' alias was set earlier in order to refer to the Braintree SDK. Now all the code had to do was to mention that braintree was a dependency.

require.config({
  paths: {
    braintree: "/vendor/assets/javascripts/braintree-2.16.0",
  },
});

With the change to use the NPM package in place of the JavaScript file the dependency sourcing did not work as expected because the NPM package name was 'braintree-web' and the source code was trying to load 'braintree' which was not known to the build system(webpack). In order to avoid making changes to source code we used the "alias" feature provided by webpack as shown below.

module.exports = {
  resolve: {
    alias: {
      braintree: "braintree-web",
    },
  },
};

We did this for all the dependencies which had been given an alias in the RequireJS configuration and we got dependency resolution to work as expected.

As a part of this step, we also created a new common chunk and used it to improve caching. You can read more about this feature here. Note that we would tweak this iteratively later but we thought it would be good to get started with the basic configuration right away.

Step 2: Use NPM packages in place of Bower components

Another goal of the migration was to remove Bower so as to make the build system simpler. The first reason behind this was that all Bower packages which we were using were available as NPM packages. The second reason was that Bower itself is recommending users to migrate to Yarn/webpack for a while now.

What we did here was simple. We removed Bower and the Bower configuration file. Then, we sourced the required Bower components as NPM packages instead by adding them to package.json. We also removed the aliases added to source them from the webpack configuration.

For example, here's the change required to the configuration file after sourcing clipboard as an NPM package instead of a Bower component.

resolve: {
  alias: {
    // Other Code

    $app:           path.resolve(__dirname, '../../app/javascript'),
    $lib:           path.resolve(__dirname, '../../lib/assets/javascripts')
-   clipboard:      path.resolve(__dirname, '../../vendor/assets/javascripts/clipboard.min.js')
  }
}

Step 3: Use NPM packages in place of libraries present under vendor/assets/javascripts

We had a lot of javascript libraries present under vendor/assets/javascripts which were sourced in the required javascript files. We deleted those files from the project and sourced them as NPM packages instead. This way we could have better visibility and control over the versions of these packages.

As part of this migration we also did some asset-related cleanups. These included removing unused JavaScript files, including JavaScript files only where required instead of sourcing them into the global scope, etc.

We were continuously measuring the performance of the application before and after applying changes to make sure that we were not worsening the performance during the migration. In the end, we found that we had improved the page load speeds by an average of 2%. Note that this task was not undertaken to improve the performance of the application. We are now planning to leverage webpack features and try to improve on this metric further.

Using Google Map polylines

We used polylines to draw individual routes on Google maps.

Polyline is composed of line segments connecting a list of points on the map. The more points we use for drawing a polyline the more detailed the final curve will be. Here's how we added route points to the map.

// List of latitude and longitude
let path = points.map(point => [point.lat, point.lng]);

let route_options = {
  path: path,
  strokeColor: color,
  strokeOpacity: 1.0,
  strokeWeight: mapAttributes.strokeWeight || 3,
  map: map, // google.maps.Map
};

new google.maps.Polyline(route_options);

Here's an example of a polyline on a Google map. We used 422 latitude and longitude points to draw these routes which makes it look more contiguous.

We needed to show 200 deliveries in that map. On an average a delivery contains around 500 route points. This means we need to load 1,00,000 route points. Let's measure and see how much time the whole process takes.

Loading multiple routes on a map

Plotting a single route on a map can be done in less than a second. However as we increase the number of routes to plot, the payload size increases which affects the load time. This is because we've around 500 route points per delivery. If we want to show 500 deliveries on the map then we need to load 500 * 500 = 2,50,000 routes points. Let's benchmark the load time it takes to show deliveries on a map.

No. of deliveries | Load Time | Payload Size | 500 | 8.77s | 12.3MB | 400 | 7.76s | 10.4MB | 300 | 6.68s | 7.9MB | 200 | 5.88s | 5.3MB | 100 | 5.47s | 3.5MB |

The load time is more than 5 seconds which is high. What if we could decrease the payload size and still be able to plot the routes.

Sampling route points for decreased payload size

For each delivery we've around 500 route points. If we drop a few route points in between on a regular interval then we'll be able to decrease the payload size. Latitude and longitude have at least 5 decimal points. We rounded them off to 1 decimal point and then we picked unique values.

  def route_lat_lng_points
    return '' unless delivery.route_lat_lng_points

    delivery.route_lat_lng_points.
        chunk{ |point| [point.first.round(1), point.second.round(1)] }.
        map(&:first).join(',')
  end

Now let's check the payload size and the load time.

No. of deliveries | Load Time | Payload Size | 500 | 6.52s | 6.7MB | 400 | 5.97s | 5.5MB | 300 | 5.68s | 4.2MB | 200 | 4.88s | 2.9MB | 100 | 4.07s | 2.0MB |

The payload size decreased by 50 percent. However since we sampled the data the routes are not contiguous anymore. Here's how it looks now.

Note that we sampled route points till single decimal point. Notice that the routes in which we did sampling appears to be jagged instead of contiguous. We can solve this by using a curve fitting method to create a curve from the discrete points we have.

Curve fitting using B-spline function

B-spline or basis spline is a spline function which can be used for creating smooth curves best fitted to a set of control points. Here's an example of a B-spline curve created from a set of control points.

We changed our previous example to use B-spline function to generate latitude and longitude points.

// List of latitude and longitude
let lats = points.map(point => point.lat);
let lngs = points.map(point => point.lng);
let path = bspline(lats, lngs);

let route_options = {
  path: path,
  strokeColor: color,
  strokeOpacity: 1.0,
  strokeWeight: mapAttributes.strokeWeight || 3,
  map: map, // instance of google.maps.Map
};

new google.maps.Polyline(route_options);

function bspline(lats, lngs) {
  let i, t, ax, ay, bx, by, cx, cy, dx, dy, lat, lng, points;
  points = [];

  for (i = 2; i < lats.length - 2; i++) {
    for (t = 0; t < 1; t += 0.2) {
      ax = (-lats[i - 2] + 3 * lats[i - 1] - 3 * lats[i] + lats[i + 1]) / 6;
      ay = (-lngs[i - 2] + 3 * lngs[i - 1] - 3 * lngs[i] + lngs[i + 1]) / 6;

      bx = (lats[i - 2] - 2 * lats[i - 1] + lats[i]) / 2;
      by = (lngs[i - 2] - 2 * lngs[i - 1] + lngs[i]) / 2;

      cx = (-lats[i - 2] + lats[i]) / 2;
      cy = (-lngs[i - 2] + lngs[i]) / 2;

      dx = (lats[i - 2] + 4 * lats[i - 1] + lats[i]) / 6;
      dy = (lngs[i - 2] + 4 * lngs[i - 1] + lngs[i]) / 6;

      lat =
        ax * Math.pow(t + 0.1, 3) +
        bx * Math.pow(t + 0.1, 2) +
        cx * (t + 0.1) +
        dx;

      lng =
        ay * Math.pow(t + 0.1, 3) +
        by * Math.pow(t + 0.1, 2) +
        cy * (t + 0.1) +
        dy;

      points.push(new google.maps.LatLng(lat, lng));
    }
  }
  return points;
}

Source: https://johan.karlsteen.com/2011/07/30/improving-google-maps-polygons-with-b-splines

After the change the plotted routes are much better. Here's how it looks now.

The only downside here is that if we zoom in the map we'll notice that the routes are not exactly overlapping the Google map paths. Otherwise we're able to plot almost same routes with sampled route points. However we still need 6.5 seconds to load 500 deliveries. How do we fix that ?

Loading deliveries in batches

Sometimes users have up to 500 deliveries but they want to change only a few deliveries and then use the application. Right now the way application is setup users have no choice but to wait until all 500 deliveries are loaded and then only they would be able to change a few deliveries. This is not ideal.

We want to show deliveries as soon as they're loaded. We added a polling mechanism that would load batches of 20 deliveries and as soon as a batch is loaded we would plot them on the map. This way user could interact with the loaded deliveries while the remaining deliveries are still being loaded.

  loadDeliveriesWindow(updatedState = {}, lastPage = 0, currentWindow = 1) {
    // windowSize: Size of the batch to be loaded
    // perPage: No of deliveries per page
    const { perPage, windowSize } = this.state;

    if (currentWindow > perPage / windowSize) {
      // Streaming deliveries ended
      this.setState($.extend(updatedState, { windowStreaming: false }));
      return;
    }

    if (currentWindow === 1) {
      // Streaming deliveries started
      this.setState({ windowStreaming: true });
    }

    // Gets delivery data from backend
    this.fetchDeliveries(currentWindow + (lastPage * windowSize), queryParams).complete(() => {
      // Plots deliveries on map
      this.loadDeliveries();

      // Load the next batch of deliveries
      setTimeout((() => {
        this.loadDeliveriesWindow(updatedState, lastPage, currentWindow + 1);
      }).bind(this, currentWindow, updatedState, lastPage), 100);
    });
  }

Here's a comparison of how the user experience changed.

Notice that loaded deliveries are instantly plotted and user can start interacting with them. While if we load all the deliveries before plotting them the user has to wait for all of them to be loaded. This made the user experience much better if the user loaded more than 100 deliveries.

Serializing route points list without brackets

One more optimization we did was to change how route points are being serialized.

The route points after serialization contained opening and closing square brackets. So let's say the route points are

[[25.57167, -80.421271], [25.676544, -80.388611], [25.820025, -80.386488],...].

After serialization they looked like

[[25.57167,-80.421271], [25.676544,-80.388611], [25.820025,-80.386488],...].

For each route point we've an extra opening and closing square bracket which can be avoided.

We could get rid of the brackets by concatenating the route points array and converting it to a string. After conversion it looked like this.

"25.57167,-80.421271|25.676544,-80.388611|25.820025,-80.386488|..."

At the client side we converted it back to an array. This reduced the payload size by 0.2MB for dense routes.

Note this is a trade off between client side processing and network bandwidth. In modern computers the client side processing will be negligible. For our clients, network bandwidth was a crucial resource so we optimized it for network bandwidth.

Recently, Honeybadger released a new feature to upload the source maps to Honeybadger. We have written a grunt plugin to upload the source maps to Honeybadger.

Here is how we can upload source map to Honeybadger.

First, install the grunt plugin.

npm install --save-dev grunt-honeybadger-sourcemaps

Configure the gruntfile.

grunt.initConfig({
  honeybadger_sourcemaps: {
    default_options:{
      options: {
        appId: "xxxx",
        token: "xxxxxxxxxxxxxx",
        urlPrefix: "http://example.com/",
        revision: "<app version>"
        prepareUrlParam: function(fileSrc){
          // Here we can manipulate the filePath
          return filesrc.replace('built/', '');
        },
      },
      files: [{
        src: ['@path/to/**/*.map']
      }],
    }
  },
});
grunt.loadNpmTasks('grunt-honeybadger-sourcemaps');
grunt.registerTask('upload_sourcemaps', ['honeybadger_sourcemaps']);

We can get the `appId` and `token` from Honeybadger project settings.


~~~plaintext
grunt upload_sourcemaps

Now, we can upload the source maps to Honeybadger and get better error stack trace.

Testing

Clone the following repo.

git clone https://github.com/bigbinary/grunt-honeybadger-sourcemaps

Replace appId and token in Gruntfile.js and run grunt test. It should upload the sample source maps to your project.

Here is code without R.

function isUnique(element, selector) {
  const parent = element.parentNode;
  const elements = parents.querySelectorAll(selector);
  return elements.length === 1 && elements[0] === element;
}

Code with R.

function isUnique(element, selector) {
  const querySelectorAll = R.invoker(1, 'querySelectorAll')(selector);

  return R.pipe(
    R.prop('parentNode'),
    querySelectorAll,
    elements => R.both(
                  R.equals(R.length(elements), 1),
                  R.equals(elements[0], element)
                );
  )();
}

Is the refactored code better ?

What is R? What's invoker? What's pipe?

The "code without R" reads fine and even a person who has just started learning JavaScript can understand it. Then why take all this extra complexity. Shouldn't we be writing code that is easier to understand ?

Good questions. Who could be against writing code that is easier to understand.

If all I'm writing is a function called isUnique then of course the "before version" is simpler. However this function is part of a bigger thousands of lines of code software.

A big software is nothing but a collection of smaller pieces of code. We compose code together to make code work.

We need to optimize for composability and as we write code that is more composable, we are finding that composable code is also easier to read.

At BigBinary we have been experimenting with composability. We previously wrote a blog on how using Recompose is making our React components more composable.

Now we are trying same techniques at pure JavaScript level using Ramda.js.

Let's take a look at another examples.

Example 2

We have a list of users with name and status.

var users = [
  { name: "John", status: "Active" },
  { name: "Mike", status: "Inactive" },
  { name: "Rachel", status: "Active" },
];

We need to find all active users. Here is a version without R.

jsfiddle{:.code-link}

var activeUsers = function (users) {
  return users.filter(function (user) {
    var status = user.status;
    return status === "Active";
  });
};

Here is code with R.

jsfiddle{:.code-link}

var isStatusActive = R.propSatisfies(R.equals("Active"), "status");
var active = R.filter(isStatusActive);
var result = active(users);

Now let's say that user data changes and we have a user with an empty name. We don't want to include such users. Now data looks like this.

var users = [
  { name: "John", status: "Active" },
  { name: "Mike", status: "Inactive" },
  { name: "Rachel", status: "Active" },
  { name: "", status: "Active" },
];

Here is modified code without R.

jsfiddle{:.code-link}

var activeUsers = function (users) {
  return users.filter(function (user) {
    var status = user.status;
    var name = user.name;
    return (
      name !== null &&
      name !== undefined &&
      name.length !== 0 &&
      status === "Active"
    );
  });
};

Here is modified code with R.

jsfiddle{:.code-link}

var isStatusActive = R.propSatisfies(R.equals("Active"), "status");
var active = R.filter(isStatusActive);
var isNameEmpty = R.propSatisfies(R.isEmpty, "name");
var rejectEmptyNames = R.reject(isNameEmpty);
var result = R.pipe(active, rejectEmptyNames)(users);
log(result);

Notice that change we needed to do to accommodate this request.

In the none R version, we had to get into the gut of the function and add logic. In the with R version we added new function and we just composed this new function with old function using pipe. We did not change the existing function.

Now let's say that we don't want all the users but just the first two users. We know what need to change in the without R version. In the with R version all we need to do is add R.take(2) and no existing function changes at all.

Here is the final code.

jsfiddle{:.code-link}

var isStatusActive = R.propSatisfies(R.equals("Active"), "status");
var active = R.filter(isStatusActive);
var isNameEmpty = R.propSatisfies(R.isEmpty, "name");
var rejectEmptyNames = R.reject(isNameEmpty);

var result = R.pipe(active, rejectEmptyNames, R.take(2))(users);
log(result);

Data comes at the end

Another thing to notice is that in the R version nowhere we have said that we are acting on the users. All the functions have no mention of users. In fact all the functions do not take any argument explicitly since the functions are curried. When we want result then we are passing users as the argument but it could be articles and our code will still hold.

This is pointfree programming. We do not need to know about "pointfree" since this comes naturally when write with R.

I'm still not convinced that Ramda.js is solving any real problem

No problem.

Please watch Hey Underscore, You're doing it wrong video by Brian Lonsdorf. Hopefully that will convince you to give Ramda.js a try.

Watch on YouTube

If you are still not convinced then, the author of Ramda.js has written a series of blogs called Thinking in Ramda. Please read the blogs. Slowly.

Ramda brings functional concepts to JavaScript

Functional programming is another way of thinking about the code. When we move to Elm, Haskell or Elixir to get functional concepts then we are wrestling with two things at once - a new language and functional concepts.

Ramda.js brings functional concepts to JavaScript. In this way we can slowly start using functional concepts in our day to day JavaScript code.

The best part is that if you write any JavaScript code then you can start using Ramda.js today. Whether you are using React.js or Angular.js, it's all JavaScript and you can use Ramda.js.

Generate package.json

If you don't already have a package.json file then execute the following command to create a package.json file with value {}.

echo "{}" > package.json

Install prettier

Now execute following command to install prettier.

npm install --save-dev lint-staged husky prettier

# Ignore `node_modules`
echo "/node_modules" >> .gitignore
echo "/package-lock.json >> .gitignore

Add scripts & ignore node_modules

Now open package.json and replace the whole file with following content.

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "app/**/*.{js,es6,jsx}": [
      "./node_modules/prettier/bin/prettier.js --trailing-comma --single-quote es5 --write",
      "git add"
    ]
  },
  "devDependencies": {
    "husky": "^0.13.4",
    "lint-staged": "^3.6.0",
    "prettier": "^1.4.2"
  }
}

Note that if you send pull request with your changes and circleCI or such tools run npm install then downgrade husky to ^0.13.4 and that will solve the problem.

In Ruby on Rails applications third party vendor files are stored in vendor folder and we do not want to format JavaScript code in those files. Hence we have applied the rule to run prettier only on files residing in app directory.

Here at BigBinary we store all JavaScript files using ES6 features with extension .es6. Hence we are running such files through prettier. Customize this to match with your application requirements.

Note that "pre-commit" hook is powered by husky. Read up "husky" documentation to learn about "prepush" hook and other features.

Commit the change

git add .
git commit -m "Added support for prettier for JavaScript files"

Execute prettier on current code

./node_modules/prettier/bin/prettier.js --single-quote --trailing-comma es5 --write "{app,__{tests,mocks}__}/**/*.{js,es6,jsx,scss,css}"

We want more

We were thrilled to see prettier format our JavaScript code. We wanted more of it at more places. We found that prettier can also format CSS files. We changed our code to also format CSS code. It was an easy change. All we had to do was change one line.

Before : "app/**/*.{js,es6,jsx}"

After : "app/**/*.{js,es6,jsx,scss,css}"

Inspired by prettier we welcomed rubocop

Now that JavaScript and CSS files are covered we started looking at other places where we can get this productivity gain.

Since we write a lot of Ruby code we turned our attention to rubocop.

It turned out that "rubocop" already had a feature to automatically format the code.

Open package.json and change lint-staged section to following

"app/**/*.{js,es6,jsx,scss,css}": [
  "./node_modules/prettier/bin/prettier.js --single-quote --trailing-comma es5 --write",
  "git add"
],
"{app,test}/**/*.rb": [
  "bundle exec rubocop -a",
  "git add"
]

Open Gemfile and add following line.

group :development do
  gem "rubocop"
end

The behavior of rubocop can be controlled by .rubocop.yml file. If you want to get started with the rubocop file that Rails uses then just execute following command at the root of your Rails application.

wget https://raw.githubusercontent.com/rails/rails/master/.rubocop.yml

Open the downloaded file and change the TargetRubyVersion value to match with the ruby version the project is using. ` value to match with the ruby version the project is using.

Execute rubocop in all ruby files.

bundle install
bundle exec rubocop -a "{app}/**/*.rb"

Code is changed on git commit and not on git add

We notice that some people were a bit confused when git add did not format the code.

Code is formatted when git commit is done.

npm install is important

It's important to note that users need to do npm install for all this to work. Otherwise prettier or rubocop won't be activated and they will silently fail.

Full package.json file

After all the changes are done then package.json should be like as shown below.

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "app/**/*.{js,es6,jsx,scss,css}": [
      "./node_modules/prettier/bin/prettier.js --trailing-comma es5 --write",
      "git add"
    ],
    "{app,test}/**/*.rb": [
      "bundle exec rubocop -a",
      "git add"
    ]
  },
  "devDependencies": {
    "husky": "^0.13.4",
    "lint-staged": "^3.6.0",
    "prettier": "^1.4.2"
  }
}

function* genFunc(){...}

Calling genFunc() doesn't execute the body of the function.

const genObj = genFunc();

Instead, it returns generator object which can be used to control the execution of the generator.

genObj.next() will start executing the function and it will execute till it reaches yield keyword.

We can think of yield as return for now. It is similar to C# yield.

function* genFunc() {
  console.log("First");
  yield;
  console.log("Second");
}
const genObj = genFunc();
genObj.next();

/*
output

First
*/

Calling genObj.next() again will resume the further execution after yield.

function* genFunc() {
  console.log("First");
  yield;
  console.log("Second");
}
const genObj = genFunc();
genObj.next();
genObj.next();

/*
output

First
Second
*/

Here's how the execution looks like:

yield is not allowed inside non-generator functions. That is, yielding in callbacks doesn't work.

We can also pass the data to generator function via next.

function* genFunc() {
  console.log("First");
  const input = yield;
  console.log(input);
  console.log("Second");
}
const genObj = genFunc();
genObj.next();
genObj.next("Third");

/*
output

First
Third
Second
*/

We can retrieve the yielded values via the generator object genObj:

function* genFunc() {
  console.log("First");
  const input = yield;
  console.log(input);
  console.log("Second");
  yield "Forth";
}
const genObj = genFunc();
genObj.next();
const result = genObj.next("Third");
console.log(result);

/*
output

First
Third
Second
{
  done: false,
  value: "Forth"
}
*/

We can have multiple yield in the function as shown in the above example.

Once, the execution of the generator function is completed, further calls to genObj.next() will have no effect.

Further reading

We highly recommend Exploring ES6 by Dr. Axel Rauschmayer to go deeper on this topic.

Let's say we want to convert following ES6 code using Babel.

let a = 10;
let b = 42;

if (a < b) {
  console.log("a is less than b");
} else {
  console.log("b is less than a");
}

It will get translated to:

"use strict";

var a = 10;
var b = 42;

if (a < b) {
  console.log("a is less than b");
} else {
  console.log("b is less than a");
}

All good so far. Let's try Babel's constant folding plugin (Link is not available). I am compiling the ES6 code from command line this time.

babel --plugins constant-folding index.js --out-file bundle.js -w

This gives us following output:

"use strict";

var a = 10;
var b = 42;

if (true) {
  console.log("a is less than b");
} else {
  console.log("b is less than a");
}

If condition changed from (a < b) to (true). The constant-folding plugin has smartly evaluated the conditional expression a < b and replaced the code with the result of that expression.

This plugin can also optimize other expressions as shown below.

// Unary operators
console.log(!true);

// Binary expression
console.log(20 + 22);

// Function calls
console.log(Math.min(91, 2 + 20));

Which gets optimized to:

// Unary operators
console.log(false);

// Binary expression
console.log(42);

// Function calls
console.log(22);

How does this actually work?

Though we are using a "constant folding plugin" to achieve this optimization, the real work happens in Babel itself.

For every expression in the code, the constant folding plugin calls evaluate function from Babel source code. This function checks whether it can confidently find end value for a given expression.

The evaluate function returns confidence level and end value for any given expression. Based on this "confidence level", constant folding plugin replaces the expression with their end values altering our original code as follows.

How evaluate handles different cases

For code Math.min(10, 20), evaluate will return

{ confident: true, value: 10 }

For code a < b, evaluate will return

{ confident: true, value: true }.

But for user defined function like foo('bar') or browser defined console.log('hello'), evaluate will return

{ confident: false, value: undefined }.

In the above case "confident" value will be "false" even if function returns a constant value. For example for code foo(100), evaluate will return

{ confident: false, value: undefined }.

In the above case function foo will always return 100. Still Babel has low confidence level. Why? That's because Babel sees that it is a function and it bails out. It does not even look inside to try to figure things out.

Here is evaluate code in Babel. You should check it out.

How much optimization is possible?

How much help we will get from Babel for optimizing our code? Will it optimize everything?

The answer is unfortunately no.

As of now, Babel optimizes logical, binary, conditional expressions. It can also evaluate function calls on literals like "babel".length confidently if the literal is string or number.

For function calls, it supports only certain callees like String, Number and Math. So call to a user defined function, even if it's returning a fixed value, will not be optimized.

Experimental feature

This feature looks great. But it's available as experimental feature. If you use the plugin you will get following warning. unless you enable experimental flag.

$ babel --plugins constant-folding index.js --out-file bundle.js -w

[BABEL] index.js: THE TRANSFORMER constant-folding HAS BEEN MARKED AS EXPERIMENTAL AND IS WIP. USE AT YOUR OWN RISK. THIS WILL HIGHLY LIKELY BREAK YOUR CODE SO USE WITH **EXTREME** CAUTION. ENABLE THE `experimental` OPTION TO IGNORE THIS WARNING.

In order to get rid of warning you need to pass --experimental flag like this.

$ babel --plugins constant-folding index.js --out-file bundle.js -w
--experimental

Eliminating dead code

In above code example, we know that the result of if (a < b) is true based on values of a and b. Since the result is not going to change no matter what there is no need to have the if and else clauses.

That's dead code.

Can Babel help us eliminate dead code?

Yes with the help of minification.deadCodeElimination option.

babel --optional minification.deadCodeElimination index.js --out-file bundle.js -w

Which converts earlier code to:

"use strict";

console.log("a is less than b");

I will talk about how Babel can eliminate dead code in a later post.

These are the set of commands I used to achieve that.

Command : storeEval
Target  : var d = new Date();
          d.setTime(new Date( (d.getTime() + (d.getTimezoneOffset() * 60000))            + (3600000 * (-5) ) ));
          d.toLocaleTimeString();
Value   : timeEst

Command : echo
Target  : ${timeEst}
Value   :

storeEval command is used to store the value in the variable timeEst after evaluating the javascript code.

var d = new Date(); a new date object is created.

d.getTime() method returns the number of milliseconds between midnight of January 1, 1970 and the specified date (as is present in the variable "d").

d.getTimezoneOffset() method returns the time difference between UTC (Coordinated Universal Time) time and local time from the variable "d", in minutes. For example, If our time zone is GMT-5.50, -330 will be returned.

Since getTime() is in milliseconds and getTimezoneOffset() is in minutes; getTimezoneOffset() is multiplied with 60000 to make it into milliseconds.

The expression 3600000 * (- 5) is required to make the time from UTC to EST. The difference between UTC and EST is -5 hours. So, to make the hours to milliseconds we need to multiply with 3600000 (60 min x 60 sec x 1000 millisec).

d.setTime() method is used to set the time of variable "d" after evaluating the expression.

With the above, the variable "d" is set with the date and time of the EST time.

d.toLocaleTimeString() method returns the time portion of a Date object as a string, using locale conventions.

The time string obtained above is stored in the variable timeEst.

echo ${timeEst}, the time string is displayed in the console.

Using est time

Using est date

mixin using apply

m = Ember.Mixin.create({
  skill: function () {
    return "JavaScript & " + this._super();
  },
});
main = {
  skill: function () {
    return "Ruby";
  },
};
o = m.apply(main);
console.log(o.skill());

result: JavaScript & Ruby;

mixin in create and extend

Now lets see usage of mixin in create and extend. Since create and extend work similarly I am only going to discuss create scenario .

skillJavascript = Ember.Mixin.create({
  skill: function () {
    return "JavaScript ";
  },
});
main = {
  skill: function () {
    return "Ruby & " + this._super();
  },
};
p = Ember.Object.create(skillJavascript, main);
console.log(p.skill());

result: Ruby & JavaScript;

Notice that in the first case the mixin code was executed first. In the second case the mixin code was execute later.

Here is how it works

Here is mergeMixins code which accepts the mixins and the base class. In the first case the mixins list is just the mixin and the base class is the main class.

At run time all the mixin properties are looped through. In the first case the mixin m has a property called skill .

m.mixins[0].properties.skill

function () {
    return 'JavaScript & ' + this._super()
  }

Runtime detects that both mixin and the base class has a property called skill . Since base class has the first claim to the property a call is made to link the _super of the second function to the first function.

That works is done by wrap function.

So at the end of the execution the mixin code points to base code as _super.

It reveres itself in case of create

In the second case the mixin skillJavaScript and the main are the mixins to base class of Class. The mixin is the first in the looping order. So the mixin has the first claim to key skill since it was unclaimed by base class to begin with.

Next comes the main function and since the key is already taken the wrap function is used to map _super of main to point to the mixin .

Remember in Create and Extend it is the last one that executes first

Here is an example with two mixins.

skillHaskell = Ember.Mixin.create({
  skill: function () {
    return "Haskell";
  },
});
skillJavascript = Ember.Mixin.create({
  skill: function () {
    return "JavaScript & " + this._super();
  },
});
p = Ember.Object.create(skillHaskell, skillJavascript, {
  skill: function () {
    return "Ruby & " + this._super();
  },
});
console.log(p.skill());

result: Ruby & JavaScript & Haskell;

In this case the haskell mixin first claimed the key. So the javascript mixin's _super points to haskell and the main code's _super points to Javascript.

Embjers makes good use of mixin

emberjs has features like comparable, freezable, enumerable, sortable, observable. Take a look at this (Link is not available) to checkout their code.

It all starts with apply

Function bindAll internally uses bind . And bind internally uses apply. So it is important to understand what apply does.

var func = function beautiful() {
  alert(this + " is beautiful");
};
func();

If I execute above code then I get [object window] is beautiful. I am getting that message because when function is invoked then this is window, the default global object.

In order to change the value of this we can make use of method apply as given below.

var func = function beautiful() {
  alert(this + " is beautiful");
};
func.apply("Internet");

In the above case the alert message will be Internet is beautiful . Similarly following code will produce Beach is beautiful .

var func = function beautiful() {
  alert(this + " is beautiful");
};
func.apply("Beach"); //Beach is beautiful

In short, apply lets us control the value of this when the function is invoked.

Why bind is needed

In order to understand why bind method is needed first let's look at following example.

function Developer(skill) {
  this.skill = skill;
  this.says = function () {
    alert(this.skill + " rocks!");
  };
}
var john = new Developer("Ruby");
john.says(); //Ruby rocks!

Above example is pretty straight forward. john is an instance of Developer and when says function is invoked then we get the right alert message.

Notice that when we invoked says we invoked like this john.says(). If we just want to get hold of the function that is returned by says then we need to do john.says. So the above code could be broken down to following code.

function Developer(skill) {
  this.skill = skill;
  this.says = function () {
    alert(this.skill + " rocks!");
  };
}
var john = new Developer("Ruby");
var func = john.says;
func(); // undefined rocks!

Above code is similar to the code above it. All we have done is to store the function in a variable called func. If we invoke this function then we should get the alert message we expected. However if we run this code then the alert message will be undefined rocks!.

We are getting undefined rocks! because in this case func is being invoked in the global context. this is pointing to global object called window when the function is executed. And window does not have any attribute called skill . Hence the output of this.skill is undefined.

Earlier we saw that using apply we can fix the problem arising out of this. So lets try to use apply to fix it.

function Developer(skill) {
  this.skill = skill;
  this.says = function () {
    alert(this.skill + " rocks!");
  };
}
var john = new Developer("Ruby");
var func = john.says;
func.apply(john);

Above code fixes our problem. This time the alert message we got was Ruby rocks!. However there is an issue and it is a big one.

In JavaScript world functions are first class citizens. The reason why we create function is so that we can easily pass it around. In the above case we created a function called func. However along with the function func now we need to keep passing john around. That is not a good thing. Secondly the responsibility of rightly invoking this function has been shifted from the function creator to the function consumer. That's not a good API.

We should try to create functions which can easily be called by the consumers of the function. This is where bind comes in.

How bind solves the problem

First lets see how using bind solves the problem.

function Developer(skill) {
  this.skill = skill;
  this.says = function () {
    alert(this.skill + " rocks!");
  };
}
var john = new Developer("Ruby");
var func = _.bind(john.says, john);
func(); // Ruby rocks!

To solve the problem regarding this issue we need a function that is already mapped to john so that we do not need to keep carrying john around. That's precisely what bind does. It returns a new function and this new function has this bound to the value that we provide.

Here is a snippet of code from bind method

return function () {
  return func.apply(obj, args.concat(slice.call(arguments)));
};

As you can see bind internally uses apply to set this to the second parameter we passed while invoking bind.

Notice that bind does not change existing function. It returns a new function and that new function should be used.

How bindAll solves the problem

Instead of bind we can also use bindAll . Here is solution with bindAll.

function Developer(skill) {
  this.skill = skill;
  this.says = function () {
    alert(this.skill + " rocks!");
  };
}
var john = new Developer("Ruby");
_.bindAll(john, "says");
var func = john.says;
func(); //Ruby rocks!

Above code is similar to bind solution but there are some big differences.

The first big difference is that we do not have to worry about the returned value of bindAll . In case of bind we must use the returned function. In bindAll we do not have to worry about the returned value but it comes with a price. bindAll actually mutates the function. What does that mean.

See john object has an attribute called says which returns a function . bindAll goes and changes the attribute says so that when it returns a function, that function is already bound to john.

Here is a snippet of code from bindAll method.

function(f) { obj[f] = _.bind(obj[f], obj); }

Notice that bindAll internally calls bind and it overrides the existing attribute with the function returned by bind.

The other difference between bind and bindAll is that in bind first parameter is a function john.says and the second parameter is the value of this john. In bindAll first parameter is value of this john and the second parameter is not a function but the attribute name.

Things to watch out for

While developing a Backbone.js application someone had code like this

window.ProductView = Backbone.View.extend({
  initialize: function () {
    _.bind(this.render, this);
    this.model.bind("change", this.render);
  },
});

Above code will not work because the returned value of bind is not being used. The correct usage will be

window.ProductView = Backbone.View.extend({
  initialize: function () {
    this.model.bind("change", _.bind(this.render, this));
  },
});

Or you can use bindAll as given below.

window.ProductView = Backbone.View.extend({
  initialize: function () {
    _.bindAll(this, this.render);
    this.model.bind("change", this.render);
  },
});

Recommended videos

If you like this blog then most likely you will also like our videos series on "Understanding this in JavaScript" at Learn JavaScript .

He likes to declare the variable where they are used to be sure that the variable being used is declared with var otherwise that variable will become global variable. This fear of accidentally creating a global variables wants him to see variable declaration next to where it is being used.

Use the right tool

var payment;
payment = soldPrice + shippingCost;

In the above case user has declared payment variable in the middle so that he is sure that payment is declared. However if there is a typo as given below then he has accidentally created a global variable "payment".

var payment; //there is a typo
payment = soldPrice + shippingCost;

Having variable declaration next to where variable is being used is not a safe way of guaranteeing that variable is declared. Use the right tool and that would be jslint validation. I use MacVim and I use Javascript Lint. So every time I save a JavaScript file validation is done and I get warning if I am accidentally creating a global variable.

You can configure such that JSLint validation runs when you check your code into git or when you push to github. Or you can have a custom rake task. Many solutions are available choose the one that fits you. But do not rely on manual inspection.

Variable declaration are being moved to the top by the browser

Take a look at following code. One might expect that console.log will print "Neeraj" but the output will be "undefined" . That is because even though you have declaration variables next to where they are being used, browsers lift those declarations to the very top.

name = "Neeraj";
function lab() {
  console.log(name);
  var name = "John";
  console.log(name);
}
lab();

Browser converts above code into one shown below.

name = "Neeraj";
function lab() {
  var name = undefined;
  console.log(name);
  name = "John";
  console.log(name);
}
lab();

In order to avoid this kind of mistakes it is preferred to declared variables at the top like this.

name = "Neeraj";
function lab() {
  var name = "John";
  console.log(name);
  console.log(name);
}
lab();

Looking at the first set of code a person might think that

Also remember that scope of variable in JavaScript at the function level.

Implications on how functions are declared

There are two ways of declaring a function.

var myfunc = function () {};
function myfunc2() {}

In the first case only the variable declaration myfunc is getting hoisted up. The definition of myfunc is NOT getting hoisted. In the second case both variable declaration and function definition is getting hoisted up. For more information on this refer to my previous blog on the same topic.

Creating an Object

Simplest solution is creating an instance of the object.

var Logger = function (path) {
  this.path = path;
};

l1 = new Logger("/home");
console.log(l1);

l2 = new Logger("/dev");
console.log(l2);

console.log(l1 === l2);

Above solution works. However l2 is a new instance of Logger .

Singleton solution using a global variable

window.global_logger = null;
var Logger = function (path) {
  if (global_logger) {
    console.log("global logger already present");
  } else {
    this.path = path;
    window.global_logger = this;
  }
  return window.global_logger;
};

l1 = new Logger("/home");
console.log(l1);

l2 = new Logger("/dev");
console.log(l2);

console.log(l1 === l2);

Above solution works. However this solution relies on creating a global variable. To the extent possible it is best to avoid polluting global namespace.

Single solution without polluting global namespace

var Logger = (function () {
  var _instance;

  return function (path) {
    if (_instance) {
      console.log("an instance is already present");
    } else {
      this.path = path;
      _instance = this;
    }

    return _instance;
  };
})(); //note that it is self invoking function

var l1 = new Logger("/root");
console.log(l1);

var l2 = new Logger("/dev");
console.log(l2);

console.log(l1 === l2);

This solution does not pollute global namespace.

Defining regular expressions

In JavaScript regular expression can be defined two ways.

var regex = /hello/gi; // i is for ignore case. g is for global.
var regex = new RegExp("hello", "ig");

If I am defining regular expression using RegExp then I need to add escape character in certain cases.

var regex = /hello_\w*/gi;
var regex = new RegExp("hello_\\w*", "ig"); //notice the extra backslash before \w

When I am defining regular expression using RegExp then \w needs to be escaped otherwise it would be taken literally.

test method

test method is to check if a match is found or not. This method returns true or false.

var regex = /hello/gi;
var text = "hello_you";
var bool = regex.test(text);

exec method

exec method finds if a match is found or not. It returns an array if a match is found. Otherwise it returns null.

var regex = /hello_\w*/gi;
var text = "hello_you";
var matches = regex.exec(text);
console.log(matches); //=> hello_you

match method

match method acts exactly like exec method if no g parameter is passed. When global flag is turned on the match returns an Array containing all the matches.

Note that in exec the syntax was regex.exec(text) while in match method the syntax is text.match(regex) .

var regex = /hello_\w*/i;
var text = "hello_you and hello_me";
var matches = text.match(regex);
console.log(matches); //=> ['hello_you']

Now with global flag turned on.

var regex = /hello_\w*/gi;
var text = "hello_you and hello_me";
var matches = text.match(regex);
console.log(matches); //=> ['hello_you', 'hello_me']

Getting multiple matches

Once again both exec and match method without g option do not get all the matching values from a string. If you want all the matching values then you need to iterate through the text. Here is an example.

Get both the bug numbers in the following case.

var matches = [];
var regex = /#(\d+)/gi;
var text = "I fixed bugs #1234 and #5678";
while ((match = regex.exec(text))) {
  matches.push(match[1]);
}
console.log(matches); // ['1234', '5678']

Note that in the above case global flag g. Without that above code will run forever.

var matches = [];
var regex = /#(\d+)/gi;
var text = "I fixed bugs #1234 and #5678";
matches = text.match(regex);
console.log(matches);

In the above case match is used instead of regex . However since match with global flag option brings all the matches there was no need to iterate in a loop.

match attributes

When a match is made then an array is returned. That array has two methods.

• index: This tells where in the string match was done
• input: the original string

var regex = /#(\d+)/i;
var text = "I fixed bugs #1234 and #5678";
var match = text.match(regex);
console.log(match.index); //13
console.log(match.input); //I fixed bugs #1234 and #5678

replace

replace method takes both regexp and string as argument.

var text = "I fixed bugs #1234 and #5678";
var output = text.replace("bugs", "defects");
console.log(output); //I fixed defects #1234 and #5678

Example of using a function to replace text.

var text = "I fixed bugs #1234 and #5678";
var output = text.replace(/\d+/g, function (match) {
  return match * 2;
});
console.log(output); //I fixed bugs #2468 and #11356

Another case.

// requirement is to change all like within <b> </b> to love.
var text = " I like JavaScript. <b> I like JavaScript</b> ";
var output = text.replace(/<b>.*?<\/b>/g, function (match) {
  return match.replace(/like/g, "love");
});
console.log(output); //I like JavaScript. <b> I love JavaScript</b>

Example of using special variables.

$& -	the matched substring.
$` -  the portion of the string that precedes the matched substring.
$' -  the portion of the string that follows the matched substring.
$n -  $0, $1, $2 etc where number means the captured group.

var regex = /(\w+)\s(\w+)/;
var text = "John Smith";
var output = text.replace(regex, "$2, $1");
console.log(output); //Smith, John

var regex = /JavaScript/;
var text = "I think JavaScript is awesome";
var output = text.replace(regex, "before:$` after:$' full:$&");
console.log(output); //I think before:I think after: is awesome full:JavaScript is awesome

Replace method also accepts captured groups as parameters in the function. Here is an example;

var regex = /#(\d*)(.*)@(\w*)/;
var text = "I fixed bug #1234 and twitted to @javascript";
text.replace(regex, function (_, a, b, c) {
  log(_); //#1234 and twitted to @javascript
  log(a); //1234
  log(b); //  and twitted to
  log(c); // javascript
});

As you can see the very first argument to function is the fully matched text. Other captured groups are subsequent arguments. This strategy can be applied recursively.

var bugs = [];
var regex = /#(\d+)/g;
var text = "I fixed bugs #1234 and #5678";
text.replace(regex, function (_, f) {
  bugs.push(f);
});
log(bugs); //["1234", "5678"]

Split method

split method can take both string or a regular expression.

An example of split using a string.

var text = "Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec";
var output = text.split(",");
log(output); // ["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"]

An example of split using regular expression.

var text = "Harry Trump ;Fred Barney; Helen Rigby ; Bill Abel ;Chris Hand ";
var regex = /\s*;\s*/;
var output = text.split(regex);
log(output); // ["Harry Trump", "Fred Barney", "Helen Rigby", "Bill Abel", "Chris Hand "]

Non capturing Group

The requirement given to me states that I should strictly look for word java, ruby or rails within word boundary. This can be done like this.

var text = "java";
var regex = /\bjava\b|\bruby\b|\brails\b/;
text.match(regex);

Above code works. However notice the code duplication. This can be refactored to the one given below.

var text = "rails";
var regex = /\b(java|ruby|rails)\b/;
text.match(regex);

Above code works and there is no code duplication. However in this case I am asking regular expression engine to create a captured group which I'll not be using. Regex engines need to do extra work to keep track of captured groups. It would be nice if I could say to regex engine do not capture this into a group because I will not be using it.

?: is a special symbol that tells regex engine to create non capturing group. Above code can be refactored into the one given below.

var text = "rails";
var regex = /\b(?:java|ruby|rails)\b/;
text.match(regex);

text = "#container a.filter(.top).filter(.bottom).filter(.middle)";
matches = text.match(/^[^.]*|\.[^.]*(?=\))/g);
log(matches);

When I looked at source code for the first time, it looked intimidating. In order to get started with nodejs, I have developed a small portion of the node-chat application in 13 incremental steps.

The first step is as simple as 15 lines of code .

If you want to follow along then go through README and you can get a feel of nodejs very quickly. How to checkout each step and other information is mentioned in README.

Enjoy nodejs.

var foo = function () {};
function foo() {}

Thanks to Ben today I learned that there is a difference .

When a var is used to declare a function then only the variable declaration gets hoisted up

function test() {
  foo();
  var foo = function () {
    console.log("foo");
  };
}
test();

Above code is same as one given below.

function test() {
  var foo;
  foo();
  foo = function () {
    console.log("foo");
  };
}
test();

When a function variable is declared without var then both variable declaration and body gets hoisted up

function test() {
  foo();
  function foo() {
    console.log("foo");
  }
}
test();

Above code is same as one given below.

function test() {
  var foo;
  foo = function () {};
  console.log(foo());
}
test();

Conclusion

Now it will be clear why foo() does not work in the following case while bar() does work.

function test() {
  foo(); // TypeError "foo is not a function"
  bar(); // "this will run!"
  var foo = function () {
    // function expression assigned to local variable 'foo'
    alert("this won't run!");
  };
  function bar() {
    // function declaration, given the name 'bar'
    alert("this will run!");
  }
}
test();

var num1 = 5,
  num2 = 10,
  result = num1++ + num2;

However some of the questions helped me learn a few things.

Questions from quiz

Recently there was a quiz out.

This was question #5 in the original blog. I have modified the quiz a little bit to suit my needs.

var x = 10;
var foo = {
  x: 20,
  bar: function () {
    var x = 30;
    return this.x;
  },
};

// 1
console.log(foo.bar());

// 2
console.log(foo.bar());

// 3
console.log(foo.bar.call());

I got the first two answers wrong. In JavaScript a variable and a property are two different things. When this.xyx is invoked then JavaScript engine is looking for property called xyz.

var bar = function () {
  var x = 30;
  return this.x;
};
console.log(bar()); //=> undefined

In the above case output is undefined. This is because this refers to a property named x and since no such property was found undefined is the answer.

var foo = {
  x: 20,
  bar: function () {
    return x;
  },
};
console.log(foo.bar());

Above code causes ReferenceError because x is not defined. Same theory applies here. In this case x is a variable and since no such variable was found code failed.

Coming back to the third part of the original question. This one uses call.

console.log(foo.bar.call());

First argument of call or apply method determines what this would be inside the function. If no argument is passed then JavaScript engine assumes that this would be global scope which translates to this being window. Hence the answer is 10 in this case.

Questions from another quiz

There was another quiz .

In the original blog this is question #2.

var x = 5,
  o = {
    x: 10,
    doIt: function doIt() {
      var x = 20;
      setTimeout(function () {
        alert(this.x);
      }, 10);
    },
  };
o.doIt();

The key thing to remember here is that All functions passed into setTimeout() are executed in the global scope .

In the original blog this is question #5.

var o = {
    x: 8,

    valueOf: function () {
      return this.x + 2;
    },
    toString: function () {
      return this.x.toString();
    },
  },
  result = o < "9";

alert(o);

The thing to remember here is that when comparison is done then valueOf method is called on the object.

Questions from quiz

This is question #1 in the original blog.

if (!("a" in window)) {
  var a = 1;
}
alert(a);

I knew that all the variable declarations are hoisted up but somehow failed to apply that logic here. Please see the original blog for a detailed answer.

This is question #5 in the original blog.

function a() {
  alert(this);
}
a.call(null);

I knew that if nothing is passed to call method then this becomes global but did not know that if null is passed then also this becomes global.

Creating standard jQuery plugin

Given below is code that does exactly what Alex's code does.

$(function () {
  $.fn.speaker = function (options) {
    if (this.length) {
      return this.each(function () {
        var defaultOptions = {
          name: "No name",
        };
        options = $.extend({}, defaultOptions, options);

        var $this = $(this);

        $this.html("<p>" + options.name + "</p>");

        var fn = {};
        fn.speak = function (msg) {
          $this.append("<p>" + msg + "</p>");
        };

        $.data(this, "speaker", fn);
      });
    }
  };
});

For smaller plugins this code is not too bad. However if the plugin is huge then it presents one big problem. The code for business problem and the code that deals with jQuery is all mixed in. What it means is that if tomorrow same functionality needs to be implemented for Prototype framework then it is not clear what part of code deals with framework and what part deals with business logic.

Separating business logic and framework code

Given below is code that separates business logic and framework code.

var Speaker = function (opts, elem) {
  this._build = function () {
    this.$elem.html("<h1>" + options.name + "</h1>");
  };

  this.speak = function (msg) {
    this.$elem.append("<p>" + msg + "</p>");
  };

  var defaultOptions = {
    name: "No name",
  };

  var options = $.extend({}, defaultOptions, this.opts);

  this.$elem = $(elem);

  this._build();
};

$(function () {
  $.fn.speaker = function (options) {
    if (this.length) {
      return this.each(function () {
        var mySpeaker = new Speaker(options, this);
        $.data(this, "speaker", mySpeaker);
      });
    }
  };
});

This code is an improvement over first iteration. However the whole business logic is captured inside a function. This code can be further improved by embracing object literal style of coding.

Final Improvement

Third and final iteration of the code is the code presented by Alex.

var Speaker = {
	init: function(options, elem) {
		this.options = $.extend({},
		this.options, options);

		this.elem = elem;
		this.$elem = $(elem);

		this._build();
	},
	options: {
		name: "No name"
	},
	_build: function() {
		this.$elem.html('<h1>' + this.options.name + '</h1>');
	},
	speak: function(msg) {
		this.$elem.append('<p>' + msg + '</p>');
	}
};

// Make sure Object.create is available in the browser (for our prototypal inheritance)
if (typeof Object.create !== 'function') {
	Object.create = function(o) {
		function F() {}
		F.prototype = o;
		return new F();
	};
}

$(function() {
	$.fn.speaker = function(options) {
		if (this.length) {
			return this.each(function() {
				var mySpeaker = Object.create(Speaker);
				mySpeaker.init(options, this);
				$.data(this, 'speaker', mySpeaker);
			});
		}
	};

Notice the Object.create pattern Alex used. The business logic code was converted from a function to a JavaScript object. However the problem is that you can't create a new on that object. And you need to create new object so that you could dole out new objects to each element. Object.create pattern comes to rescue.

This pattern takes a standard Object and returns an instance of a function. This function has the input object set as prototype. So you get a brand new object for each element and you get to have all your business logic in object literal way and not in a function. If you want to know more about prototypal inheritance then you can read more about it in previous blog .

Object.create is now part of ECMAScript 5 .

In the beginning there was duplication

function Person(dob) {
  this.dob = dob;
  this.votingAge = 21;
}

function Developer(dob, skills) {
  this.dob = dob;
  this.skills = skills || "";
  this.votingAge = 21;
}

// create a Person instance
var person = new Person("02/02/1970");

//create a Developer instance
var developer = new Developer("02/02/1970", "JavaScript");

As you can see both Person and Developer objects have votingAge property. This is code duplication. This is an ideal case where inheritance can be used.

prototype method

Whenever you create a function, that function instantly gets a property called prototype. The initial value of this prototype property is empty JavaScript object {} .

var fn = function () {};
fn.prototype; //=> {}

JavaScript engine while looking up for a method in a function first searches for method in the function itself. Then the engine looks for that method in that functions' prototype object.

Since prototype itself is a JavaScript object, more methods could be added to this JavaScript object.

var fn = function () {};
fn.prototype.author_name = "John";
var f = new fn();
f.author_name; //=> John

Refactoring code to make use of prototype method

Currently Person function is defined like this.

function Person(dob) {
  this.dob = dob;
  this.votingAge = 21;
}

Problem with above code is that every time a new instance of Person is created, two new properties are created and they take up memory. If a million objects are created then all instances will have a property called votingAge even though the value of votingAge is going to be same. All the million person instances can refer to same votingAge method if that method is define in prototype. This will save a lot of memory.

function Person(dob) {
  this.dob = dob;
}
Person.prototype.votingAge = 21;

The modified solutions will save memory if a lot of objects are created. However notice that now it will a bit longer for JavaScript engine to look for votingAge method. Previously JavaScript engine would have looked for property named votingAge inside the person object and would have found it. Now the engine will not find votingAge property inside the person object. Then engine will look for person.prototype and will search for votingAge property there. It means, in the modified code engine will find votingAge method in the second hop instead of first hop.

Bringing inheritance using prototype property

Currently Person is defined like this.

function Person(dob) {
  this.dob = dob;
}
Person.prototype.votingAge = 21;

If Developer Object wants to extend Person then all that needs to be done is this.

function Developer(dob, skills) {
  this.skills = skills || "";
  this.dob = dob;
}
Developer.prototype = new Person();

Now Developer instance will have access to votingAge method. This is much better. Now there is no code duplication between Developer and Person.

However notice that looking for votingAge method from a Developer instance will take an extra hop.

• JavaScript engine will first look for votingAge property in the Developer instance object.
• Next engine will look for votingAge property in its prototype property of Developer instance which is an instance of Person. votingAge method is not declared in the Person instance.
• Next engine will look for votingAge property in the prototype of Person instance and this method would be found.

Since only the methods that are common to both Developer and Person are present in the Person.prototype there is nothing to be gained by looking for methods in the Person instance. Next implementation will be removing the middle man.

Remove the middle man

Here is the revised implementation of Developer function.

function Developer(dob, skills) {
  this.skills = skills || "";
  this.dob = dob;
}
Developer.prototype = Person.prototype;

In the above case Developer.prototype directly refers to Person.prototype. This will reduce the number of hops needed to get to method votingAge by one compared to previous case.

However there is a problem. If Developer changes the common property then instances of person will see the change. Here is an example.

Developer.prototype.votingAge = 18;
var developer = new Developer("02/02/1970", "JavaScript");
developer.votingAge; //=> 18

var person = new Person();
person.votingAge; //=> 18. Notice that votingAge for Person has changed from 21 to 18

In order to solve this problem Developer.prototype should point to an empty object. And that empty object should refer to Person.prototype .

Solving the problem by adding an empty object

Here is revised implementation for Developer object.

function Developer(dob, skills) {
  this.dob = dob;
  this.skills = skills;
}
var F = function () {};
F.prototype = Person.prototype;
Developer.prototype = new F();

Let's test this code.

Developer.prototype.votingAge = 18;
var developer = new Developer("02/02/1970", "JavaScript");
developer.votingAge; //=> 18

var person = new Person();
person.votingAge; //=> 21

As you can see with the introduction of empty object, Developer instance have votingAge of 18 while Person instance have votingAge of 21.

Accessing super

If child wants to access super object then that should be allowed. That can be accomplished like this.

function Person(dob) {
  this.dob = dob;
}
Person.prototype.votingAge = 21;

function Developer(dob, skills) {
  this.dob = dob;
  this.skills = skills;
}
var F = function () {};
F.prototype = Person.prototype;
Developer.prototype = new F();
Developer.prototype.__super = Person.prototype;
Developer.prototype.votingAge = 18;

Capturing it as a pattern

The whole thing can be captured in a helper method that would make it simple to create inheritance.

var extend = function (parent, child) {
  var F = function () {};
  F.prototype = parent.prototype;
  child.prototype = new F();
  child.prototype.__super = parent.prototype;
};

Pure prototypal inheritance

A simpler form of pure prototypal inheritance can be structured like this.

if (typeof Object.create !== "function") {
  Object.create = function (o) {
    function F() {}
    F.prototype = o;
    return new F();
  };
}

Before adding the create method to object, I checked if this method already exists or not. That is important because Object.create is part of ECMAScript 5 and slowly more and more browsers will start adding that method natively to JavaScript.

You can see that Object.create takes only one parameter. This method does not necessarily create a parent child relationship . But it can be a very good tool in converting an object literal to a function.

Question 1

What's the output.

x = 90;
function f() {
  console.log(x);
  var x = 100;
}
f();

Answer 1

The result is undefined . In JavaScript a variable exists in the scope of a function and that variable can be defined anywhere in the function. To find out more about lexical scope read here and here .

Question 2

Go to prototype homepage open firebug and execute following code.

var a = ["a", "b", "c"];
var result = "\n";
for (i in a) {
  result += "index: " + i + " value:" + a[i] + "\n";
}

Now go to jQuery homepage and execute the same code. Notice the difference in output. Why the difference?

Answer 2

Prototype adds additional methods to Array using Array.prototype . Those methods show up when you iterate through them. If you want to ignore methods added through Array.prototype then use this code.

var a = ["a", "b", "c"];
var result = "\n";
for (i in a) {
  if (a.hasOwnProperty(i)) result += "index: " + i + " value:" + a[i] + "\n";
}

Question 3

In order to find if an element with id foo is present, one can do

if ($("#foo").length > 0) console.log("id foo is present");

How can you make the conditional statement shorter.

Answer 3

In JavaScript following items evaluate to false in a conditional statement: undefined, null, false, empty string, NaN, 0

if ($("#foo")) console.log("id foo is present");

Question 4

What is the output in this case. Notice that function bar is defined after the return statement.

function foo() {
  console.log(z);
  console.log(bar());
  return true;

  function bar() {
    return "this is bar";
  }

  var z = "zzz";
}

foo();

Answer 4

Output is

undefined
this is bar
true

Question 5

What's output in this case.

function logit(n) {
  console.log(n);
}

for (i = 1; i < 5; i++) {
  setInterval(function () {
    logit(i);
  }, 2000);
}

Answer 5

The result would be output 5 5 5 5 and all the four output will appear together in one shot. Then after 2 seconds another set of similar data would appear. This would continue forever.

Question is why do I see the output in one single shot and why do I see value 5 for all four cases.

Browsers execute JavaScript in a single thread. While that thread is busy executing 'for loop' the thread makes note of additional instructions like setInterval. Since the thread is already running 'for loop', the same thread can't run setInterval. So the thread finishes the 'for loop' and then looks up additional tasks to be performed. It find setInterval task to be waiting. It executes the function. While it is executing the function ,by virtue of closure, the value of i is 5. Hence you see 5 5 5 5 and you see all that in one single shot.

Correct implementation would be

function logit(n) {
  console.log(n);
}

var counter = 0;
var timer = setInterval(function () {
  logit(counter);
  counter++;
  if (counter == 5) {
    clearTimeout(timer);
  }
}, 2000);

Above code would print 0 1 2 3 4 at an interval of 2 seconds.

Question 6

What's the output in this case.

flight = { status: "arrived" };
console.log(typeof flight.status);
console.log(typeof flight.toString);
console.log(flight.hasOwnProperty("status"));
console.log(flight.hasOwnProperty("toString"));

Answer 6

string
function
true
false

Question 7

What's output in this case.

function Person(name) {
  this.name = name;
}
Person.prototype.welcome = function () {
  return "welcome " + this.name;
};

p = new Person("John");

console.log(p.welcome.call(p));

o = { name: "Mary" };

console.log(Person.prototype.welcome.call(o));

Answer 7

welcome John
welcome Mary

Question 8

JavaScript has Math library which can be used like this

Math.max(6, 7, 8); // result is 8

If I provide an array with certain values then how would you find the max value for that array.

a = [1, 2, 3];

Answer 8

This answer builds up on the answer provided in #7 .

You can try this but it will fail.

Math.max(a); //output is NaN

You can try this but it will fail too.

Math.max.call(Math, a); // output is NaN

This will work

Math.max.apply(Math, a); //output is 3

apply method works because it accepts an array as the argument. call method passes the individual params to the called method directly and hence it does not work. You can read more about JavaScript apply and call methods here .

Here is a simple implementation of the case where you want to verify input code.

function verifycode(code) {
  console.log(code.length);
  return code.length == 4 ? true : false;
}

function info(code) {
  if (verifycode(code)) {
    console.log(code + " is valid");
  } else {
    console.log(code + " is wrong");
  }
}

info("abcd");
info("rty");

In the above implementation anyone can call the method verifycode. Not good. Here is one way to fix this problem.

var Lab = Lab || {};
Lab = (function () {
  var verifycode = function (code) {
    console.log(code.length);
    return code.length == 4 ? true : false;
  };
  return {
    info: function (code) {
      if (verifycode(code)) {
        console.log(code + " is valid");
      } else {
        console.log(code + " is wrong");
      }
    },
  };
})();

Lab.info("abcd");
Lab.info("rty");
Lab.verifycode("abcd"); //verifycode is private

Another way to solve the same problem would be to create a constructor function. Here is an implementation.

function Lab(code) {
  this.code = code;
  var verifycode = function () {
    return code.length == 4 ? true : false;
  };
  this.info = function () {
    if (verifycode()) {
      console.log(code + " is valid");
    } else {
      console.log(code + " is wrong");
    }
  };
}
new Lab("abcd").info();

Here is another way to solve the same problem. In this case I have moved all the public methods to prototype.

function Lab(code) {
  this.code = code;
  this.verifycode = function () {
    l = code.length;
    return l == 4 ? true : false;
  };
}

Lab.prototype.info = function () {
  if (this.verifycode()) {
    console.log(this.code + " is valid");
  } else {
    console.log(this.code + " is wrong");
  }
};

new Lab("abcd").info();

var select_col1 = $("<select></select>")
  .addClass("ram_drop_down")
  .addClass("ram_drop_down_col1")
  .attr("name", "adv_search[" + random_num + "_row][col1]")
  .attr("id", random_num + "_ram_drop_down_col1");

In such cases JavaScriptLint had warnings for me.

unexpected end of line. It is ambiguous whether these lines are part of the same statement.

JavaScriptLint wants me to put the dot at the end of the line and not at the beginning of the line. Well, I like having dots at the beginning of lines and I wanted to turn off such warning.

JavaScriptLint comes with a default config file. I copied the config file to a personal directory and disabled the warning.

before: +ambiguous_newline
after: -ambiguous_newline

Also I had to comment out +process jsl-test.js at the very bottom. Now tell your plugin to use this configuration file rather than the default one. Add the following line to your vimrc file.

let jslint_command_options = '-conf "/Users/neeraj/vim/plugin/jslint/jsl.custom.conf" -nofilelisting -nocontext -nosummary -nologo -process'

This is the vim settings I use and it has been configured to take care of it. Just go to vimrc.local and change the path to your config file. Also don't forget to remove " at the beginning of the line to uncomment it.

What problem JSONP solves?

Browsers do not allow cross-domain Ajax requests. For example if you try to make Ajax request to http://www.eventsinindia.com/events/14633.js to get event data you will get following error.

Access to restricted URL denied.

In order to get around this security problem you can do any number of things including sending the Ajax request to your server which will get the JSON data from the eventsinindia.com API. Or use iframe. Both of these solutions are implemented and discussed in this article .

However in some cases JSONP solves this problem much more elegantly.

Before we discuss JSONP some basics ?

Before looking at JSONP let's cover some basics. When a html page includes a javascript file then the html code looks something like this.

<script src="http://neeraj.name/javascripts/color.js" type="text/javascript"></script>

There are two things to notice here. First is that the source of the javascript file could be cross-domain. It means your html page can point the source of your javascript file to http://neeraj.name/javascripts/cache/all.js and all.js will be loaded by the browser. This feature which allows cross-domain loading of javascript file is the basis of JSONP.

The second thing to notice is that the javascript written in color.js is immediately evaluated after the source file has been loaded. For example the content of color.js could be this.

alert("hello");

When the html page is loaded you will get an alert.

Let's recap: In the above section I showed you how you can point the source of your javascript file to a domain that is not yours (cross-domain) and the code loaded from the domain is immediately evaluated.

What is JSONP?

From the above section it is clear that if by some means we could dynamically create a script node and point the source of that node to cross-domain and if the remote site returns a javascript function then that function will be evaluated.

However in the world of JSON we only get JSON data from the remote server. If we want to stick the returned JSON data on our page then that data needs be used by a javascript function. And that's where JSONP comes in handy.

Let's take an example. If you make a call to http://www.eventsinindia.com/events/14633.js you will get JSON data back.

{"name": "Craft Classes" , "start_date": "2009-05-01" , ....}

However what you really want is to do is to stick this data on your html page by invoking a javascript function like this

AddThisDataToPage({"name": "Craft Classes" , "start_date": "2009-05-01" , ....});

What needs to be done is while making a call to http://www.eventsinindia.com/events/14633.js pass a parameter called callback . So in this case the full url would look something like this

http://www.eventsinindia.com/events/14633.js?callback=AddThisDataToPage

Remember callback is a special word here. By using callback we are telling API to wrap the response JSON data with a call to function named AddThisDataToPage.

Click on following two links to see the difference. The first link is returning pure JSON data while the second link will return a javascript function.

http://www.eventsinindia.com/events/14633.js

http://www.eventsinindia.com/events/14633.js?callback=AddThisDataToPage

Using JSONP with jQuery

jQuery makes it easy to use JSONP. Look for documentation on how to use JSONP with jquery here .

Callback is not the name everyone uses

Most of the people use callback as the key word to identify client is asking for JSONP data. However some people use a different keyword. For example flickr uses the keyword jsoncallback

This returns JSON data

http://api.flickr.com/services/feeds/photos_public.gne?tags=cat&tagmode=any&format=json

In this case callback is being passed but flickr ignores it.

http://api.flickr.com/services/feeds/photos_public.gne?tags=cat&tagmode=any&format=json&callback=show

In this case callback is being passed but the name is jsoncallback.

http://api.flickr.com/services/feeds/photos_public.gne?tags=cat&tagmode=any&format=json&jsoncallback=show

Providing support for JSONP

All the APIs should provide support for JSONP. Enabling JSONP support is easy if you are using Rails 2.3 or any Rack compliant framework. In Rails 2.3 all you need to do is stick this file in lib as jsonp.rb (Link is not available) and then add one line to the environment.rb .

#environment.rb
Rails::Initializer.run do |config|
  .....
  config.middleware.use 'Jsonp'
end

That's it. Now you are providing support of JSONP with the keyword being callback.

Security

Since the data from external source is read and then that data is evaluated on run time by Javascript, there is potential for security breach. So be careful when you are using JSONP. Only load data from a trusted source.

Example 1: Getting digit name

The goal is to read from an array and display the result. The first implementation is to put everything in Global namespace.

var names = ["zero", "one", "two", "three", "four", "five"];

var digit_name = function (n) {
  return names[n];
};

alert(digit_name(3)); // 'three'

Above solution works. However creating a global variable names is not a good thing. You should create as less global variables as possible.

Moving to a function

Next step is to move the code to a function. In this case we will not have any global variable.

var digit_name = function (n) {
  var names = ["zero", "one", "two", "three", "four", "five"];
  return names[n];
};
alert(digit_name(3));

The above solution is very slow. Every single time the function is called the whole array is loaded. This solution works and most of the developers will settle with this one. However Closure can provide a better solution.

Better solution with Closure

var digit_name = (function () {
  var names = ["zero", "one", "two", "three", "four", "five"];

  return function (n) {
    return names[n];
  };
})();
alert(digit_name(3));

Note that after declaring, the function is also getting invoked. This is a case of self invoking function. You can find out more about self invoking function here .

Example 2: Getters and Setters

Developers deal with getters and setters all the time. However creating a good getter and setter could be a little tricky. Here is one implementation

function Field(val) {
  var value = val;

  this.getValue = function () {
    return value;
  };

  this.setValue = function (val) {
    value = val;
  };
}

var field = new Field("test");
field.value;
// => undefined
field.setValue("test2");
field.getValue();
// => "test2"

Above solution works and it's nicely done.

Let's look at another implementation.

var getValue, setValue;
(function () {
  var secret = 0;
  getValue = function () {
    return secret;
  };
  setValue = function (v) {
    secret = v;
  };
})();

setValue("foo");
getValue(); // foo

Example 3: Building an iterator using Javascript

function custome_iterator(x) {
  var i = 0;
  return function () {
    return x[i++];
  };
}

var next = setup(["one", "two", "three", "four"]);

next();
next();
next();

This is a simple case of serially iterating through the items provided but the logic of deciding next element can be complex and it can be private.

Closure is a big topic and a lot of people have written a lot about it. Just search for Closure and you will get tons of links. I refer to this article time to time to see what pattern to use to make best usage of Javascript Closure.

This article was inspired by this book, this video and this article .