DEV Community: Ed Bentley

Nix for Frontend Developers

Ed Bentley — Wed, 23 Sep 2020 19:53:25 +0000

I recently bought a new MacBook. My old MacBook had become bloated with random CLI tools, version managers and Homebrew packages from all over the internet. I always seemed to have install issues with Node and npm (I'd tried both nvm and n at various points) and had no way of knowing what was installed, where it came from or how to remove it.

So while marvelling at the smooth aluminium exterior of my new laptop, I had a strong desire to keep the interior system as clean and tidy as possible too. And it just so happens I'd been hearing about something exciting called Nix at the time.

Nix is an open source tool which describes itself as a "package manager". You can use Nix to manage the packages on your system such as git and Node, like you would with Homebrew. But the "package manager" part is just the tip of the iceberg: in this post I'll explain why Nix's ability to setup dev environments can give you frontend developer superpowers.

Install Nix

Feel free to read about what Nix can do below before installing. But if you want to follow along, here's what you need to do.

If you're on a Mac like me, you'll need to setup a new /nix volume to install Nix. You can follow Solution 1 of this GitHub comment - it's a pain, but it works, and once you've done it once you don't need to worry about it again. Since us Mac users are likely on zsh, I also had to add this for initial setup (it's normally added to a bash profile):

❯ cat ~/.zprofile
. ~/.nix-profile/etc/profile.d/nix.sh

If you're on Linux, just head to the Nix download page and install.

If you're on Windows, then our path ends here my friend. Maybe try Linux on Windows?

Nix the dabbler

Sometimes you just want to try hacking on something for a short time - but to do that you need to install a lot of software. For example in 2017 I'd been playing around with Machine Learning Python frameworks, and had a ton of (outdated) tools lying around my system, clogging up my CLI path and taking up space. Not ideal.

Let's imagine we wanted to play with PureScript. If you run the command:

nix-shell -p purescript

We're now in a shell with access to the PureScript CLI:

[nix-shell:~]$ purs --version
0.13.6

If you type exit or close that window, then boom PureScript is gone without a trace! (Well, it's leftover in a cache in case you decide to use it again later on, but don't concern yourself with that).

Just like the npx command, we can even run CLIs for a one-time-only use:

nix-shell -p nodejs --run 'node -v'

Nix the environment

Let's take this a step further. I recently needed to make a small change to a Haskell program I'd made as a personal project. Now I don't want to manually type all the nix-shell -p ... packages every time I need to hack on my Haskell project, but I also don't want lots of Haskell compilers and package managers clogging up my precious system.

Enter the shell.nix file. Here's my very simple Haskell setup:

with (import <nixpkgs> {});
let ghc = haskell.compiler.ghc865;
in haskell.lib.buildStackProject {
  inherit ghc;
  name = "myEnv";
  buildInputs = [ pcre ];
}

This is the Nix language - think of shell.nix as a powerful Webpack config file. I won't go into details here on how this works (for that see the resources at the end), but we're essentially describing the environment we need Nix to setup for the project. We can even specify which version of programs we need (for example, Node 12 instead of Node 10).

To get into the correct dev environment to build and hack on the project, you simply run nix-shell in the directory with the shell.nix file.

I can commit shell.nix, share this repo on GitHub - and any other Nix user (or myself in the future) who clones this repo is guaranteed to have the same dev environment.

Do you feel the power at your fingertips yet? No more "works on my machine" problems. No need to manually switch Node versions between repos (goodbye nvm!). No more over-the-top Docker environments necessary either (Docker, we've had a great run, but maybe it's for the best?).

Nix the package manager

nix-shell is great, but there are some tools we do want installed at all times, like git and Node.

We can view what Nix has globally installed for us (including itself):

❯ nix-env --query --installed
home-manager-path
nix-2.3.4

We can see what packages are available to install, for example see versions of Node:

❯ nix-env -qa nodejs
nixpkgs.nodejs       nodejs-10.20.1
nixpkgs.nodejs-10_x  nodejs-10.20.1
nixpkgs.nodejs-12_x  nodejs-12.16.3
nixpkgs.nodejs-13_x  nodejs-13.14.0
nixpkgs.nodejs-14_x  nodejs-14.3.0

Where are the packages coming from? It turns out there's a gigantic 240k+ commit GitHub repo where we're all encouraged to write Nix files describing dependencies. For example, here's Node's v12.nix. It's this herculean crowd-sourced effort that enables you to smoothly add and remove packages as you please.

We can then add new programs into our global environment with nix-env -i ...:

❯ nix-env -i nodejs
installing 'nodejs-10.20.1'
building '/nix/store/vvanv82vvw2lyc79bs3plnygphnpvvva-user-environment.drv'...
created 5005 symlinks in user environment

Nix will even list your entire install history, just like a git history:

❯ nix-env --list-generations
   1   2020-05-23 10:53:43
   2   2020-09-20 19:07:11   (current)

Perhaps our last install was a huge mistake (it installed Java or something) and we need an undo button. Fortunately, just like git histories, your install history (known as "generations") is immutable and can be easily undone:

❯ nix-env --rollback
switching from generation 2 to 1

Phew! Now you can play around with installing tools, without worrying about permanently messing up your dev environment.

You can use Nix in this way as a simple package manager, but actually I never use nix-env. There's an alternative, even better way.

Nix the operating system

There's a version of Linux available called NixOS. It takes the ideas of Nix - describing your environment in a .nix file - to the entire operating system. The entire OS is configured in /etc/nixos/configuration.nix, which makes it perfect for spinning up identical machines.

That's great for the DevOps crowd, but not so useful for us Frontend Developers who are are enjoying our Mac experience.

Instead, I've been using a community tool called Home Manager to achieve a similar experience. It's more focussed on your user setup instead of the entire system (like NixOS is), but that suits us. Instead of manually installing our tools like Node through nix-env, we can simply list in a .nix file all the tools we want and all the configs and dotfiles we want.

If we think of typical setups (like Homebrew and git config commands) as jQuery, where we're always mutating the state of things, then think of Home Manager as a pure React component: a declarative function that we can run again and again without fear.

Here's a shortened example of my ~/.config/nixpkgs/home.nix file:

{ config, pkgs, ... }:

{
  programs.home-manager.enable = true;

  home.stateVersion = "20.03";

  home.packages = [
    pkgs.iterm2
    pkgs.nodejs-12_x
    pkgs.cheat
  ];

  home.sessionVariables = {
    EDITOR = "vim";
  };

  home.file = {
    ".zshrc".text = ''
      # Aliases
      alias ls="ls -a"
      alias ll="ls -lhA"
    '';

    ".macos".text = ''
      # Disable the “Are you sure you want to open this application?” dialog
      defaults write com.apple.LaunchServices LSQuarantine -bool false
    '';
  };

  programs.vim = {
    enable = true;
    settings = {
       number = true;
    };
  };

  # https://github.com/rycee/home-manager/blob/master/modules/programs/vscode.nix
  programs.vscode = {
    enable = true;
    userSettings = {
      "editor.tabSize" = 2;
    };
    extensions = [
      # some can be found here: https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/vscode-extensions/default.nix
      pkgs.vscode-extensions.vscodevim.vim
      pkgs.vscode-extensions.bbenoist.Nix
    ];
  };
}

You can see I've listed some packages I want like Node and cheat. I've written to some dotfiles manually (like .macos) but also used some of Home Manager's settings to configure some like vim. No need to share dotfiles anymore, we can just share home.nix files!

The difference between home.packages and the rest of the file can be a little confusing. home.packages lists the packages you can install from that big GitHub repo called nixpkgs we used with nix-env earlier. But those are just packages and don't say anything about how to configure them, e.g. through a dotfile.

For configuration, we can make use of Home Manager's modules, which are also stored in a big directory on the GitHub repo (though nowhere near as big as nixpkgs). It works in a similar way to NixOS but has some differences, which is why it has its own GitHub repo.

To edit home.nix I just run:

home-manager edit

And when I'm ready to try the changes out on my system, I run:

home-manager switch

That's it! You can feel safe and secure knowing that you can revert to a previous version of your home.nix file if something goes wrong.

And since my home.nix file is backed up, if anything happened to my MacBook, getting back to my desired environment would take no effort at all (except for installing Xcode of course, that takes forever). What's more, if you have a personal and work laptop, it's easy to keep your dev environment synced between them.

Nix the time sink

So far I've given Nix a glowing review, so there must be a catch, right? Well, it's taken me a long time to get my Nix environment to the state I want it to be, and that's the catch. Nix really takes up a lot of time to learn and get right.

Firstly there's a whole new language to learn to know how to read and write .nix files.

Then what happens if a Nix package you want to install hasn't been added yet? Well, you need to spend time contributing it.

True story: I needed to use the audiowaveform CLI tool briefly, but it's not on Nix. It is on Homebrew though, and I was being lazy, so I booted up my old MacBook and used it there. 🙈

And then you find out there's no Home Manager module for what you need - you need to submit a PR for that too.

GUI applications (e.g. Chrome) are difficult / impossible to manage through Home Manager too, and I wouldn't recommend doing so. For example I can't change my VS Code settings within the app, since the settings.json file is "Read Only". It's great that Nix is immutable like that, but it takes away the convenience in some cases.

I hope this post has helped explain some of the core concepts around Nix, but going through all of the details can be tedious to debug and get right. It's another layer of setup you need to figure out, which is tough if no one else on your team is doing it (until you inevitably convince them, of course).

The community is not enormous and the existing documentation leaves a lot to be desired. It's certainly not a smooth developer experience yet.

But don't let any of that deter you! 😁

Nix for Frontend Developers

I've been using Nix for my frontend work for the past few months and it's been working a treat. It certainly was a lot to learn upfront, but the magic of setting up my tools in an organised manner (and not breaking them again) has been 100% worth it.

I've got my regular tools like Node listed in a Home Manager home.nix file. My dotfiles and program configs are there too.

I've got projects in other languages (like the Haskell one) using a shell.nix file to easily get my environment setup. Web projects often rely on just Node and npm, but you can use a shell.nix file to specify the minimum Node version supported too.

In theory Nix could completely replace npm, but that goes so against the grain I wouldn't recommend even trying. A local node_modules and npm install still works fine. Global npm modules must still be handled through Nix packages though.

VS Code is the text editor of choice for many frontend developers. As mentioned earlier, you can use Home Manager to install it, write its settings and install extensions through the home.nix file. But every extension needs to be added as a module (and most are not there), so it's simply easier at the moment to download from the website. And with Settings Sync, you're already getting most of the benefits Nix would provide anyway.

That's it from me! If Nix seems to your liking and you're willing to get your hands dirty for some developer superpowers, here's a bunch of resources to take you further:

The official docs of course
Burke Libbey's YouTube videos on Nix (highly recommend!)
A nice summary of Nix commands through use cases
A tour of Nix to learn the language
The official Home Manager manual
Some tips on Node with Nix
The friendly Discord channel

Happy Nix hacking!

Introducing Replay: a cross-platform JS game engine inspired by React

Ed Bentley — Sat, 02 May 2020 18:09:36 +0000

Today I'm publishing a new open-source library for creating games: Replay.

I've built many indie games over the years (such as The Impossible Game). I've also built many web apps using React.

Replay takes the ideas and concepts that makes React such a great library for building user interfaces, and brings them to game development. Take a look at how Replay manages state and rendering through a declarative API:

const Player = makeSprite({
  init() {
    // Initial state
    return {
      posX: 0,
      posY: 0,
    };
  },

  loop({ state }) {
    // Return new state at 60 fps
    return {
      posX: state.posX + 1,
      posY: state.posY + 1,
    };
  },

  render({ state }) {
    // Draw a circle based on current state
    return [
      t.circle({
        position: {
          x: state.posX,
          y: state.posY,
        },
        color: "#147aff",
        radius: 10,
      }),
    ];
  },
});

Check out the docs on how to quickly get setup with a new JavaScript or TypeScript project, and then deploy to the web or iOS.

I hope you enjoy using it to build some new games!

Mind-bending functional programming with TypeScript - part 2

Ed Bentley — Wed, 08 Apr 2020 21:37:29 +0000

Part 1: Introduction
Part 2: Effects

Let's imagine you want to write a function which writes to a file in Node. Here's a simple example:

import * as fs from "fs";

function writeHelloWorld(path: string) {
  fs.writeFileSync(path, "Hello world!");
}

writeHelloWorld("my-file.md");

What's the type of our function writeHelloWorld? fs.writeFileSync returns void, so naturally so does writeHelloWorld.

But let's think about this for a second. What if we took the same function and made it empty? Like this:

function writeHelloWorld(path: string) {
  // Nothing to see here!
}

It's got the exact same type (path: string) => void. But of course they do very different things. What the first example does - writing a file - is called an effect. It's certainly not a pure function.

If you're familiar with React hooks, this is exactly the same concept as useEffect, which you use for things like fetching data (which is very much an effect).

We're going to run on the assumption here that writing pure functions is good, and having side effects is bad.

So how could we make writeHelloWorld pure? Is this possible?

How about we make it lazy by having writeHelloWorld return a function?

import * as fs from "fs";

function writeHelloWorld(path: string) {
  return () => fs.writeFileSync(path, "Hello world!");
}

const runEffects = writeHelloWorld("my-file.md");

Is this code now pure?

no side effects ✅
same input always produces same output ✅

Seems pure to me! But it doesn't do anything. We also need to add:

runEffects();

Only this part of our code is impure, because without that, nothing would happen.

Is this cheating? Sort of, but it works.

In fact we can make our entire program pure, despite it being full of effects like file writes and random numbers all over the place. So long as every function with effects is lazy, we can combine all of our effects together into one lazy function - like a big red button to run the program:

// WARNING: do not call this function unless you're sure what you're doing!
function runMyPureProgram() {
  return () => {
    writeSomeFiles();
    getSomeRandomNumbers();
    getTodaysDate();
  }
}

Calling runMyPureProgram() is impure, yet the program itself is pure.

But how do we ensure our functions are pure? If I look at getSomeRandomNumbers and it returns () => number[], how do I know if it has an effect or not? If only there was some way the compiler could tell us this... 🤔

Well it's called Type Script for a reason! Let's imagine a new type:

type Effect<T> = () => T;

What we say is, any impure function with effects must return the type Effect. T is the return value - for example, if our effect was to read a file as a string it could be Effect<string>.

We can write:

function writeHelloWorld(path: string): Effect<void> {
  return () => fs.writeFileSync(path, "Hello world!");
}

Now, just by looking at the type signature of writeHelloWorld, we know it's going to be doing some effectful things. In this case, T is void since it doesn't return a value.

So if I start adding new impure things in my code, TypeScript will complain until I actually handle the effects correctly at the end of the program.

Through some lazy functions and a new type called Effect, we've both kept our program pure and we know where the impure effectful things are hiding. 🤯

If you're like me, at this point you might be thinking: "This is great! Wait - what's the point?". It seems like we still have a bunch of impure stuff littered around our codebase, and we've now made the code more awkward than it was before. All in the name of "purity".

Let's stop for a second for a quiz. Imagine this contrived example:

function funcA(): number {
  return funcB();
}

function funcB(): number {
  return funcC();
}

function funcC(): number {
  return 5;
}

We want to change funcC to return a random number. I'll give you three ways we could do this, which one is the 'best'?

1. The impure way:

function funcC(): number {
  return Math.random();
}

Easy! Nothing else to change, let's go home now.

2. Dependency injection:

function funcA(randomGenerator: () => number): number {
  return funcB(randomGenerator);
}

function funcB(randomGenerator: () => number): number {
  return funcC(randomGenerator);
}

function funcC(randomGenerator: () => number): number {
  return randomGenerator();
}

Our functions are still nice and pure, but we had to add an argument to them all, which is a lot of typing...

3. Effects

function funcA(): Effect<number> {
  return funcB();
}

function funcB(): Effect<number> {
  return funcC();
}

function funcC(): Effect<number> {
  return () => Math.random();
}

Everything's still pure but we had to change the return type of everything to make it lazy.

So I'll ask again, which one's the 'best'?

I would say typing effects are a blessing and a curse. It's exactly because they require you to change your function signatures you're forced to program in a way where effects are kept to a minimum in your code. And you're more likely to put them all in one place.

It's like immutability - it can be more annoying to do, but can provide a cleaner codebase overall. Whether the short-term pain is worth the long-term gain is always difficult to say though.

Even if you're now convinced to use the Effect type, this still isn't perfect. There's nothing in TypeScript which forces us to add an Effect type for effects, we just have to be vigilant about it. If you want to be forced to do it, that's when you head to pure a functional language like Haskell.

Introducing: IO

The fp-ts library already has a type just like Effect, and its name is IO. In fact, its type is exactly as we defined Effect.

// taken from source code
export interface IO<A> {
  (): A
}

The benefit of using IO is it comes with a lot of helper functions for handling effects. Plus, it provides functions for effectful things (like generating random numbers) which are already typed as IO. Here are some simple examples:

Add a number

Let's start here:

import { IO } from "fp-ts/lib/IO";
import { random } from "fp-ts/lib/Random";

function funcA(): IO<number> {
  return funcB();
}

function funcB(): IO<number> {
  // importing random from fp-ts is the same as
  // return () => Math.random();
  return random;
}

Imagine we want to add 1 in funcA:

function funcA(): IO<number> {
  return funcB() + 1;
}

Oops! We get the error:

Operator '+' cannot be applied to types 'IO<number>' and 'number'.

We could change funcA to this:

function funcA(): IO<number> {
  return () => funcB()() + 1;
}

But that's annoying and plain ugly. Instead fp-ts gives us io.map:

import { IO, io } from "fp-ts/lib/IO";

function funcA(): IO<number> {
  return io.map(funcB(), (x) => x + 1);
}

Much like you call .map on an array, you can map something of type IO too.

Logging a random number

We can use io.chain to combine two effects into a single effect:

import { IO, io } from "fp-ts/lib/IO";
import { random } from "fp-ts/lib/Random";
import { log } from "fp-ts/lib/Console";

function logRandomNumber(): IO<void> {
  return io.chain(random, log);
}

const program = logRandomNumber();

// this logs a random number when called
program();

In this way we can combine all of our effects into one program, which we then call right at the very end.

There's much more to learn that we haven't covered (I haven't even mentioned error handling), so do check out these resources if you want to find out more:

Mind-bending functional programming with TypeScript - part 1

Ed Bentley — Wed, 08 Apr 2020 17:33:15 +0000

Part 1: Introduction
Part 2: Effects

To start with, let's have a quiz.

Imagine a pure function, one with no side effects. You give it an input, it always produces the same output. It won't throw exceptions at you. It doesn't use variables outside the scope of the function. There's certainly no mutation.

We'll call it mysteryFunction. Now the only thing I'll tell you is its type signature. You need to guess what the body of the function is.

Is that even possible? Let's try:

function mysteryFunction<T>(x: T): T

It takes an argument x of generic type T, and returns type T.

Can you tell me, with absolute certainty, what's in the body of the function?

Try copying it into the TypeScript Playground and have a go:

function mysteryFunction<T>(x: T): T {
    // ?
}

Scroll further to see the answer.

...

It's this:

function mysteryFunction<T>(x: T): T {
    return x;
}

With just a type signature, we already know what the body of the function is. It just returns what you pass in. This is the only possible thing it could do (remember, it's pure - no console.log or anything allowed). Nothing else. 🤯

This function has a special name: the identity function.

Now let's try again with this type signature:

function mysteryFunction(x: string[]): string

What's in the body of this function? Scroll further to see the answer.

...

No idea! 🤷

It could return x[0], or x[1]. It could just return a constant "lolz" string. There are an infinite number of things it could be doing.

However since we know it's returning a string, we can guess some of the most likely things it's going to be doing.

Lastly, the opposite extreme of our first example: what's in the body of this function?

function mysteryFunction(x: any): any

...

It could literally be anything. But the space of possible things it could be is greater than our second mysteryFunction (if we forget about practicalities like memory, we can say both have an infinite number of possible function bodies - but for any it's a bigger infinity 🤯).

What I'm saying is, the less we know about the types, the more we know about the function's body - no names required. As our types become more concrete we loose that intuition on what the function is doing.

Does this matter, you ask? Probably not a great deal for your day-to-day programming (saying that, keeping functions more generic does make them more reusable). But that's not the point of this series.

In this series we're going to explore some less mainstream but totally fascinating concepts from the land of functional programming. We'll be taking a look at topics such as Semigroups and Monads using the great fp-ts library by Giulio Canti.

I can't say what we'll look at is suitable for the majority of your programming. But throughout our journey we'll be expanding our minds and taking inspiration from novel concepts together.

Resources for this part:

Next up is Part 2: Effects

Build your React charts without a library

Ed Bentley — Wed, 01 Apr 2020 15:04:20 +0000

So you want to build a chart in your React app? If you're like me, the first thing you did was search for something like "react charting library".

There are lots of great lists out there debating the pros and cons of different options like recharts and victory. A lot of them are built on top of D3. These libraries can get you up and running really quickly with powerful features, and for many use cases will be the right choice.

But here I want to show you how quickly we can build our own charts without any of these libraries. Since we already have React to manage the DOM, we'll just be using SVG to render our charts.

Why are we doing this?

Every new library you use requires learning how it works. But SVG is built into the browser - it's not going anywhere or being updated any time soon!
You can build your chart to your exact design requirements - no need to worry about whether the library supports what you want to do or not.
Save your precious kB! Sure, building your custom chart may require more lines of code in your app than using a library, but the total bundle size should be much smaller that way.

To go further with saving kB, the examples below all work with Preact too.

If you want to follow along, I'm starting with create-react-app using the TypeScript template:



npx create-react-app my-chart --template typescript

I recommend quickly adding Prettier for formatting too.

Chart Axes

In the diagram of the chart axes we're about to build below, I've added some variables to help visualise. We put y0 at the top since in SVG the y axis goes from top to bottom. You kind of have to look at everything upside down.

Open App.tsx and replace it with the following (I'll explain the code in more detail later on):



import React from "react";
import "./App.css";

const SVG_WIDTH = 400;
const SVG_HEIGHT = 300;

function App() {
  const x0 = 50;
  const xAxisLength = SVG_WIDTH - x0 * 2;

  const y0 = 50;
  const yAxisLength = SVG_HEIGHT - y0 * 2;

  const xAxisY = y0 + yAxisLength;

  return (
    <svg width={SVG_WIDTH} height={SVG_HEIGHT}>
      {/* X axis */}
      <line
        x1={x0}
        y1={xAxisY}
        x2={x0 + xAxisLength}
        y2={xAxisY}
        stroke="grey"
      />
      <text x={x0 + xAxisLength + 5} y={xAxisY + 4}>
        x
      </text>

      {/* Y axis */}
      <line x1={x0} y1={y0} x2={x0} y2={y0 + yAxisLength} stroke="grey" />
      <text x={x0} y={y0 - 8} textAnchor="middle">
        y
      </text>
    </svg>
  );
}

export default App;

And with that, we have an x and y axis!

To start with, we must put everything in the svg element:



    <svg width={SVG_WIDTH} height={SVG_HEIGHT}>
      ...
    </svg>

You'll notice all SVG elements work just the same as other DOM elements like div and p in React. For svg make sure to pass in a width and height.

Here I'm hardcoding the width and height, but for a responsive view this could be a prop in your component. There's a good example of measuring the width of the parent element in the React Hooks FAQ.

Next is the line element:



      <line
        x1={x0}
        y1={xAxisY}
        x2={x0 + xAxisLength}
        y2={xAxisY}
        stroke="grey"
      />

It's rather simple: draw a line from a point (x1, y1) to (x2, y2). At a minimum, we also need a stroke colour. If you read the docs you'll find far more ways to customise it, such as getting a dashed line or changing the thickness. But a thin solid line (the default) is good enough for now.

Lastly we have the text element:



      <text x={x0 + xAxisLength + 5} y={xAxisY + 4}>
        x
      </text>

As well as its content, it just needs an x and y coordinate. You'll notice for the y text I also included the textAnchor="middle" attribute to center the text.

Bar chart

To produce this chart, replace your code with the following:



import React from "react";
import "./App.css";

const SVG_WIDTH = 400;
const SVG_HEIGHT = 300;

const data: [string, number][] = [
  ["Mon", 12],
  ["Tue", 14],
  ["Wed", 12],
  ["Thu", 4],
  ["Fri", 5],
  ["Sat", 18],
  ["Sun", 0],
];

function App() {
  const x0 = 50;
  const xAxisLength = SVG_WIDTH - x0 * 2;

  const y0 = 50;
  const yAxisLength = SVG_HEIGHT - y0 * 2;

  const xAxisY = y0 + yAxisLength;

  const dataYMax = data.reduce(
    (currMax, [_, dataY]) => Math.max(currMax, dataY),
    -Infinity
  );
  const dataYMin = data.reduce(
    (currMin, [_, dataY]) => Math.min(currMin, dataY),
    Infinity
  );
  const dataYRange = dataYMax - dataYMin;

  const numYTicks = 5;

  const barPlotWidth = xAxisLength / data.length;

  return (
    <svg width={SVG_WIDTH} height={SVG_HEIGHT}>
      {/* X axis */}
      <line
        x1={x0}
        y1={xAxisY}
        x2={x0 + xAxisLength}
        y2={xAxisY}
        stroke="grey"
      />
      <text x={x0 + xAxisLength + 5} y={xAxisY + 4}>
        Day
      </text>

      {/* Y axis */}
      <line x1={x0} y1={y0} x2={x0} y2={y0 + yAxisLength} stroke="grey" />
      {Array.from({ length: numYTicks }).map((_, index) => {
        const y = y0 + index * (yAxisLength / numYTicks);

        const yValue = Math.round(dataYMax - index * (dataYRange / numYTicks));

        return (
          <g key={index}>
            <line x1={x0} y1={y} x2={x0 - 5} y2={y} stroke="grey" />
            <text x={x0 - 5} y={y + 5} textAnchor="end">
              {yValue}
            </text>
          </g>
        );
      })}
      <text x={x0} y={y0 - 8} textAnchor="middle">
        $
      </text>

      {/* Bar plots */}
      {data.map(([day, dataY], index) => {
        const x = x0 + index * barPlotWidth;

        const yRatio = (dataY - dataYMin) / dataYRange;

        const y = y0 + (1 - yRatio) * yAxisLength;
        const height = yRatio * yAxisLength;

        const sidePadding = 10;

        return (
          <g key={index}>
            <rect
              x={x + sidePadding / 2}
              y={y}
              width={barPlotWidth - sidePadding}
              height={height}
            />
            <text x={x + barPlotWidth / 2} y={xAxisY + 16} textAnchor="middle">
              {day}
            </text>
          </g>
        );
      })}
    </svg>
  );
}

export default App;

Let's break this down. At the top we have some mock data, with a value (I'm going to say $) for each day of the week. Then we need to calculate some values based on the data for plotting:



  const dataYMax = data.reduce(
    (currMax, [_, dataY]) => Math.max(currMax, dataY),
    -Infinity
  );
  const dataYMin = data.reduce(
    (currMin, [_, dataY]) => Math.min(currMin, dataY),
    Infinity
  );
  const dataYRange = dataYMax - dataYMin;

  const numYTicks = 5;

  const barPlotWidth = xAxisLength / data.length;

For dataYMax and dataYMin we need to iterate through the data to calculate the values. This would certainly be a good place to add useMemo and extract into a utility function. Below that we calculate some more values we'll need for our chart.

For the y axis I've added some ticks along the axis:



      {/* Y axis */}
      <line x1={x0} y1={y0} x2={x0} y2={y0 + yAxisLength} stroke="grey" />
      {Array.from({ length: numYTicks }).map((_, index) => {
        const y = y0 + index * (yAxisLength / numYTicks);

        const yValue = Math.round(dataYMax - index * (dataYRange / numYTicks));

        return (
          <g key={index}>
            <line x1={x0} y1={y} x2={x0 - 5} y2={y} stroke="grey" />
            <text x={x0 - 5} y={y + 5} textAnchor="end">
              {yValue}
            </text>
          </g>
        );
      })}
      <text x={x0} y={y0 - 8} textAnchor="middle">
        $
      </text>

Try to think through all of the coordinates in your head to understand how the values of y and yValue are determined, and see if the diagram below helps. You need to keep in mind that the y axis in our plot is bottom to top, but we are plotting the line's y points in a top to bottom system.

The only new element here is g, which is used to group SVG elements. It's also handy for adding a key.

Lastly we have the bar plots themselves:



      {/* Bar plots */}
      {data.map(([day, dataY], index) => {
        const x = x0 + index * barPlotWidth;

        const yRatio = (dataY - dataYMin) / dataYRange;

        const y = y0 + (1 - yRatio) * yAxisLength;
        const height = yRatio * yAxisLength;

        const sidePadding = 10;

        return (
          <g key={index}>
            <rect
              x={x + sidePadding / 2}
              y={y}
              width={barPlotWidth - sidePadding}
              height={height}
            />
            <text x={x + barPlotWidth / 2} y={xAxisY + 16} textAnchor="middle">
              {day}
            </text>
          </g>
        );
      })}

The maths to calculate the right values does get a bit tricky, try working your way through it. I've also added some manual padding between the bars.

Mike Bostock actually has a good post on why D3 is still useful for these kind of calculations. I don't disagree, though personally I would prefer to write the utility functions myself, rather than bringing in more dependencies. But it's really up to you.

We're using the rect element here, which produces a rectangle, and whose properties are conveniently self explanatory. The only thing to keep in mind is the x and y coordinates refer to the top-left corner of the rectangle.

Styling

Open up App.css, and replace the contents with the following to adjust the colours and text size:



text {
  font-size: .7em;
  fill: grey;
}

rect {
  fill: blue;
}

Here I'm using element selectors, but you can add class names to SVG elements exactly the same way you would do to a div. The biggest difference to note is we use fill to change the colour.

What's next?

At this point you may be concerned that you have 100 lines of code to produce a, lets be honest, fairly ugly bar chart. But using just line, text and rect we can already go a long way! Other useful elements to check out are circle and path. These building blocks are enough to produce the most vivid and captivating charts you can imagine.

SVG elements can be animated with CSS just like any other element. In React they also work great in that you can add onClick or onPointerOver attributes to make them interactive. They'll work exactly as you expect.

Tip: sometimes your hover won't work on an element if other elements are laid on top of it. In this case, using an invisible element as the last element can get around this.

Sure, if you just need to plot some data in a generic way then reach for a library. But if you have a specific design in mind (or someone else designed in a mockup), using SVG directly enables you to build exactly what you want, without any compromises.

Quick ref

Here's a quick reference covering the SVG elements you need:

<svg> - wrap all your elements in this
<line> - a line!
<text> - some text!
<rect> - a rectangle!
<g> - group elements together
<circle> - a circle!
<path> - define a shape
and more

TypeScript Gotchas

Ed Bentley — Sat, 14 Mar 2020 11:09:35 +0000

TypeScript can be a great language to work with. If you're starting a new mid to large project in JavaScript, I would certainly recommend using TypeScript at the moment. Knowing your code is correctly typed brings a lot of confidence when it comes to making changes.

However in order to get this great experience, I always have a few "gotchas" in the back of my head while writing TypeScript. These are things to watch out for, which can cause runtime issues if you're not careful.

This can provide us with a "sound" codebase, even though TypeScript is inherintly an "unsound" type system.

These examples have been tested with TypeScript v3.8.3

1. Beware `JSON.parse` and `.json()`

const obj = JSON.parse('{ "x": 5 }');

obj.hello(); // uh-oh! obj.hello is not a function

const data = await fetch("https://pokeapi.co/api/v2/pokemon/1/").then(res => res.json());

data.hello(); // same again!

Here obj and data are returning the type any, even in strict mode, and so TypeScript doesn't warn you about these runtime errors.

Solution: you should decode anything that you don't know the type of. I recommend bringing in a library like io-ts for the job. It's also really useful for query parameters.

2. Beware record types

type MyObj = Record<string, string>;

const myObj: MyObj = {};

const result = myObj.hello;

What's the type of result? TypeScript tells me it's string, but actually it's undefined!

I still find Record to be useful in some cases but you really need to be careful with it. You could also consider using something like fp-ts lookup in order to be extra careful.

3. Beware type assertions

type MyObj = { hello: () => void };

const myObj = {} as MyObj;

myObj.hello(); // uh-oh! myObj.hello is not a function

Just avoid as and angle bracket type assertions as much as you can.

4. Beware `catch`

try {
    throw undefined;
}
catch (e) {
    e.hello(); // uh-oh! Cannot read property 'hello' of undefined
}

Here e has type any so no type errors are reported. Interestingly if you try to annotate e like

catch (e: Error) {

TypeScript won't let you do that which is good. But without it it's still returned as any. 🤷

Watch out for .catch on a Promise too.

5. Don't use `any` or `!`

By now this should go without saying. Using any breaks down the point of bringing in TypeScript and you loose all of your confidence everything is sound and runtime error free.

! can be very convenient but it's best avoided. My only exception is in test code.

Avoid things like this

function lowercaseOptional(val?: string) {
    return val!.toLocaleLowerCase();
}

and prefer explicitly handling the undefined case like this

function lowercaseOptional(val?: string) {
    if (!val) return "";
    return val.toLocaleLowerCase();
}

You can ensure any and ! aren't used by setting up the eslint rules no-explicit-any and no-non-null-assertion.

6. Be careful with libraries!

There are some libraries which served their purpose brilliantly in JavaScript. But in TypeScript, it's simply not feasible to keep using the same API while also keeping your code sound.

This example is taken straight from the lodash doc and converted to TypeScript:

function square(n: number) {
  return n * n;
}

var addSquare = _.flow([_.add, square]);
addSquare(1, 2);

What's the return type of addSquare? any ! 😩

Honourable mention - arrays

const array: string[] = [];
const val = array[1];

TypeScript tells us val is of type string, when really it's undefined. However this is a gotcha in most programming languages, and it really wouldn't be practical to check for optionals in something like a for loop. But it's good to be aware of.

Do you have any more "gotchas" I'm missing? Please share in the comments below!

DEV Community: Ed Bentley

Nix for Frontend Developers

Install Nix

Nix the dabbler

Nix the environment

Nix the package manager

Nix the operating system

Nix the time sink

Nix for Frontend Developers

Introducing Replay: a cross-platform JS game engine inspired by React

Mind-bending functional programming with TypeScript - part 2

1. The impure way:

2. Dependency injection:

3. Effects

Introducing: IO

Add a number

Logging a random number

Mind-bending functional programming with TypeScript - part 1

Build your React charts without a library

Chart Axes

Bar chart

Styling

What's next?

Quick ref

TypeScript Gotchas

1. Beware JSON.parse and .json()

2. Beware record types

3. Beware type assertions

4. Beware catch

5. Don't use any or !

6. Be careful with libraries!

Honourable mention - arrays

1. Beware `JSON.parse` and `.json()`

4. Beware `catch`

5. Don't use `any` or `!`