Promising Design Patterns

I talked to someone this evening about what I know and what I don’t know as far as web dev, React, JavaScript, and the like.

And I had to admit a couple of things, right then and there:

  1. I only have a vague sense of what promises are (in JavaScript! in life, I’m good at keeping them).
  2. I can visualize what algorithms and design patterns are, but I have no idea if I know any of them offhand.

So I figured: why not learn something tonight?

And then I can post it! Bonus!


The thing that I knew, in the moment (probably due to the name? It’s right there on the tin): promises are a way to deal with asynchronicity.

In plain english: Once this other thing is done, then do this thing.

In fact, it literally uses then to make the promise. What could be more readable?

This isn’t the only way to do this (see also: callbacks), but it does remove some complexity, in favor of more readable code.

On that linked example, I feel like the single-use guarantee” portion is super important:

A promise only ever has one of three states at any given time:

A pending promise can only ever lead to either a fulfilled state or a rejected state once and only once, which can avoid some pretty complex error scenarios.

For the next post in that linked tutorial the author shows how to use promises in order to implement the fetch() api. It makes so much sense, and is so readable:

  .then(resp => resp.json())
  .then(resp => {
    const currentTime = resp.dateString;

Even for someone who’s new to Promises, this makes so much sense. Give me the response, turn it into JSON, and use it to set the current time.

Woop! We just learned about promises.

As far as algorithms and design patterns? Those are less of a quick study. I did, however, find a pretty good React-oriented design patters site here:

React Patterns

I even saw some that I use all the time, like the spread operator in JSX and Style Components, or have learned about already, like Event Switches. Some of this feels like unknown knowns,” as it were.

I’ve definitely got some more resources to add the list now — I’m glad I had this convo today, and took the opportunity to learn a bit more. Bit by bit, bird by bird. That’s all we can do!

14/11/2019 · learning · coding · javascript · design patterns


I’m definitely a visual thinker/learner (close second to audio learning style), and I also love to map a thing out ahead of time so I don’t have to track it in my brain.

Sometimes that means that if I’m breaking things down into components that I make some wireframe-y sketches! to Here’s a couple of examples of how that looks, from a thing I worked on this weekend:

two-page notebook spread with wireframe sketches done in ink single notebook spread with wireframe sketches done in ink

Bonus: I get to use my fancy fountain pens!

10/6/2019 · process · front-end · sketching

Whoa ImageMagick!

Holy whoa this is cool: by using ImageMagick’s command line interface, you can combine images using terminal commands like:

convert +append a.png b.jpg c.tif

This is super cool if you don’t feel like fussing a ton with, or worse, launching Photoshop, etc., OR if you need to convert to a different image type (note the different extensions, above).

I used it today becaue I had a few screenshots I wanted to combine and markup for posting in an pull request. Instead of having to do all that manually, I did this:

convert +append form1.png form2.png form3.png form-all.png

…and then marked up the new image (which was form-all.png) by just by hitting spacebar in Finder and using Markup.

Easy Peasy!

I learned about ImageMagick by Googling combine three images preview mac osx which led me to StackExchange).

I installed it with brew install imagemagick; this led to an error message (Permission denied @ dir_s_mkdir - /usr/local/Frameworks), which was resolved by Googling the Error message, which took me here.

Just a small glimpse into the way that anything involving web dev is time consuming. 😀

Happy combining!

28/5/2019 · errors · command line · quick tutorial · tools

Literally speaking

Yesterday I put in a pull request for the framework that we use at work. It was related to an issue I’d submitted; namely, that I wanted to be able to send folks style guide links to specific variants of components we build.

Building this had a lot of codey type things in it:

// for permalinks to examples
const exampleName =;
const exampleNameNoSpace = exampleName.replace(/\s+/g, '');
const exampleLink = `#${exampleNameNoSpace}`;

However, I did it!

You see, when you look up examples for using these sorts of expressions, programmers like to use variables (like str for string) that feel like they mean more than they do. So many examples used str.replace(/\s+/g that I thought it meant something important. Nope! This was just convention, used by many folks, but not necessary.

And hey, it worked!

One of the main things I had to figure out is how .jsx — combined with the linting we use — would want me to combine the # needed for an anchor link on the same page with the exampleNameNoSpace variable I’d created above it.

These are template literals,” and though I could have concatenated the two parts, ESLint wasn’t having it. The cool thing is that the linter’s warning taught me a new thing I needed to know.

So yeah! That’s what I learned yesterday. How bout you?

31/1/2019 · learning · coding

Hello, World!

This thing looks pretty swell. Let’s see how it goes!

27/12/2017 · hello

View the archives