DEV Community: Amber Wilkie

How to set up a brand new Macbook, for programmers

Amber Wilkie — Tue, 06 Aug 2019 00:00:00 +0000

I started a new job on Monday (it's going awesome, thanks for asking) and that means a brand new, blank-slate Macbook Pro. Fortunately, I still have my old work computer (my last job maybe wasn't so wonderful, as I had to bring my own every day...). But next time, I'll probably have to turn my new work computer in, so I wanted to create a record of my setup. Maybe it's helpful for others too! By the way, almost all of these programs are F-R-E-E.

The Terminal

It's absolutely essential to get your terminal set up so you can work efficiently. If you are running the default terminal with no adjustments, these tips could save you a lot of time and frustration.

iTerm2

Go on and download iTerm2 and then be very pleased with all the features. My favorites are:

Scroll (arrow keys) up and down to move through commands. Type partial commands to filter, then scroll.
Auto-copy - just highlight text in iTerm and it will automatically be copied to the clipboard.

oh my zsh

If you, like me, want to make your terminal work for you, get oh my zsh. Here's what my terminal prompt looks like:

When I have uncommitted changes, I get a yellow x to the left of my cursor. It's really handy for recognizing that I have changes hanging out.

You can do lots of things with oh my zsh - there's a library of different ways you can style your terminal. I use theme "robbyrussel". Note that you will also want to use .zshrc instead of .bashrc for aliases and other modifications to terminal settings.

While we're here, let's give a huge shout to terminal aliases. I love the "insider" language I have with my terminal. Here are a few I put into .zshrc. I don't need all of them anymore, but I left them here to show some of the ridiculously long commands that can be aliased to something very short.

alias j-u='jest --updateSnapshot'
alias ytu='yarn test-update'
alias dcu='docker-compose up'
alias dcd='docker-compose down'
alias lint-front='docker-compose exec front yarn gulp lint'
alias back-bash='docker-compose exec back bash'

.gitconfig

You probably have a .gitconfig on your computer, but you may not be using git aliases to save yourself some keystrokes. Here's mine:

# This is Git's per-user configuration file.
[user]
    name = amberwilkie
    email = amber@amberwilkie.com
[alias]
    co = checkout
    st = status
    ci = commit
    lp = log --oneline
    poh = push origin head
    rc = rebase --continue
    prom = pull --rebase origin master

Under that [alias] header, you can put whatever you want, including complicated git commands particular to your organization. It's super-handy.

.gitignore_global

Did you know you can automatically ignore files in every git repo on your computer? Put them in .gitignore_global and never have to fuss with .DS_Store in your .gitignore again. I put .idea in mine as well, since my editor of choice generates profiles in every repo.

Github SSH keys

New computer, new SSH keys. Follow the Github instructions so you don't have to type in your credentials ever again.

Trash

Have you ever felt that rm -rf folder was a little too final? With this simple Trash npm package, you can call trash file/folder to literally move it to your computer's trash instead of deleting it from memory. It can be recalled, or otherwise managed. This has saved me plenty of times.

Pro tip: Always run rm -rf node_modules instead of trash node_modules (you 100% never need to recall your old node_modules).

Homebrew & Cask

If you have a mac, you already know you need Homebrew and Cask. The first to install packages, the next for applications distributed in binary.

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install cask

Programs

My editor of choice is Webstorm, though I'm trying to create a workflow with VS Code at the moment. I'll skip all the editor-related stuff, since it's covered so well in my many other places. Here's the rest of what I install on day one.

TimeOut

TimeOut blocks your screen at intervals, forcing you to take a break. I keep mine at 2 minutes every hour and 15 seconds every 15 minutes. It can get annoying, but it's good for my health. We know sitting for extended periods of time is bad for us, but it's far too easy to let four hours go while we just fix this liiiiittttlllllle thing. Conveniently, my break popped up while I was writing this paragraph. (Normally the image and timer are aligned, not sure what is up with that.)

You can set the image to be whatever you want and can add text.

gitx

I would love to install gitx because I was using it extensively on my old computer. Unfortunately, it's no longer maintained! I have been experimenting with other git UIs but none of them are meeting my needs yet. More investigation is needed. If you have an older version of Mac, you might be able to get your hands on this original, extremely useful, tool. And if you can write natively, consider contributing!
GitX is extremely useful for quickly reviewing changes in your current commit and editing those changes.

Alfred

I always install Alfred, though I honestly have not yet taken the time to fall in love. I am aware that there are a thousand features that developers use every day. It's on my productivity improvements list to figure out! I'm likely to buy the power pack so that I can access the improved clipboard, which looks awesome.

I was using Clipy before, but the visual preview of what you are going to paste seems incredibly helpful.

But whatever you do, get a damn clipboard extension! Having only one clipboard slot is impossible. How many times have you had to go back and forth between things copying and pasting? Having a better clipboard manager significantly improved my efficiency as a developer.

Spectacle

This program allows you to snap windows to various parts of the screen. My new workplace has provided me with a baller 4k monitor, but that thing is so damn huge, when I plug it in, my windows are floating in a sea of desktop. Spectacle allows me to snap them where they belong with keyboard shortcuts. Magic!

Giphy Capture

This may sound silly, but as a web developer who works on the front end (sometimes), I find myself needing to make short gifs to explain functionality constantly. Giphy Capture is the best tool I've found for this - it's intuitive and does everything you need it to do.

And that is everything I consider core for getting to work as a web developer on a Mac! Naturally, a thousand other programs follow, as dictated by need, but these are the settings and programs I find indispensable in getting started. If you have any tips on other productivity tools that might useful, I'd love to hear.

This post originally appeared on wilkie.tech

Hide the new Twitter sidebar: a simple, locally-hosted Chrome extension

Amber Wilkie — Thu, 25 Jul 2019 18:51:23 +0000

After seeing folks complain about the new Twitter design for days, I finally got it. Indeed, the meat of the page seems to be lost. After realizing I could quickly get rid of the right side-bar by simply hiding it, I decided to write a Chrome extension so I wouldn't have to go in and do that again.

To install this guy, head to the github repo and follow the README instructions. If you've never played around with Chrome extensions, this is a great intro - an incredibly simple extension that adjusts the CSS on one page. Extensions are really neat, and there's a world of things you can make with them.

The extension will run locally on your machine. If at any time you want to see the side bar again, just turn off the extension (at chrome://extensions) or click the little icon for the extension and remove its permissions.

Happy tweeting!

Tell me about your experiences with tech recruiters

Amber Wilkie — Mon, 10 Jun 2019 17:47:05 +0000

I'm mid-career, which means I've already been through one round of job-hunting where I got "help" from recruiters. On the one hand, having someone write you about job opportunities is awesome. On the other, they can be very unprofessional, and I get the feeling that there are a class of recruiter jobs and another entire pile of jobs that recruiters don't have access to. And I wonder if that second pile is where all the "good" jobs are.

What has been your experience? Did you work with a recruiter at your current role? Do you recommend or advise against letting a / many recruiters steer your job hunt?

How to create a searchable log with Gatsby

Amber Wilkie — Thu, 16 May 2019 17:23:45 +0000

For all your developer note-taking needs

Taking notes is key to remembering most things in our lives. How many times have you worked on a project, then three months later needed to get back in the code, and it took you hours to come back up to speed? If you had taken a few minutes to jot down some documentation, you could have cut to the chase.

Personally, I keep my notes all over the place — in notebooks, mostly, but also right here on this blog. Many times when I finish a large, difficult feature, I like to blog key elements of it so I can come back later and figure out how I did what I did. Plus, it might help someone else along the way. However, there are tons of things I learn every day that just slip away. I keep learning and re-learning them and that’s inefficient.

I recently wanted a way to quickly jot down things I learn throughout the day, or lessons I want to keep in mind. But that’s not enough — I also need to be able to search these logs so I can find exactly what I’m looking for right away. That’s exactly what I’m going to show you how to build today. This project, front-to-back, took me maybe an hour and a half.

Gatsby

This project is built using Gatsby, the wildly popular front-end framework for creating static websites. I’m going to skip all the sales pitch stuff and just jump into the code, but if you want to back up a step, I wrote a long blog post about why I love Gatsby so much. In short: it’s awesome if you know React, and probably worth learning anyway if you need a static site.

Step 1: Create a new Gatsby site using the beautiful “Julia” template

Assuming you’ve got the Gatsby CLI working, run this to pull the pared-down but beautifully laid-out Julia template:

gatsby new <site-name> https://github.com/niklasmtj/gatsby-starter-julia

Pop open the gatsby-config.js and swap out your details for “Julia Doe” under siteMeta. You’re halfway there.

Step 2: Add logging

Now we want to add some functionality to the site. In the content directory, add a markdown file or twenty. Nest them however you like. You’ll follow this format:

---
title: "Whatever title you want"
date: "2019-05-010"
draft: false
path: "/logs/some-slug-for-the-file"
tags: testing, documentation
---

_# Monday, May 6, 2019_  
\* Added documentation ....

Note that path needs to be unique for each file. I named mine by date (with each week getting one file) but obviously you can do anything you like.

Step 2A: follow the Gatsby documentation for creating pages from Markdown

I could reiterate, but the Gatsby documentation itself is incredibly straightforward and easy to follow. You’ll install the required plugins, configure them in gatsby-config.js, create a template for how your posts should look, and set up gatsby-node.js to build pages from your markdown files.

To steal a tip from somewhere else on the internet: if you head to a localhost page you know doesn’t take you anywhere (I prefer localhost:8000/garbage), you can see all the available links for your page. It’s a quick way to check Gatsby has created all your markdown pages appropriately.

Keep it clean

I learned working on this project that you can assign multiple folders to get scanned by Gatsby’s file system plugin:

{
  resolve: `gatsby-source-filesystem`,
  options: {
    name: `images`,
    path: `${__dirname}/src/images`,
  },
},
{
  resolve: `gatsby-source-filesystem`,
  options: {
    name: `markdown-pages`,
    path: `${__dirname}/src/content`,
  },
},

So no problem if you are already using gatsby-source-filesystem to read, for instance, your image files. I also tested nesting, and Gatsby will grab anything in your content folder recursively — so you can go ahead and organize any way you like.

Good times! If you took that diversion to the Gatsby docs, you should now have a fully-functioning log system.

Step 3: Add search

Now the fun part. We’ll add the ability to search our logs using the Gatsby lunr elastic search plugin.

Configure

First, yarn add @gatsby-contrib/gatsby-plugin-elasticlunr-search, then we’ll add to gatsby-config.js:

{
  resolve: `@gatsby-contrib/gatsby-plugin-elasticlunr-search`,
  options: {
    // Fields to index
    fields: [`title`, `tags`, `html`],
    resolvers: {
      MarkdownRemark: {
        title: node => node.frontmatter.title,
        tags: node => node.frontmatter.tags,
        path: node => node.frontmatter.path,
**html: node => node.internal.content,**
      },
    },
  },
},

Note that I’ve added a field not included on the lunr docs: html. We’ll need this for full text search of the logs, rather than just searching by tags.

Add a search bar

Obviously yours can go anywhere. I put mine right on the index under my name.

The search bar component:

import React from "react"
import { graphql, StaticQuery } from "gatsby"
import Search from "./search"

export default () => {
  return (
    <StaticQuery
      query={graphql`
          query SearchIndexQuery {
            siteSearchIndex {
              index
            }
          }
        `}
      render={data => (
        <Search searchIndex={data.siteSearchIndex.index}/>
      )}
    />
  )
}

Nothing much going on here — we’re just grabbing the search index from the elastic search data.

The search component, essentially copied directly from the lunr docs:

import React, { Component } from "react"
import { Index } from "elasticlunr"
import { Link } from "gatsby"
import styled from "@emotion/styled"

export default class Search extends Component {
  state = {
    query: ``,
    results: []
 }

  render() {
    return (
      <div>
        <input type="text" value={this.state.query} onChange={this.search} />
        <ul>
          {this.state.results.map(page => (
            <li key={page.id}>
              <Link to={"/" + page.path}>{page.title}</Link>
              {': ' + page.tags}
            </li>
          ))}
        </ul>
      </div>
    )
  }

  getOrCreateIndex = () => {
    return this.index
      ? this.index
      : // Create an elastic lunr index and hydrate with graphql query results
      Index.load(this.props.searchIndex)
  }

  search = evt => {
    const query = evt.target.value
    this.index = this.getOrCreateIndex()
    this.setState({
      query,
      // Query the index with search string to get an [] of IDs
      results: this.index
        .search(query, { expand: true })
        // Map over each ID and return the full document
        .map(({ ref }) => {
          return this.index.documentStore.getDoc(ref)
        }),
    })
  }
}

You build a search index, fetch results based on a partial string, hydrate those results based on what the index returns, then map over them to display.

And that is seriously it. Your markdown pages will be built when Gatsby build runs and your search will index the first time you try to search.

Step 4: Add security

I’m not putting any state secrets or env variables in these logs, but I would rather not have a potential employer stumble upon them, mostly because I want to be free to talk about my struggles or be very clear about what I don’t know. If I have to censor myself, it will affect the quality of my logs.

At the same time, I can’t be bothered with a login or anything too fancy. So I opted for the silliest, loosest, easiest security I could come up with: a basic localStorage token. If you have it, you see the logs, and if not, too bad. Here’s how that works.

In landing-bio.js and anywhere else I want to protect:

const isBrowser = () => typeof window !== "undefined"
const isAuthenticated = isBrowser() && window.localStorage.getItem('authenticated');

[...]

{isAuthenticated ? <SearchBar /> : <div>You aren't Amber, so you don't get to read her logs.</div>}

I would never use this for actually-sensitive information, but it’s great for a tiny bit of peace of mind that my coworkers won’t be sneaking around my personal logs.

Note that the browser check (first line) is needed for this to pass tests on Netlify — it works fine without it otherwise.

Bonus: Deploy with Netlify

I talked about how much I love Netlify on my previous Gatsby blog post, and I still love them. It’s so dang easy to get your stuff right online.

All you’ll do is head over to Netlify, authorize them to access the Github where your logs are stored, and they will monitor Github and make new releases for you whenever you push to master. They will also create deploy previews when you make PRs! It’s really wonderful and I super-recommend them.

If you are going to create logs in markdown, I highly recommend a deploy system as easy as this one, and I don’t know of another that is as seamless.

When to use a function declaration vs. a function expression

Amber Wilkie — Fri, 19 Apr 2019 15:44:14 +0000

Tech Jargon Series

It’s likely you already know how to write functions in both these ways. function doStuff() {} and () => {} are characters we type all day. But how are they different and why use one over the other?

Note: Examples are given in JavaScript. _Y_our _M_ileage _M_ay _V_ary with other languages.

The first difference: a name

When you create a function with a name, that is a function declaration. The name may be omitted in function expressions , making that function “anonymous”.

Function declaration:

function doStuff() {};

Function expression:

const doStuff = function() {}

We often see anonymous functions used with ES6 syntax like so:

const doStuff = () => {}

Hoisting

Hoisting refers to the availability of functions and variables “at the top” of your code, as opposed to only after they are created. The objects are initialized at compile time and available anywhere in your file.

Function declarations are hoisted but function expressions are not.

It’s easy to understand with an example:

doStuff();

function doStuff() {};

The above does not throw an error, but this would:

doStuff();

const doStuff = () => {};

The case for function expressions

It might seem like function declarations, with their powerful hoisting properties, are going to edge out function expressions for usefulness. But choosing one over the other requires thinking about when and where the function is needed. Basically, who needs to know about it?

Function expressions are invoked to avoid polluting the global scope. Instead of your program being aware of many different functions, when you keep them anonymous, they are used and forgotten immediately.

IIFE

The name — immediately invoked function expressions — pretty much says it all here. When a function is created at the same time it is called, you can use an IIFE, which looks like this:

(function() => {})()

or:

(() => {})()

For an in-depth look at IIFEs, check out this comprehensive article.

Callbacks

A function passed to another function is often referred to as a “callback” in JavaScript. Here’s an example:

function mapAction(item) {
  // do stuff to an item
}

array.map(mapAction)

The problem here is that mapAction will be available to your entire application — there’s no need for that. If that callback is a function expression, it will not be available outside of the function that uses it:

array.map(item => { //do stuff to an item })

const mapAction = function(item) {
  // do stuff to an item
}

array.map(callbackFn)

though mapAction will be available to code below its initialization.

Summary

In short, use function declarations when you want to create a function on the global scope and make it available throughout your code. Use function expressions to limit where the function is available, keep your global scope light, and maintain clean syntax.

References

Function declaration, MDN docs.
Function expression, MDN docs.
Hoisting, MDN glossary.

The Tech Jargon Series

There are so many phrases that get thrown around at tech meetups and conferences, assuming that everyone is already down with the lingo. I’m often not down with the lingo. It’s common for developers to act astonished that I lack a piece of knowledge.

The truth is, I often just don’t know the right word for it. As humans, but especially developer humans, we love to dismiss those who don’t “talk the talk”, so this series is about getting a solid understanding of programming concepts that one “should know”.

This is the second article in the series. The first was higher-order functions. Look out for more as I go to meetups and conferences and pretend to know what my fellow techies are talking about, but then have to go home and Google it.

Uploading source maps to Sentry with Gulp: solved!

Amber Wilkie — Thu, 18 Apr 2019 14:59:02 +0000

I’m learning that the first thing any new developer on the job wants to do is upend all the tooling. I was crazy-frustrated when we onboarded a dude at my old company who wanted to do this. Now that I’ve started a new job, I’m the one complaining about tooling (and feeling humble).

So here I was, trying to get into the code base at this tiny startup. I’d gotten my login for Sentry, the error tracking service, and was rearing to pick some bugs and start fixing. Unfortunately, this is what I saw:

Useless minified reference to error in the code

A reference to minified code. This sent me down what seems like an unnecessarily complicated rabbit-hole of sourcemappery. May you, dear reader, avoid this suffering with the tips to follow.

What is a sourcemap?

A sourcemap is a guide to translate a minified version of Javascript code to the human-readable code we work with. Because we write massive amounts of Javascript and send it willy-nilly to browsers all over the place, we minify it to eke out those easily-tossable bytes. We end up with code like in the screenshot above.

Typically, we will bundle up the Javascript in our files, dump it all into one file, then minify it for shipping to the browser. A function like this:

const myFunction = (paramOne, paramTwo, paramThree) => {
  console.log(paramOne);
  return paramTwo + paramThree
}

gets minified to this:

const myFunction=(o,n,c)=>(console.log(o),n+c);

Great for browsers, not so great for anyone who needs to figure out what the heck myFunction is doing.

Don’t upload source maps to production (I guess)

The easier it is to figure out how your code is doing what it’s doing, the easier it will be for bad guys to find a way to exercise their badiness. Source maps are essentially a guide to your code, so it can be a security risk to upload them to production. That said, the internets seem to be of two minds on this. If you feel comfortable sending them to the world, I guarantee you that’s an easier way to get your proper stack trace on Sentry.

Sentry allows you to directly upload source maps, bypassing any security issues with having them online. But they are very particular about how you upload those files and nothing less than exactly right will produce code you actually want to see in their error log.

Starting point

When I walked into this project, we were already generating source maps with gulp-sourcemaps, and sending them to sentry using gulp-sentry-release, an npm package that hasn’t been updated in three years (!). Here’s a super-pared-down version of our gulp scripts task:

gulp.src('./scripts/\*\*/\*.js')
  .pipe(plugins.sourcemaps.init())
  .pipe(plugins.concat('./scripts.js'))
  .pipe(plugins.uglify)
  .pipe(plugins.sourcemaps.write('.'))
  .pipe(gulp.dest('./dist'))

and Sentry deploy:

const sentryRelease = plugins.sentryRelease({
  API\_URL: 'https://app.getsentry.com/api/0/projects/our-team',
  API\_KEY: process.env.SENTRY\_API\_KEY,
});

const version = // some git thing that wasn't working

gulp.src('\*\*/\*.js.map')
  .pipe(sentryRelease.release(`${process.env.APP_ENV}-${version}`));

Problem one: versioning

The first thing I had to fix was versioning. Sentry expects you to provide information about a release. If a user is looking at a certain release on your site, then you need to have told Sentry which source maps you are dealing with. We were using a git versioning that stopped working when the company switched to Docker nearly a year ago. Sentry had been looking at everything we pushed to production as staging- or production-.

I solved this by creating a version in my package.json and incrementing it when we push to production with gulp-bump. My gulp task looks like this:

if (process.env.APP\_ENV === 'production') {
  gulp.src('./package.json')
    .pipe(plugins.bump({type: 'minor'}))
    .pipe(gulp.dest('./'));
}

I read from package.json to version my sentry release:

import { version } from '../../../package.json';

and then I can use the same code I had before to send to Sentry:

gulp.src('\*\*/\*.js.map')
  .pipe(sentryRelease.release(`${process.env.APP_ENV}-${version}`));

Adding the release to the code shipped to the browser

This is great for telling Sentry that these source maps belong to this release. But what about the user browsing along on my app and getting an error? The browser needs to be able to tell Sentry which release that person is viewing. In our code, we use the Sentry Raven client:

Raven.config('our-api-url-for-sentry', {
**release: 'SENTRY\_VERSION',**
  dataCallback: function(data){
  ...

We later regex out the SENTRY_VERSION from our code using gulp-replace:

import { version } from '../../../package.json';

gulp.src('./html/\*\*/\*.html').pipe(plugins
  .replace('SENTRY\_VERSION',(`${process.env.APP_ENV}-${version}`)))

Now the version in our HTML will match the version we send to Sentry.

Note: the file doesn’t seem to get saved early enough in the gulp process. I’m hopeful a switch to gulp 4 will just resolve this. If not, there’s plenty more work to do figuring out how to version this in any logical way.

Problem two: uploading the right source maps

For ages, I thought I had it but Sentry was still trying to grab source maps from the internet. I knew because it was throwing an error saying they could not be found. Indeed, I had not uploaded them to production.

Though gulp-sentry-release has not been touched for three years, it still handles the Sentry API just fine, as long as you manage to pass in the right options:

const sentryRelease = plugins.sentryRelease({
  API\_URL: 'https://app.getsentry.com/api/0/projects/our-team',
  API\_KEY: process.env.SENTRY\_API\_KEY,
  DOMAIN: '~'
});

Did you miss the change? DOMAIN defaults to '' in this outdated package. Sentry has since decided they want to see a tilde on the front of sourcemaps. When I added this piece, suddenly it all came together.

Finally seeing human-readable code in Sentry

There’s a good chance this didn’t solve your problem, as Sentry has a whole bunch of documentation on how to troubleshoot this issue. The tilde is just one of many, many problems people have trying to make this work. If you’re still on the hunt, best of luck! And if this did help you, I’d love to hear about it.

Higher-order functions: what they are, and a React example

Amber Wilkie — Tue, 02 Apr 2019 16:58:06 +0000

Tech Jargon series

My first topic for this series is Higher-Order Functions. I was at a tech meetup the other day, and we were discussing React and how difficult it can be for React newbies to get into the code. I mentioned that higher-order components (HOCs) can be tough to understand. A response was that they are much like higher-order functions, don’t I agree? And I said: “I don’t know what that is.” When I asked for an example, I was told “map”. I made a joke about how I have no idea what “map” is and we moved on.

But still: what is a higher-order function?

(Note: all the examples given are in Javascript, but this concept applies to every programming language.)

Higher-order functions: a definition

A higher-order function is one which either a) takes a function as an argument or b) returns a function.

If a function doesn’t do either of those things, it is a first-order function.

Map

Let’s start with the example I was given: map.

[1, 2, 3].map(num =\> num \* 2)
\> [2, 4, 6]

The map function is called on an array and takes a “callback” function. It applies the function to each of the items in the array, returning a new array. [1, 2, 3] is our array and num => num * 2 is our function. A callback is the function argument passed to our higher-order function.

This HOF is baked into the language, prototyped on Array (Array.prototype.map).

Other examples of HOFs prototyped on Array are filter, reduce, and some.

Custom example

So let’s write our own higher-order function.

Passed function

const myFunc = age =\> age \* 2

Higher-order function

Now we write a function that takes in a function.

const hof = (customFunc, age) =\> customFunc(age + 5)

We’ll pass a number to hof, which will add 5 and then call our passed function, which will double it. If we pass 10, we pass 15 to our first function, which then doubles to 30.

Our dead-simple higher-order function running in the terminal

Custom example with React “components”

As I noted above, this topic came up in reference to React’s components. As a React component is a function, when passing it to another function, we are creating our own higher-order function, which React calls “higher-order components”. If you are using stateful components (and extending React’s Component), you are already using HOCs.

Stateless Component

const details = ({ name, randomNum }) =\>
 `${name}, ${randomNum}`

We have a function, called details, into which we pass props. We are deconstructing them as they come in and assigning them to local variables name and randomNum. This is ES6 syntax — if it looks unfamiliar give it a google (you’ll love it).

This is a first-order function — it takes one argument (a props object) and returns a template literal.

Higher-order component

const hoc = (component, props) =\> {
 const randomNum = Math.floor(Math.random() \* 100)

return component({ ...props, randomNum })
}

This is a higher-order function — it takes in a function (the component, which it then calls, passing in additional props). This is an extremely basic example of what every stateless React component is doing.

Our super-basic “component” running in the console

You can employ this pattern to abstract code that is shared among many components in your application.

Are you wondering if you can nest higher-order functions? You can! But be careful. Abstractions should make code easier to read and work with. It’s easy to get down a path here where your code is so obtuse no one can figure out how to do anything.

References

Higher-order-function, Wikipedia
Higher-order functions, Eloquent Javascript (chapter 5)
Array.prototype MDN docs.