Forem: Micah Riggan

The story of my longest side-project

Micah Riggan — Thu, 23 Jan 2020 08:51:41 +0000

Making a thing.

This is the story of the past 4 or 5 months, so it'll be long.

I've always wanted to make a thing. A thing people use, and enjoy. Sometimes the struggle is motivation, sometimes the lack of an idea.

Recently I encountered a problem. I was paying $2-15 a month to purchase crypto-currency from Coinbase. It was convenient, but wow, that seems pretty expensive, I thought.

So I have this idea. What if I just make a thing, that connects to an exchange account, where trades are cheaper, and I just buy from there with cash. I'd save hundreds a year! This is August.

Starting

So I make a new folder, run some typical setup scripts and get started. Eventually I get this script that can load my Coinbase balances and trades, and make new trades. I even spend some time making strategies, and a class that can use a strategy to pick a price and place a trade.

The momentum is pretty exciting, so I keep working on it at night time after work. Eventually it's working. Maybe people would use something like this?

I make a frontend, not my strong suit, but I start with something pretty choppy.

Oh making a thing that people can use requires a ton of steps.

Now I need Auth, a login page, a way to configure the different bot settings, a way to securely store the credentials....

The Slump

I've never been good at continuing to work on something past a month or two at home. Usually I made a great deal of progress the first couple of nights and get it to a spot where it does what I need.

Getting a project to a point where you're comfortable telling people about it, and getting users. That's not something I've really done.

The sheer amount of TODO items to get something ready is very scary. Time for a break.

Keep Pushing

I took a break, but I still thought about it. So after about a month, I came back to it, and just started chipping little things away. I come home, I watch a show on Netflix, grab a drink, and code just a little bit on it. Eventually the motivation starts to build again. The list becomes a little bit smaller.

IT WORKS

After two months, by far my longest side project, I get to a state where I can publish the website to an S3 bucket, behind cloudfront, and update a backend which is running multiple node.js services, and people can use it.

So I get close friends to try it. Watching people onboard, you realize you've learned or ignored quite a few little things to make your app work.

Other people don't know not to click there, or how to use it at all really. I learned that my UI was too complicated, and the on-boarding needed an over-haul.

BUT, with help, I could get them up and running. That small group of people trying it, and asking questions really boosted me.

Once I got my first user, I was hooked. I had to fix bugs that were breaking them, or add features they wanted, or improve flows that confused them.

The value of the first user, for me, was huge.

This is October, and now I can avoid those fees.

By now I've realized I've probably spent a few hundred hours over the course of two or three months in order to avoid maybe $500 of fees over the course of the year.

Extend

So I've removed the fees, but what I've always wanted is the ability to manage ALL of my trading in one place. I've been doing recurring buys of stocks too, and I've been doing that manually. Wonder how long that'd take to get Robinhood added to this thing.

The hardest part was the authentication. Once I got that working, it was smooth sailing. Luckily this existed https://github.com/sanko/Robinhood, otherwise I would have had to reverse engineer more.

At the core, the bot level, it took a day. But at the full application level, it took a month.

Going from 0 to 1, is crazy hard. Going from 1 to 2, will show you were your code was flexible enough, and where it wasn't.

The Peak

Once I got the stock trading working, my excitement peaked. Now I can automate all my investing, and I even have some math that picks good prices. I'd been able to test the Coinbase integration for a solid month.

Trades were being suggested daily, and I managed to catch a great dip for ETH from 200ish, while my bot was putting in trades in at 167-170.

A Blur

At this point, I've been working on this thing for 3 or 4 months. It's routine. I don't have a feeling of impending doom, or low motivation when I go to work on it. There's so much to do, but no real friction. (Aside from moving apartments)

I added a ton of stuff, late nights of adding SMS notifications, billing, SoFi, fractional shares, billing. It all blurred together into something that I'm super proud of.

Now I know I'm capable of sticking with a project for longer than a month. I defeated that narrative.

I'm looking forward to seeing where it goes.

Here's a look at what I ended up with

If you're on Coinbase, Robinhood or Sofi and want to try it out

Have you had a long running side-project? How did it go? Have you launched a thing? Let me know in the comments

Javascript Streams vs Generators

Micah Riggan — Thu, 04 Apr 2019 07:02:43 +0000

In javascript we sometimes have to deal with large sets of data that come in asynchronously.

Two tools we can use to do this are streams and generators.

Generators yield data, and continue logic after each yielded item is consumed.

ReadableStreams are the same in that data proceeds to flow as you consume it.

Both of these are great for consuming data as it comes in, and creating flows of data.

In this post, I'd like to show some examples of both of these, side by side, and talk about how to create and consume both forms.

Example 1: Creating and Consuming

In this example we're generating random strings about every 100ms. We'll have a readable stream that we can subscribe to, and a generator that we can iterate over.

We'll call getStream and getGenerator to get these.,

const stream = require('stream');

function getRandomString() {
  return (Math.random() * 16).toString(16)
}

function getStream(time) {
  class TimeStream extends stream.Readable {
    constructor(time) {
      super();
      this.setMaxListeners(100);
      this.streamEnds = Date.now() + time;
    }
    _read(size) {
      setTimeout(() => {
        if(Date.now() < this.streamEnds) {
          this.push(getRandomString());
        } else {
          this.push(null);
        }
      }, 100);
    }
  }
  return new TimeStream(time);
}

function* getGenerator(time) {
  const streamEnds = Date.now() + time;
  while(Date.now() < streamEnds) {
    yield new Promise(resolve => {
      setTimeout(() => {
        resolve(getRandomString());
      }, 100)
    });
  }
}

function testStream() {
  return new Promise(resolve => {
    let i = 0;
    console.time('stream');
    const ds = getStream(1000);
    ds.on('data', (data) => console.log(i++, data.toString()));
    ds.on('end', () => {
      console.log(i++, 'end');
      console.timeEnd('stream')
      resolve();
    });
  });
}

async function testGenerator() {
  let i = 0;
  console.time('generator');
  const generator = getGenerator(1000);
  for(const asyncData of generator) {
    const data = await asyncData;
    console.log(i++, data)
  }
  console.timeEnd('generator');
}

async function main() {
  console.log('Testing stream...');
  await testStream();
  console.log();
  console.log('Testing async generator...');
  await testGenerator();
}

if(require.main === module) {
  main();
}
module.exports = getStream;

Outputs

Testing stream...
0 'e.d244c32e8623'
1 '5.b1684670615e'
2 '7.a3ccc5ad7cd5'
3 '1.30698269b999'
4 'a.0df84371e841'
5 'e.04b9ee941ba'
6 'f.b4e328ecf36f'
7 '2.a3834203577d'
8 'f.472469520bcf'
9 'end'
stream: 1027.421ms

Testing async generator...
0 'c.a0345feebe33'
1 '1.3feb27ad4b78'
2 'e.de0f74e641c4'
3 'b.dc5b66f56322'
4 '1.ec8915a4b07c'
5 '2.d94dde53ff09'
6 'd.e8b57a3b028d'
7 '9.6454bafaf36b'
8 '2.01d0ada9e78a'
9 '7.5142faf39563'
generator: 1034.700ms

From this example, we can see async generators are very small to define.

Generator consumption also fits well with async await and for loops.

We can also see from the output that one of the 100ms iterations was used to close stream by pushing null.

Example 2: Converting a Stream to a Generator

In the last example, we could use a for loop with the generator. In this next example, we'll build an adapter from ReadableStream to Generator. This will allow us to use a for loop on the stream.

We'll have a function called getStreamAdapter which takes in a stream, and yields promises which will resolve when the next item comes on the stream.

const getStream = require('./data-stream');

function* getStreamAdapter(stream) {
  let done = false;
  stream.on('end', d => {done = true})
  while(!done) {
    yield new Promise((resolve, reject) =>{
      stream.once('data', resolve);
      stream.once('end', resolve);
    });
  }
}

async function testDataGenerator() {
  let i = 0;
  console.time('generator');
  const stream = getStream(1000)
  for (const asyncData of getStreamAdapter(stream)) {
    const data = await asyncData;
    if(data) {
      console.log(i++, data.toString());
    }
  }
  console.timeEnd('generator');
}

if(require.main === module) {
  console.log("Creating a async Generator from a Stream");
  testDataGenerator();
}

module.exports = getStreamAdapter;

Outputs

Creating a async Generator from a Stream
0 '6.91038da597eb'
1 '3.ffab4d6c03c4'
2 'c.4d1902e3275f'
3 '3.3b9299bc7c4f'
4 'b.d20e4a03ee2a'
5 '2.9990aca111e6'
6 '5.55a87b7f0c29'
7 '0.a79c544e914d'
8 'e.1cb8d9d24eea'
generator: 1035.196ms

Note, in this example, if we didn't await in the loop, the generator would continue to yield promises. All of those promises would resolve when the next value came in over the stream.

If we tried a typical Promise.all parallelization, we'd end up with an array of the same values.

Example 3: Transform Stream + Transform Generator

Transform streams are one of my favorite uses for streams. In this example I'll try to show the generator equivalent.

For this example we'll create a transform stream that outputs the length of each item as it flows through

We'll also create a generator that consumes another generator and outputs the same thing.

const {Transform} = require('stream');
const getStream = require('./data-stream');
const toGenerator = require('./stream-conversion');

function getLengthTransformStream(stream) {
  return stream.pipe(new Transform({
    objectMode:  true,
    transform: (data, encoding, cb) => {
      cb(null, data.toString().length);
    }
  }));
}

function* getLengthTransformGenerator(generator) {
  for(const item of generator) {
    if(item.then) {
      yield item.then(i => i && i.toString().length);
    } else {
      yield item && item.toString().length;
    }
  }
}
function testTransformStream() {
  return new Promise(resolve => {
    const timedStream = getStream(1000);
    getLengthTransformStream(timedStream)
      .on('error', console.log)
      .on('data', console.log)
      .on('end', resolve);
  });
}

async function testTransformGenerator() {
  const timedGenerator = toGenerator(getStream(1000));
  const lengthGenerator = getLengthTransformGenerator(timedGenerator);
  for(const asyncLength of lengthGenerator) {
    const length = await asyncLength;
    if(length !== undefined) {
      console.log(length);
    }
  }
}

async function main() {
  console.log('Testing TransformStream...');
  await testTransformStream();
  console.log();
  console.log('Testing TransformGenerator...');
  await testTransformGenerator();
}

if(require.main === module) {
  main();
}

Outputs

Testing TransformStream...
14
14
14
14
14
14
14
13
14

Testing TransformGenerator...
13
14
14
14
14
14
14
13
14

Conclusion

Streams and generators are powerful ways of dealing with data as it comes in. If you need something quick that will be consumed by async await and for loops, use a generator. If your code is interfacing with other streams, then use a stream. Pipes and transforms make streams extremely useful together.

Cross posted from my blog

Markdown Blogging with Git + Vim + Hercule

Micah Riggan — Thu, 04 Apr 2019 01:57:33 +0000

I've been enjoying some posts on dev.to about blogging style, so I wanted to briefly write about my dead simple setup that vibes with my coding style.

Dev style

I've a big fan of vim+tmux. I like being able to quickly open terminals, jumping from editor panes to terminal panes and running snippets of code to test them.

I've been a vim person for 3 years now, so that feels like home. I like the splitting, jumping from tab to tab, file to file, buffer to buffer. It feels simple and snappy.

That's how I want blogging to feel, simple, and snappy. This approach is new, and will probably evolve a good bit, but I like it so far.

Blog Goals

Simplicity - I should be able to write a post quickly and have it online without doing very much
Code friendly - I should be able to write technical posts, and run the snippets in my post, so I can be sure they work

Simplicity

My posts are all written as Readme files as markdown, and pushed to my blog repo on github.

When I have post ideas, I create a folder in my todo folder.

If I want that folder to be committed, I'll create a template.md file. More on that later

Deploying is as simple as a git push since I'm using github static pages.

Code Friendly

I want to blog about code, and I don't want to have to copy and paste updates into my posts as I refine the code.

After searching for a bit, I found out you can transclude markdown files with a tool called hercule

Transcluding is like linking, but it takes the contents of a file, and puts it where the link was.

So I can write

    javascript
    : [an example of transcluding] (example.js)

and the contents of example.js will be put inside the javascript code block.

which looks like

console.log('this file was transcluded!');

If this is unclear, feel free to checkout the template.md for this post

Make tools for yourself

So with this in mind, I wrote a quick little script that uses hercule to automatically transclude a file named template.md into a new file named Readme.md

To run this I just type gen readme

So now I can use test snippets, and then transclude them into my Readme file all from the terminal

This testing phase tends to look like the following.

Wrapping it all up

Using hercule is awesome, because now I can break my post into multiple files, and then recombine them.

One interesting usecase I've found for this, is breaking the header into it's own file, and then using it again in my toplevel readme.

Once I've finished my post, I move the folder up a directory, and add a reference to it in the top level template.md file

which looks like

This makes it pretty easy to maintain an index of my posts, with little summaries, which update when I change the corresponding file

Posting to dev.to

After pushing everything up to github, I copy the markdown, and find all relative links, and replace them with absolute links to the github repo.

Now all my pictures and links should work.

Conclusion

You can use hercule to turn your files into components, which can be imported into multiple markdown files. This allows you to write tests against examples, and have your blog posts update as you change source files.

Serial Promises vs Parallel Promises

Micah Riggan — Sat, 30 Mar 2019 14:43:39 +0000

In javascript we often need to do multiple asynchronous things.

I'd like to use this post to show a few examples of doing things serially, and in parallel with promises.

Example 1: "Wait a second" x 3

First example, lets define a function where we "wait a second", three times in a row.

This function will be called serial.

After that, we'll call the "wait a second" function, three times in parallel

This function will be called parallel

function wait(waitTime) {
  return new Promise(resolve => setTimeout(() => {
    console.log(`waited ${waitTime} ms`)
    resolve()
  }, waitTime));
}

async function serial() {
  console.time('serial');
  await wait(1000);
  await wait(1000);
  await wait(1000);
  console.timeEnd('serial');
}

async function parallel() {
  console.time('parallel');
  await Promise.all([
    wait(1000),
    wait(1000),
    wait(1000)
  ])
  console.timeEnd('parallel');
}


async function test() {
  await serial();
  await parallel();
}

test();

Output

waited 1000 ms
waited 1000 ms
waited 1000 ms
serial: 3016.319ms
waited 1000 ms
waited 1000 ms
waited 1000 ms
parallel: 1003.017ms

From the output we can see Promise.all enables us to do all of the "wait a second" calls at the same time.

Example 2: Add two async numbers

In the previous example, we just waited a second. In this example we'll get two numbers asynchronously and add them together, serially and in parallel.

function randomNumber() {
  const rand = Math.random() * 100;
  return new Promise(resolve => setTimeout(() => {
    resolve(rand)
  }, 1000))
}

async function addExampleSerial() {
  console.time('add-serial');
  const number1 = await randomNumber();
  const number2 = await randomNumber();
  const result = number1 + number2;
  console.timeEnd('add-serial');
  console.log('serial result: ', result);
}


async function addExampleParallel() {
  console.time('add-parallel');
  const [number1, number2] = await Promise.all([randomNumber(), randomNumber()]);
  const result = number1 + number2;
  console.timeEnd('add-parallel');
  console.log('parallel result: ', result);
}

async function test() {
  await addExampleSerial();
  await addExampleParallel();
}

test();

Output

add-serial: 2005.019ms
serial result: 59.0316729944722
add-parallel: 1000.616ms
parallel result: 48.7190841367634

Example 3: Required Data Dependencies

In the last example, we had to add numbers which were returned asynchronously, but we still haven't had an example where an asynchronous value is required before another asynchronous value could be retrieved.

In this example, we'll get our username, and then we'll fetch two pieces of information which depend on our username.

function fetchData(data) {
  return new Promise(resolve => setTimeout(() => {
    resolve(data)
  }, 1000))
}

function getLoggedInUser() {
  return fetchData('user1');
}

async function getDataForUser(userName) {
  const profileData = await fetchData({
    user1: {name: 'Micah', points: 100},
    user2: {name: 'someone else', point: 200}
  });
  return profileData[userName];
}

async function getUserPosts(userName) {
  const posts = await fetchData({
    user1: ['Promises Post'],
    user2: ['Streams Post']
  });
  return posts[userName];
}

async function userDataSerial() {
  console.time('userData-serial');
  const userName = await getLoggedInUser();
  const userData = await getDataForUser(userName);
  const userPosts = await getUserPosts(userName);
  console.timeEnd('userData-serial');
}


async function userDataParallel() {
  console.time('userData-parallel');
  const userName = await getLoggedInUser();
  const [userData, userPosts] = await Promise.all([
    getDataForUser(userName),
    getUserPosts(userName)
  ])
  console.timeEnd('userData-parallel');
}

async function test() {
  await userDataSerial();
  await userDataParallel();
}

test();

Output

userData-serial: 3007.785ms
userData-parallel: 2006.665ms

Conclusion

In order to optimize your code for speed, pay attention to which data is required to make calls, and then structure your code to where as many of those dependencies are fetched in parallel as possible with Promise.all()

Note: At some point, you may attempt to do too many async things at once. Now you've got to determine how many you can do, and create batches of that size to prevent thrashing. That's a post for another time.

Kubernetes First Time Project - Auto-Restarting

Micah Riggan — Fri, 29 Mar 2019 13:53:57 +0000

Kubernetes First Time Project - Auto-Restarting

Today I gave kubernetes a shot for the first time. I was interested in it's auto-restart feature, so I wrote a simple node.js program

// application that randomly dies, and see how good kubernetes is at restarting it.
console.time('alive');
setTimeout(() => {
  console.timeEnd('alive');
  process.exit(0);
}, Math.random() * 60000);
setInterval(() => {
 console.log('feels good to be alive') 
}, 100)

I downloaded minikube, and virtual box, and ran

minikube start
minikube dashboard

Then I made a super basic Dockerfile

FROM node
ADD randomly-die.js .
CMD ["node", "randomly-die.js"]

Now we've got to build this Docker image, and then create a deployment with kubernetes

eval $(minikube docker-env)
docker build -t randomly-die:1.0 .
kubectl run randomly-die --image randomly-die:1.0 --image-pull-policy=Never

Now we can check the deployments section of the dashboard and see that we have a deployment named randomly-die

From here we can see we have a replica set, and a single pod, which is running our container

Now if we check the pod logs we can see we're up and running

...
feels good to be alive
feels good to be alive
feels good to be alive
feels good to be alive
feels good to be alive
feels good to be alive
feels good to be alive
feels good to be alive
feels good to be alive
feels good to be alive
alive: 4856.096ms

Scaling

Kubernetes makes it pretty easy to scale up how many containers are running. For my final test I wanted to see it run 10 randomly-die containers, and watch it restart them

kubectl scale deployment --replicas=10 randomly-die
# deployment.extensions "randomly-die" scaled

Conclusion

Now we've got 10 containers running that randomly die, and we can watch the "restarts" counter increment as kubernetes restarts them.

Pretty cool!

Javascript Conditional Properties

Micah Riggan — Thu, 28 Mar 2019 17:42:21 +0000

Did you know you can add properties conditionally to an object with spread?

so instead of

function getUser(banned) {
  const userStatus = {banned, banReason: 'Wizard'};
  // only combine the user status if the user is banned
  const user = { name: 'Micah' };
  if(userStatus.banned) {
    Object.assign(user, userStatus);
  }
   return user;
}


console.log(getUser(true));
console.log(getUser(false));

you can do

function getUser(banned) {
  const userStatus = {banned, banReason: 'Wizard'};
  // only combine the user status if the user is banned
   return {
    name: 'Micah',
    ...userStatus.banned && userStatus,
  }
}


console.log(getUser(true));
console.log(getUser(false));

Outputs

{ name: 'Micah', banned: true, banReason: 'Wizard' }
{ name: 'Micah' }

Neat!

An Introduction to Typescript Generics

Micah Riggan — Wed, 27 Mar 2019 13:41:47 +0000

Typescript is great for developer experience.

You get real-time feedback about the validity of your code, and self documenting code via type-annotations. Also, the auto-complete and jump to definition features are game changing for speed.

In Typescript you write logic in terms of types. Sometimes you need to write logic that is valid for multiple types. One common example is an Array. You can have an Array of any type of thing.

Array<string>
Array<number>
Array<Array<number>>
Array<{name: string}>

This concept is called a template type, or a generic. Here's an example of a linked list type

type LinkedNode<T> = { next: LinkedNode<T> | null, value: T }
type LinkedList<T> = { head: LinkedNode<T> }

In this post I want to show some examples, and contrast the code safety from using "any" versus "templates"

Example 1: Log Obj[key]

In this example, logValue takes and object, and a key of that object. It logs the value associated with the key on that object.

function anyLogValue(obj: any, key: string) {
  console.log(obj[key]);
}

function genericLogValue<T>(obj: T, key: keyof T) {
  console.log(obj[key]);
}

function simpleTest() {
  const Micah = {name: 'Micah'};
  genericLogValue(Micah, "name")
  // genericLogValue(Micah, "age")
  // would not compile because "age" is not a key of Micah
  anyLogValue(Micah, "age");
}

simpleTest();

Outputs

Micah
undefined

The benefit we gain here is if we attempt to log an invalid key, we'll get a compile error.

This prevents typos and other invalid key errors. We can only specify a valid key as the second argument to logValue.

// Example Compile Error
logValue(Micah, "age");

Example 2: Non-Type-Safe Table

In this example we've got two types of data we're dealing with. Person, and Car. We have this BadTable class to help us work with lists of these types as if they were a column row data structure.

See if you can spot the errors you're allowed to create with BadTable

interface Person {
  name: string;
  age: number;
}

interface Car {
  modelName: string;
  year: number;
}

class BadTable {
  rows = new Array<any>()

  addRow(row: any) {
    this.rows.push(row);
  }

  getColumn(col: keyof any) {
    return this.rows.map(r => r[col]);
  }
}
function testBadTable() {
  const people = new BadTable()
  people.addRow({name: 'Micah'});
  people.addRow({name: 'Micah', age: 25});

  const cars = new BadTable();
  cars.addRow({modelName: 'Toyota Something or Other', year: 2010});
  cars.addRow({modelNme: 'Honda Something or Other', year: 2010});
  console.log(cars.getColumn("modelName"));
  console.log(cars.getColumn("year"));
  console.log(cars.getColumn("age")); // [undefined, undefined]
}

testBadTable();

Outputs

[ 'Toyota Something or Other', undefined ]
[ 2010, 2010 ]
[ undefined, undefined ]

Example 3: Stepping towards Generics

In the previous example, we were allowed to make a typo, and also attempt to get a column for keys that aren't on our types.

In this example we'll start moving towards a stronger typed table, that isn't generic. This will create some logic duplication.

In the process of generalization, we need to identify repeated logic, even when it comes to types

export interface Person {
  name: string;
  age: number;
}

export interface Car {
  modelName: string;
  year: number;
}

class PersonTable {
  rows = new Array<Person>();
  addRow(row: Person) {
    this.rows.push(row);
  }
  getColumn(col: keyof Person) {
    return this.rows.map(r => r[col]);
  }
}


class CarTable {
  rows = new Array<Car>();
  addRow(row: Car) {
    this.rows.push(row);
  }
  getColumn(col: keyof Car) {
    return this.rows.map(r => r[col]);
  }
}

function testTables() {
  const people = new PersonTable()
  //people.addRow({name: 'Micah'});
  people.addRow({name: 'Micah', age: 25});

  const cars = new CarTable();
  cars.addRow({modelName: 'Toyota Something or Other', year: 2010});
  //cars.addRow({modelNme: 'Honda Something or Other', year: 2010});
  cars.getColumn("modelName");
  cars.getColumn("year");
  //cars.getColumn("age");
}

testTables();

Example 4: Learning about Generics

In our previous example we can see we had to implement a new Table per type in order to retain type safety.

This duplication should be a signal that we can generalize.

Generics!

In typescript you can create a generic class, which allows you to pass types in as variables!

class MyClass<TypeVar> {
  myProp: TypeVar;
}
type GenericType<TypeVar> = TypeVar & {modified: boolean}
function genericFn<TypeVar>(arg: TypeVar) {}

Now that we have the ability to define type variables, lets revise our duplicated classes

Generic Table

import { Person, Car } from "./3-generalization-step-1";

class Table<RowType> {
  rows = new Array<RowType>();

  addRow(row: RowType) {
    this.rows.push(row);
  }

  getColumn(col: keyof RowType) {
    return this.rows.map(r => r[col]);
  }
}

function testTable() {
  const people = new Table<Person>()
  people.addRow({name: 'Micah', age: 25});

  const cars = new Table<Car>();
  cars.addRow({modelName: 'Toyota Something or Other', year: 2010});
  cars.getColumn("modelName");
  cars.getColumn("year");
}

testTable();

Conclusion

Types help prevent common bugs.

By using generics<T> we can define functions, classes, or types which work with variable types.
This allows us to write logic that holds for many types.

To generalize code, we need to identify repeated logic, even when it comes to types.

{Destructuring} = JavaScript

Micah Riggan — Tue, 26 Mar 2019 14:05:54 +0000

Destructuring is great for referencing pieces of objects or arrays. I find it to be very useful, and fun.

If you're writing code like

var thing = array[0];
var otherThing = array[1];

var name = thing.name;
var age = thing.age;
var height = thing.height;
var userId = thing.id;

Then you've come to the right place.

In this post I'll show some common uses of destructuring that simplify the above examples, and more.

Example 1: Destructuring Arrays

Here are some common array destructuring patterns :

Get the first element of an array
Get the first element, and the rest of the elements
Get the name property from the first element of the array
Get the name property and then assign it to a variable called firstName
Get the second element from the array

Outputs

{ name: 'Bob' }
[ { name: 'Sam' }, { name: 'Tom' } ]
Bob
Bob
{ name: 'Sam' }

Example 2: Destructuring Objects

Here are some common object destructuring patterns

Get the title property of an object
Get the title and pages property of an object
Get the height property off an object, and name it bookHeight
Get the ISBN property, which will default to '0000000'
Get the title property, and everything else collected into a variable named rest

Outputs

A book title
{ title: 'A book title', pages: 55 }
100
0000000
{ pages: 55, height: 100, weight: 2, price: 3.5 }

Example 3: Destructuring Parameters

In this example we've got some common destructuring patterns for function parameters

Capturing many arguments in an array
Getting the name property of an object
Getting the first element of an array, and the remainder of the array
Unpacking an array into a new array, with a new element at the end

Outputs

[ 'Hello', 'World' ]
Micah
[ 'Second', 'Third' ]
[ 'First', 'Second' ]

Conclusion

If you haven't been using destructuring, you should try it out. It's a great way to boil objects down into what you need. If you've got a favorite destructure that I didn't cover, put it down in the comments