I didn't.

I started out as a backend Java engineer before transitioning to full-stack as my role with my company at the time grew. Today, I am heavily front-end leaning. Actually, I work almost exclusively on the front-end.

During my transition to full-stack I was introduced to the npm package manager, but only what I needed to know at the time - npm install, npm uninstall, npm update -- heck, even installing specific versions! Year in and year out, that was all I really needed.

What Changed?

At work, we were transitioning to React single-page applications. Initially, we only needed one. Then, we were on our third and we planned to create more. Our process for starting a new one was to copy an existing SPA and then strip out the app-specific code to get back to a base setup, then start building.

Not ideal.

In my free time, I set out to create a base project repo that we could clone for our new SPAs. Creating the base project was easy enough, but why stop there? I decided to take it a step further and create a custom CLI for generating base projects.

Now, I had to make this CLI available to engineers at the company. But how? I couldn't publish it to the npm registry as the base project it used contained proprietary code. So, now what?

npm install to the rescue

A wise colleague of mine mentioned I could just npm install from the private CLI repo! After learning this, I finally dug into the documentation, specifically for npm install. From there we see:

npm install (with no args, in package dir)
npm install [<@scope>/]<name>
npm install [<@scope>/]<name>@<tag>
npm install [<@scope>/]<name>@<version>
npm install [<@scope>/]<name>@<version range>
npm install <git-host>:<git-user>/<repo-name>
npm install <git repo url>
npm install <tarball file>
npm install <tarball url>
npm install <folder>

alias: npm i
common options: [-P|--save-prod|-D|--save-dev|-O|--save-optional] [-E|--save-exact] [-B|--save-bundle] [--no-save] [--dry-run]

As you can see, there are plenty of ways to use npm install. I'd like to specifically point out:

npm install <git repo url></git>

Just beautiful.

Now, for an engineer at the company to install the CLI I created, they only needed to run:

npm install -g <private CLI git repo url>

or

npx <private CLI git repo url>

After that, they were free to use the CLI from any directory. Easy!

What About Yarn?

This can also be done using Yarn via yarn add.

From the Yarn docs, we see:

yarn add <git remote url>

So, similarly, for an engineer to install my CLI via yarn, they need to run:

yarn global add <private CLI git repo url>

And that's it!

It was interesting to learn that little bit of the npm CLI. Poking around the documentation has shown me another thing or two. If like me, you didn't know about some of these extra npm install powers, I hope you found this interesting and potentially useful.

I like to consider myself pretty comfortable with HOCs. I've written quite a few of them in the years I've been using React. However, I came across an interesting error recently.

The Issue

Consider a HOC that, among other things, accesses the wrapped component via a ref. The HOC works without issue... until it's used to wrap a stateless functional component. Then, the following error is logged in the console:

Stateless function components cannot be given refs. Attempts to access this ref will fail.

So, a component might need most of the functionality of a HOC, just not the ref related code, and it can't use it!

You might be thinking, "Simple fix. I'd just make the component I'm wrapping a class-based component." Yes, that's one way. But how about a way where you can maintain your functional component? There had to be another solution.

The Solution

The solution lies in having the HOC be able to recognize a difference between a class-based component and a stateless functional component. In this case, it's the fact that class-based components extend React's Component class. Class-based components need to have a render method, so the existence of that method can determine whether or not a component is stateful. Once that is known, the wrapped component can be conditionally given a ref. See the code below for a stripped-down example of a HOC like this:

import React, { Component } from 'react';

export default EnhancedComponent => {
  return class SomeHOC extends Component {
    constructor() {
      super();

      // check the prototype of the wrapped component's prototype for render
      // if render is not undefined, then the component is stateful, and can have a ref
      this._isStateful = (EnhancedComponent.prototype.render !== undefined);
    }

    /* Other HOC code would go here */

    render() {
      const allProps = {
        // spread all passed in props
        // you'd also add any other props to pass to wrapped components here
        ...this.props
      };

      // if the component is stateful, give it a ref.  Yay!
      if (this._isStateful) {
        allProps.ref = node => { this._wrappedInstance = node; };
      }

      return (
        <EnhancedComponent
          {...allProps}
        />
      );
    }
  };
};

And there you have it! I know this might seem like a pretty specialized case, and it is. However, if you have a HOC that sometimes needs access to a ref while also being able to wrap stateless functional components, then this should work for you.