Rendering folder trees in React

Over the past ~2 years of building web UIs in React, I’ve found myself turning back to this One Weird Trick when it comes to dealing with nested folder trees (or similar problems). I put together a little example to use as a starting point.

The end result is embedded below and the code is here.

I’ll dive into some of the reasoning below.

Keeping recursion separate

With a nested structure like this, it’s common to use recursive logic to dig through the children. You might use recursion to render the expanded tree, find a folder by ID, or update a folder’s data in memory. These operations can be complex, heavy, and not the most readable in code, so it would be nice to keep the touch-points with complex recursive logic as tidy as possible.

Take rendering, for example. One approach would be to do the recursion straight in the render(). Maybe you could define a component that would render a folder and its children recursively, sorta like this:

This totally works, and looks pretty nice, but I actually prefer a different approach.

Whenever possible, it’s nice to avoid having complicated logic tied up directly in rendering. In the example above, the recursive logic is simple, but in a real world application it could grow in complexity fast. If you need to reuse the folder tree or present it in a slightly different way, you’re forced to either use the existing component (maybe going in and adding some options in that component to support different UI needs, which could turn unwieldy) or create a new component, in which case you’d have to rewrite the recursive logic to deal with the nested structure.

Also, by recursing through the entire tree every time render() is invoked, you could be making it harder on yourself to keep performance in check. Is it ever possible you’d want to re-render without recursing through the whole tree? Perhaps, but it’s hard to explore those options when they’re so tied up in each other. This actually isn’t a huge deal (no need for premature optimization), and there are different ways to solve this problem. But keeping the recursion totally separate from the render eliminates this problem altogether and gives you more control over when and how often the most complicated logic is being executed.

Flattening the tree to prepare for rendering

I’ve grown to really like the approach of processing the nested data structure before rendering. If you flatten the tree, calculating and storing all necessary data for display, rendering becomes as simple as:

In the example I’ve linked at the top of this post, the flattening function calculates and stores two extra pieces of data along with the given folder data.

1. Indent level

If we want to represent a folder tree with a flat array, we need to know what level deep the folders are so we can display them with an appropriate indent.

2. Path to folder

Keeping track of the path to the corresponding folder in the nested or “true” tree data makes lookup quick and easy later on.

Here’s an example of the data representing a nested folder tree:

And the resulting “flattened” data:

Pulling out the recursion into a separate, pure function to create a flat, dumb structure has a lot of benefits. We are in complete control of when we perform the most expensive operations in the component. We only have to recurse when we deem it necessary. It means our render()s don’t have to be quite as smart. It simplifies the process of creating different UIs to present the data in different ways.

Check out the code! (ノ◕ヮ◕)ノ*:・゚✧

Adventures with the Planck keyboard

FullSizeRender 14

I finally got my hands on a Planck keyboard!

The Planck is a funny little 40% mechanical keyboard with an “ortholinear” layout (the keys are aligned horizontally and vertically rather than being staggered). It’s DIY, fully programmable, and, most importantly of course, really cute.

The main consideration with a keyboard so small is there simply aren’t enough keys to represent every possible input, so you need to use layers. On the typical Planck, the two keys to the left and right of the spacebar are function keys for “lowering” and “raising” the active layer (the orange buttons in the image below).

5a129uawmycx

It takes a little getting used to, but the benefit is that everything is right at your fingertips so you hardly have to move your hands or wrists at all. And in fact, I’ve been surprised by how easy it is to use the layers since the raise/lower keys are right at my thumbs. It’s way more convenient than using shift or control keys.

I decided to get one because I was interested in

  1. Less wrist movement while typing
  2. A keyboard that looks really tiny and cool!!! c’mon.
  3. A fun project to assemble and program.

My Planck is made up of:

Now I’ve been typing on it for about two days, and so far I’ve been surprised at how much I enjoy the layout. Typing while keeping my hands on the home row is super satisfying, and the ability to program it means I can really hone in on what I want out of it. Time will tell, but it’s already well on its way to becoming my daily driver.

Kits have been available on Massdrop in the past, but right now you can buy parts for the Planck from olkb.com. Assembly is simple enough: set the top plate on the PCB, place the switches and solder them into place, then screw it into the case.

The fun part, in my opinion, is programming it with your own custom keymap. There are lots of instructions in various READMEs in the QMK Firmware repo, which is used to program all kinds of keyboards on all kinds of platforms, but here are some simple instructions specifically for Mac OS X:

  1. Install some things with Homebrew. avr-libc is a library for microcontrollers, and dfu is a command line utility for the actual programming.
  2. Clone the QMK Firmware git repo.
  3. Navigate into the project’s Planck keymaps directory, /keyboards/planck/keymaps.
  4. Copy the default keymap directory to a new directory called whatever name you want for your custom keymap.
  5. Open mynewkeymap/keymap.c in a text editor and take a look around. It should be pretty self-explanatory. Here’s a list of the keycodes you can use. Make whatever changes you want, then save.
  6. Navigate back to the /keyboards/planck directory and run:
  7. With a pin, push the reset button on the bottom of the keyboard. Then run:

Here’s my current layout, along with the keymap.c file in my fork of qmk_firmware. The legends in the middle are the main layer, the top legends represent the “raise” layer, and the bottom legends represent the “lower” layer.

Screen Shot 2016-11-14 at 2.02.46 PM

It’s basically the default layout with a few changes. The parentheses, curly braces, and brackets are in the upper layer on the home row since I use them so much writing code. My control key is by my left pinky for shortcuts in the terminal, and Esc is on the same key in the lower layer for Vim.

We’ll see how long I last before I decide I need another Planck to use at home 🙂

A nice terminal + Vim setup for OS X

A few months ago, I switched to a Terminal & Vim development environment.

I could talk about how awesome Vim is, how it’s changed my life and solved all my problems and purified all my toxins. But this post isn’t about preaching the Gospel of Vim. I just want to document my first real terminal setup.

Even though I’ve been “using the terminal” for years, I never spent a lot of time making it a nice place to be because it wasn’t the foundation of my development environment. Of course, that changed when I became A Vim User.

I’m not someone who lives for configuring things, but (with lots of guidance) I eventually ended up with something I think is pretty nice. Here’s a screenshot:

Screen Shot 2016-11-04 at 10.01.47 AM (3)

Contents:

Terminal

First things first: figure out which terminal to use. There are a few options other than your system terminal. I think the two most compelling are:

  • iTerm2 — very popular among terminal power users.
  • hyperTerm — built on Electron using HTML/JS/CSS, which makes customizing it really accessible to web developers.

I tried these and others, and even used iTerm for the first two weeks of my setup, but I ended up going back to the OS X system terminal — Terminal.app — and I have no regrets.

  • It’s lightweight, performant, and basically bug-free.
  • It handles programming ligatures better than any other terminal I’ve tried. (This isn’t really a big deal, but I like them. More on those later.)

Note that Terminal.app only supports 256 colors. iTerm and hyperTerm have 24-bit color and lots of other cool features, but they just didn’t outweigh those two factors for me.

Vim

Vim is the reason I switched to a terminal-based dev environment in the first place. It’s an old-school text editor that uses keyboard commands to navigate and manipulate text. If you’re a “power-user” of any software ever, you already understand the advantage of keyboard shortcuts (once they’re in your muscle memory, of course), and using Vim takes that to the extreme.

Vim has changed my editing process from

Reach for mouse. Click. Reach for keyboard. Type.

to

Type. Type. Type. Type.

It’s simple and customizable, it never freezes, and it gets out of my way. More so than any other editor, it makes me feel like the computer is an extension of my brain.

If you think Vim users are just hipster neckbeards, I feel ya, but don’t totally discount it until you try it as your daily driver for at least a week or two. If being a hipster neckbeard is wrong, then I don’t want to be right.

To start out, open your terminal and type vimtutor. Spending 15-30 minutes a day on this for about a week will be a good primer. After you’re familiar with the basics, I recommend just going cold turkey. It’ll suck the first few days, but after two weeks, I reckon you’ll be the slickest text wrangler this side of the Mississippi. (I’m sorry for saying it like that.)

Vim is crazy powerful and flexible. You could learn a new command a day for years and still not know everything. It’s easy to get overwhelmed. Just know you can start out with the basics and still be productive, and add special commands to your workflow over time (the fun part). There are lots of resources for Vim commands, but here’s my cheat sheet. It’s obviously not exhaustive, but it covers most of the basics as well as a few handy commands I took note of in my first week or so.

Neovim

“the future of vim.” This adds some nice stuff to Vim. It’ll make it feel a bit more user-friendly by introducing some modern interactions like being able to scroll or change the split pane size with your mouse. Install it with homebrew (oh, and get homebrew if you haven’t already!)

Vim Configuration

Vim can be endlessly configured. As a True Vim User, your .vimrc is something that should be carefully curated line-by-line, cherished, passed down from generation to generation, and eventually engraved on your tombstone.

You can start out by enlisting the help of someone else’s dotfiles. Lots of people share them on GitHub. Here’s what I use: cp-dotfiles.

It’s lightweight but comes with some really handy things that are now essential to my workflow. Even if you don’t use the same repo, these settings can of course be added to your own configuration independently. (check out the settings folder, and also Vundle, a Vim plugin manager.)

  • NERDtree: file tree inside vim. use ctrl+\ to open it up and jump to the currently open file
  • fuzzy finder (ctrlp): find and open files quickly by typing “,t”
  • deoplete: autocomplete. options pop up as you type, use ctrl+n to choose from the options
  • silver searcher: search the content of all your files by typing “,ag” (get it? like the chemical symbol for silver?)
  • colorizer: highlights the text of hex/rgb colors with the color they define
  • tmux navigation: use ctrl+h/j/k/l to navigate between tmux panes (more on tmux later)
  • syntastic: uses your linting utility of choice (defaults to eslint) to give you helpful messages every time you save a file

If you have a friend or teammate who uses Vim, ask them for recommendations. Most importantly, don’t worry too much about getting your configuration 100% perfect the first time. Start with the basics, and over time you’ll add your own settings and tools as you discover annoying or inconvenient things in your process.

zsh

A nice shell. You won’t have to learn anything new coming from bash, but you’ll get more customizable prompts, better autocomplete, and some other handy things. Install it, then you’ll want to pick a prompt theme. Check your available prompt themes with prompt -l, then choose one with prompt promptname. I like smiley or cloud. Nice and simple with handy git info when you’re inside a git directory.

If you want to really dig in and customize your prompt further, go check out ~/.zprezto/modules/prompt/functions, duplicate the one you want, give it a new name, and hack away. Remember you’ll need to reopen a terminal session to see the new prompt in your options.

I’ve also heard really good things about fish shell, but I haven’t gotten around to trying it out myself yet.

tmux

Tmux lets you split your terminal into panes and run multiple sessions (think tabs).

I usually have a session open for each project, where each session has a large pane on the top for Vim, and two or three small panes on the bottom for doing git stuff, running tests, running servers, watching/building, etc. You can rename each session so it’s really easy to get where you need to go.

There are a bunch of commands to manage your tmux panes. All the shortcuts I use are at the bottom of my cheatsheet.

Colors

Colors are important. When first switching from Atom, I was really annoyed that my Vim/terminal colors looked like garbage when Atom has such a pretty default colorscheme. But we can fix it!

First, we’ll need to make sure that everything is set up for 256 colors (not 24-bit, since Terminal.app doesn’t support that).

  • In your Terminal.app preferences, go into your default profile, and make sure the setting under “advanced” is declared as “xterm-256color”. [screenshot]
  • Make sure you don’t have anything in your .vimrc that enables 24 bit color or “true color”. Look for true or tc or anything like that. If you find something, remove/comment it. You might have this if you’ve installed neovim.
  • Same thing with tmux. Check your .tmux.conf for the line that looks like set -g terminal-overrides ",xterm-256color:Tc", remove/comment it, and add set -g default-terminal screen-256color.
  • You might not need to do this, but just in case, I recommend adding the line set background=dark in your .vimrc. (Or light, but I’m gonna just assume you want a dark theme…???)

Now you’re ready to try out some colorschemes. Here are some of my favorites to get you started: brogrammer (pictured in the screenshot above), hybrid, apprentice, sierra, tender. You can find more at vimcolors.com and really go crazy if you want.

To install the “hybrid” colorscheme, for example, copy the hybrid.vim file into ~/.vim/colors, then try it out by opening a file in vim and typing :colorscheme hybrid. If you decide you like it and want it to be your default colorscheme, add a line with :colorscheme hybrid to the bottom of your .vimrc.

Bonus: getting terminal colors to match Vim colors

Terminal colors are configured in the Terminal.app profile preferences under “Background” and “ANSI Colors”. Some color schemes come with terminal colors you can download and use, but it’s also really easy (and worth it) to get your terminal to match all by yourself: there’s a color picker which you can use to grab colors straight from your code.

If this seems like too much work, just use one of the pre-loaded profiles, and maybe just change the background color to match your Vim background color.

Font

You can choose your font, size, and weight under your Terminal.app profile settings.

Some fonts include programming ligatures to make programming operators pretty. This is totally optional and a matter of personal taste. According to my personal taste, ligatures are the best. Download and install the font Fira Code and enable it under your Terminal profile settings.

Open a file in Vim and type in some programming symbols like !== or =>Hellooooooo handsome.

ezgif.com-crop

Caps lock

I don’t know who decided to put the most useless key in such a prime spot on the keyboard, but let’s remap it because you’ve probably never purposely caps-lock‘d in your entire life.

The options are endless (well not literally but, y’know, there are a lot of options). I think these two make the most sense:

  1. Remap the caps lock key to escape. This is one of the most commonly used keys in Vim so it makes sense. Unless you have a reprogrammable keyboard, you’ll need third-party software to do this, like Seil.
  2. Remap the caps lock key to control. You can use ctrl+[ as your escape, plus you get a handier control key for all your other commands. You can do this in your OS X system preferences under the keyboard settings.

It just comes down to personal preference. I chose option 2, as have most of my Vim-using teammates.

The End

Well, we’ve done it. We’ve reached Terminal Nirvana. Now we can relax and enjoy our hard work by getting some work done.

Building a Search Box with RxJS Observables + the Fetch API

Just looking for code? jsfiddle here.

Solving complicated asynchronous problems in JavaScript can be A Hard Thing. The moment you stray beyond the most basic callbacks, it’s easy to fall into tangly, brittle code that’s hard to wrap your head around. This state is often fondly referred to by JS devs as “callback hell”.

There are tons of strategies out there to handle async stuff cleanly, and over the past couple of years, I’ve grown comfortable with Promises as my go-to. But recently I’ve been dipping my toes into more “Reactive” strategies with RxJS, specifically its Observables, and with that mental shift has come a really powerful and expressive tool I’m glad I added to my belt.

In this post we’ll build a simple example using RxJS Observables and the Fetch API: a search box. As the user types, it will retrieve and display relevant search results from the network.

First, a quick note on the Fetch API

The Fetch API is a new way to make network requests from the browser. It uses Promises. It’s supported in all major browsers but still in beta, so you’ll want polyfills if you want to use it IRL. If you’re not familiar with Fetch, here’s a basic example:

Notice there are two then()s. That’s because we’re dealing with two “layers” of Promises here. The first one makes the request, and the second one parses the response body (in our case, as JSON). This is a simplified explanation. For more reading on Fetch, look here and here and here.

Ok, let’s build a search box!

A naïve approach

A simple (but buggy) approach might look something like this. Every time the user types a character in the search input, we retrieve new search results. On then(), we add the results to the DOM for display.

Simple enough, yeah? …can you see the problem yet?

The network is reliable, probably

Network requests are unpredictable; you can’t control how long they take to return. As the user types, the requests (for “f”, “fo”, “foo”, etc.) are made in the correct order, but the order they return is based on network timing. Whichever request takes longest to return is the one that gets displayed. Womp womp.

You could debounce or throttle the search, and that would help, but that solution would still depend on somewhat consistent network request timing. Can we find a watertight way to ensure that search results for only the latest keystroke will appear, while avoiding callback hell?

RxJS Observables: cool & composable

Observables are streams of data that “emit” items asynchronously, and anyone who cares can “subscribe” to them to hear about these pieces of data and react to them however they want.

I actually like to use the word “stream” in place of “Observable” when thinking about these problems. This might be an oversimplification, but for newbies like me, I think it’s a fine way to conceptualize it. RxJS Observables behave a lot like any other iterable; they can be filtered and mapped and composed in all kinds of ways.

This search box is a perfect candidate for the Observable pattern. There’s a stream of events (keystrokes) we care about and want to respond to in a specific way. So let’s Observable-ify this thing in three steps.

1. Create an observable stream

We start by creating an Observable from the keyup events on the search input. This is a stream that will emit all of these keyup events.

To do this, we use fromEvent(), which is just one of many ways to transform an existing stream-like object into an Observable. All sorts of other stuff can be turned into Observables, too, like arrays/iterablespromises, and callbacks.

2. Manipulate the stream

Then we add some operators to manipulate the stream. Our main goals are to:

  1. filter out the emitted items we don’t care about
  2. transform them into network requests and responses

Like I mentioned, it’s conceptually a lot like manipulating an array: filter it, map it, reduce it. RxJS provides a lot of useful ways to do this.

map(), debounce(), and distinctUntilChanged() are fairly easy to understand, but I want to go into more detail about the other two operators.

  • flatMap() “flattens” or combines items from many streams into one stream. You’ll see in the RxJS docs that a “stream” in this context can be an Observable, Promise, or iterable. After all, a Promise is just a stream with one item (the resolve value).
  • flatMapLatest() does the same thing, but with a twist: it filters out everything but the latest emitted item. So the moment it sees a new item (keyup event), it cancels any previous ones so those Promises won’t even get passed along. Cancellation is a very nice feature of Observables and is exactly what we need to avoid that race condition in the naïve solution.

flatMap is probably the trickiest concept in this whole post, so let’s review the process of how a search term gets mapped to search results.

  1. For each search term, create a Promise that makes a network request for the search results.
  2. Combine the responses from each of those Promises into a single stream.
  3. For each response in the stream, create another Promise that parses the response body as JSON. (remember how Fetch has two “layers” of Promises?)
  4. Combine those responses (the parsed bodies) into a single stream.

So, in just 6 lines of code, we’re fine-tuning our event handling in some really complex ways. See what I mean about expressive?

3. Subscribe & react to the stream

Finally, we subscribe to searchStream, which will emit the search results we’re interested in displaying.

subscribe() takes a function that handles the emitted items. It also takes other functions for error handling and completion, but I’m leaving those out here for simplicity’s sake.

All together now

See it in action in this jsfiddle.

And… that’s it!

Putting together this small example has helped me better understand how to use RxJS Observables and how cool they are, and I’ve since found all kinds of ways to use them to my advantage.

If you’re new to RxJS like me and want to learn more, I like this and this as a starting point.

P.S…

Check out this jsfiddle to confirm that flatMapLatest() solves the race condition in the naïve example above. It’s artificially slowing down Promise resolves to force the race condition. If you open up the console and watch the logs as you type, you’ll see that the correct response is displayed even though requests made earlier are returned later. That’s flatMapLatest() in action. You can guess what happens if you change flatMapLatest() to plain old flatMap().