
Everything is changing again, as it tends to do often.

### Moving to a house

At the beginning of the summer, I was 3 months into working and living at out of a 1 bedroom apartment with my partner, who was at the time out of work. Because of the pandemic, and all of the "stay-at-home" orders in Seattle, that's tight quarters to be spending most of your time. That apartment had an open kitchen, a bathroom and a bedroom. I'd primarily been working in the kitchen and it's hard to share that space when you're working 12 hour days, half in Zoom calls and the other half divided between triaging JIRA tickets and actually coding.

<div class="ImageGrid-4x4">
  <img src="/images/posts/old-apartment-wine.jpg">
  <img src="/images/posts/old-apartment-wfh.jpg">
  <img src="/images/posts/old-apartment-moving-in.jpg">
  <img src="/images/posts/old-apartment-flowers.jpg">
</div>

As much as we loved living in the city, we had to admit, this wasn't the same city anymore and our daily rhythms weren't suited for such a small place. So Sabrina and I moved down to a huge place in Kent, not too far from the commuter train but far enough that I don't have to hear it.

Now, I'm not in love with Kent but I certainly love And I setup a better office for myself. Gotta say, I love working out of here and having my own space that can just be mine is just affirming in ways I can't describe.

<div class="ImageGrid-3x3">
  <img src="/images/posts/office-chair.jpg" />
  <img src="/images/posts/office-desk.jpg" />
  <img src="/images/posts/office-deskchair.jpg" />
  <img src="/images/posts/office-dual-monitors.jpg" />
  <img src="/images/posts/office-fridge.jpg" />
  <img src="/images/posts/office-profile.jpg" />
</div>

### Back to Microsoft

<figure class="Post__figure--left">
  <img src="/images/posts/surface-equipment.jpg" alt="Pot of tea in front of bookshelf">
  <figcaption>Honestly didn't think I'd ever buy a Surface product</figcaption>
</figure>

After working at my last engagement for a year, I got the opportunity to go back to Microsoft and now I'm working with the Xbox team on A/B testing with React and TypeScript.

I was at Microsoft for most of 2018 and [2019](https://charlespeters.net/writing/twenty-nineteen#work-transition) and I'm really excited to be back. I always feel like I'm growing in someway at Microsoft more than any other engagement I've been on.

One really awesome part is being able to dive back into use React Native again for the first time in like 4 years. Microsoft has their own port of React Native that targets Windows 10 SDK, you can run React on UWP apps, Xbox, pretty much anything running Windows 10.

### New Gender

In the midst of all of this and having more time to slow down and think during lockdown, I started to ask some questions about gender and how I understand myself and where or if I fit on the gender spectrum. Started to come to the conclusion I don't identify with the gender binary. Not him or her, just them.

People come out to be seen and understood as something different than the conception they have or present to others. I'm non-binary and I'm using [they/them](http://pronoun.is/they/.../themselves) pronouns. I went into a little more detail on [Twitter](https://twitter.com/charlespeters/status/1277690247359246341?s=19).

---

Anyway, that's all for now. Hopefully I feel like I can blog more in the future. ☕


Transitions


A common interview questions is: What the difference is between `function.call()` and `function.apply()`? I didn't really know the answer to this one and if you read the docs from [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/call), it's not super clear how either of those is different from normally invoking a function.

### Invoking a Function

Let's use this function as an example:

```js
function someFn() {
  console.log("Something");
}

function someFnWithArgs(name) {
  console.log("Hello from this demo function, ", name);
}
```

Typically you'd invoke a function like this:

```js
someFn();
// Logs "Something"

// We pass a parameter to the function to represent "name".
someFnWithArgs("Charles");
// Logs "Hello from this demo function, ", "Charles"
```

### Other Invocation Methods

One of the hardest things to understand in JavaScript is `this`. `this` is the context of a given scope. If you call `this` outside of a function, you're referencing the window object (provided you're running this in a browser).

```js
console.log(this);

// Window {parent: Window, opener: null, top: Window, length: 4, frames: Window, …}
```

Functions can create a new scope and then `this` refers to the scope it's now in:

```js
function createElement(textContent) {
  const element = document.createElement(this.elementName || "div");
  element.textContent = textContent;

  return element;
}

createElement("Calm down");

// <div>Calm down</div>
```

If we invoked this function normally. We'd return a `<div>` element, but maybe we want to call this function with a different version of `this`. We can pass a new version of `this` through `createElement.call()` and `createElement.apply()`.

```js
createElement.call({ elementName: "h1" }, "Title");
// <h1>Title</h1>

createElement.apply({ elementName: "h1" }, ["Another Title"]);
// <h1>Another Title</h1>
```

This is the main feature of `function.call()` and `function.apply()`: to redefine the function's context (`this`).

### The Difference between `.call()` and `.apply()`

The difference between these methods is how you pass parameters to the function, one takes them comma separated like the normal invokation and the other through an array. People on [StackOverflow](https://stackoverflow.com/questions/1986896/what-is-the-difference-between-call-and-apply) have commented that you can remember the different by remembering **C** for comma and for `call()` because it takes it's arguments comma separated and **A** for array and for `apply()` because it takes it's arguments as an array.

Normal invokation will always be faster to process than `call()` or `apply()`; `call()` tends to perform better under stress tests and than `apply()`, you can see those performance tests [here](https://jsperf.com/function-calls-direct-vs-apply-vs-call-vs-bind/6).

### Binding

Now let's say instead of giving a function a new context (`this`) and invoking it, you need to only give the function a new context and call it later. This is the use case for `function.bind()`.

```js
const titleCreator = createElement.bind({ elementName: "h1" });

titleCreator("Hello");
// <h1>Hello</h1>
```

Here our `titleCreator` is now bound to that new version of `this`, so every time we call it, we have that same `elementName`.

---

One great reference I come across a lot on this topic is [_Understanding This, Bind, Call, and Apply in JavaScript_](https://www.taniarascia.com/this-bind-call-apply-javascript/) from Tania Rascia. It goes more in-depth into understand `this` and how it applies to all these other methods.


Call vs Apply


I prefer `useReducer` to `useState` when I'm using React, it gives us a declarative (and as you'll see, strongly typed) way of defining our next state after an update. With `useReducer()` we have a tuple of state and how to update that state, the dispatch:

```ts
const [state, dispatch] = React.useReducer(reducer, initialState);
```

We have two concepts here: the **state**, a snapshot of what should be rendering inside your component and the **dispatch**, a way of describing how to update that state.

If you create a reducer function, you're going to need to create a pure function, meaning there's a single input and derived output, that returns your next state. When you add type annotations for your state object that's pretty clear most of the time, it's what you want the out to be each time:

```ts
interface IState {
  someKey: string;
}

function reducer(state: IState, action): IState {
  // return some state that satisfies that interface
  return { someKey: "..." };
}
```

Now there's some type safety, our compiler will warn when you're not returning that value that's an object that matches that interface. But adding type annotations to the second parameter `action` can get a little wild. Action is what we pass to the dispatch to update the state.

```ts
dispatch("foo");

// Then when the reducer is called
reducer(currentState, "foo");
```

You can pass anything, the pattern I've most often used is a switch statement and passing a `{ type: 'ActionName' }`. When we create our reducer function we can call it a `React.Reducer`:

```tsx
const reducer: React.Reducer<State, Action> = () => {};
```

We can pass generics to the reducer to describe the state and action.

```tsx
interface IState {
  someKey: string;
}

interface IAction {
  type: string;
  payload?: any;
}

type MyReducer = React.Reducer<IState, IAction>;
```

### Pitfalls of Typing Dispatch Functions

This tells us that when we call `dispatch()` we're expecting to call it like this:

```ts
// Both satisfy IAction for the compiler
dispatch({ type: "ActionOne", payload: [] }); // ✅
dispatch({ type: "ActionTwo" }); // ✅
```

Now this presents an issue, our payload might be undefined, or we might pass it into an action that doesn't need it, say our reducer looks like this:

```ts
interface IState {
  items: any[];
  loading: boolean;
}

interface IAction {
  type: string;
  payload?: any[];
}

const reducer: React.Reducer<IState, IAction> = (state, action) => {
  switch (action.type) {
    case "FETCHING": {
      return { ...state, loading: true };
    }
    case "ADD_ITEMS": {
      return { items: [...state.items, ...action.payload], loading: false };
    }
    default: {
      throw new Error("Must specify action type");
    }
  }
};
```

We can't spread our payload if it's undefined.

### Federated Union Types

One thing I've found helps is using a federated union type. We need to change our `IAction` interface to a type.

```ts
type ActionType =
  | {
      type: "FETCHING";
    }
  | {
      type: "ADD_ITEMS";
      payload: any[];
    };

const reducer: React.Reducer<IState, ActionType> = () => {};
```

In that switch statement we don't get an error, we know when we call `dispatch()` with the type `"ADD_ITEMS"` we're expecting the payload to exist and be the type we specified.

Now when we call dispatch:

```ts
// Both will fail during compilation
dispatch({ type: "FETCHING", payload: [] }); // ❌
dispatch({ type: "ADD_ITEMS" }); // ❌
```

There you have it we've added more type safety to our reducer and we can even do a little better.

### Enums for Action Types

It's a strong preference of mine when you're writing reducers in your application to use enums to define the action types. An enum in TypeScript is named constant, it's enumerable meaning it can be known at compile time. For our purposes it would allow us to specify a specific action type name with a specific dispatch:

```ts
enum NamedActions {
  FETCHING = "FETCHING",
  ADD_ITEMS = "ADD_ITEMS"
}

type ActionType =
  | {
      type: NamedActions.FETCHING;
    }
  | {
      type: NamedActions.ADD_ITEMS;
      payload: any[];
    };

dispatch({ type: NamedActions.FETCHING });
```

What this buys us is organization. It ensures the only thing calling `dispatch()` is coming from within our application and that it belongs to something we typed. With just simple strings, we lose that certainty.


Typed Reducer


In Javascript, there's two major data types, objects and arrays. An array is a list like structure with numeric indexes to reference the items store there and objects are more of a dictionary, with named references to find what you stored.

```ts
const arr: Array<number> = [9, 23, 17, 31];

const obj = {
  name: "Charles",
  status: false
};
```

But we can do a little bit better, you also have `Map` and `Set`. I like to think of these as super charged versions of objects and arrays respectively but they have their own special use cases.

### Maps

Maps are similar to objects except they have some nice built-in helpers to them: `.has()`, `.get()`, `.set()`, `.delete()` and `.clear()`.

```ts
const map = new Map();

map.set("a", 1);
map.set("b", 2);

const b = map.get("b"); // returns 2

map.set("b", 3); // allows us to reset a named key.
map.delete("b");

map.clear(); // removes all entries from the map
```

Maps are also iterable, so you can loop through them like an array. One of the main differences between objects and maps is that **maps respect their insertion order**.

```ts
const m = new Map<string, number>();

m.set("c", 3);
m.set("a", 1);
m.set("b", 2);

for (const [key, value] of m) {
  console.log(key, value);
}
```

As we loop through this, the order it would log these elements is "c, 3", "a, 1", "b, 2", where an object might sort the elements alphabetically, we can't rely on the order of the keys inside an object.

Look up performance in both maps and objects is constant (`O(1)`) meaning that it's "instant" look and doesn't need to traverse the whole input to find an entry. Tests show that `map.get("key")` can be [faster](https://jsperf.com/javascript-objects-vs-map-performance) than using `object["key"]`

Because a map is iterable, if you ever need to transform a map into an object or an array you can use built helpers.

```ts
const m = new Map<string, number>();

m.set("c", 3);
m.set("a", 1);
m.set("b", 2);

const arr = Array.from(m);
// [["c", 3], ["a", 1], ["b", 2]]

const obj = Object.fromEntries(m);
// { c: 3, a: 1, b: 2 }
```

### Sets

Sets are similar in that they have a nice API to add and remove and get data out of them.

```ts
const s = new Set();

s.add(4);
s.add(5);
s.has(3); // false
s.has(4); // true
```

The main difference between an array and a set is that **sets cannot have two values the same; only one occurance of a value is allowed**. Sets de-duplicate their input and like maps respect their insertion order.

```ts
const s = new Set();

s.add(4);
s.add(5);
s.add(4);
s.add(3);

s.values();
// SetIterator {4, 5, 3}
```

Even though we added `4` twice, we only have one occurence of this value. Sets are iterable too, so again, you can loop their values:

```ts
const s = new Set();

s.add(4);
s.add(5);
s.add(4);
s.add(3);

for (let item of s) {
  console.log(item);
}

// 4
// 5
// 3
```


Maps & Sets


So another year is over and I keep seeing posts (some great and some rather canned, both enjoyable) about what 2019 meant for folks. Which made me think, what did 2019 actually consist of for me? I don't consistently write posts like this last one I wrote was 6 years ago [2013](/writing/twenty-thirteen/) and I wasn't really interested in doing it again until this year.

Too much happened not want to process it. I went through some personal things, a job transition, I went to a bunch of conferences and felt like I learned so much (as trite as that may sound).

I broke it down by section.

- [Takeaways](#takeaways)
- [Tech Projects](#projects)
- [Work Transition](#work-transition)
- [Conferences](#conferences)
- [Personal](#personal)
- [To 2020](#to-2020)

## Takeaways

I don't think time really allows us to be the same people year over year and this year was no different. I don't think I'm the same person who made it through 2018 looking at 2019.

I did learn quite a few things about the world and myself. Some good and some bad.

The Good:

- I have value as an engineer and my capacity to grow and lead is much greater than I believed. I spent a lot of time in toxic work environments, being gaslit and minimized by senior engineers on the teams I was on. Coming into Microsoft and then migrating onto the team I'm on outside that place, I don't feel this way anymore, I don't feel like I'm in the way, but I can contribute at a higher-level.
- Taking care of my body is a good idea. I keep learning that, I'm reaching the end of my 20s and my body isn't the same as it was at 21, let alone 18. It needs care and maintenance and green vegetables. I wrote a really long blog post on [taking care of yourself](/writing/self-care/).
- TypeScript has continued being the most rewarding programming experience I've had in my career. I can't say enough good things about it. There's lots of ways it could be overkill, but the tooling and the environments and the feedback it provides you as a developer without getting in your way, ughhh too good.
- Fighting with errors never gets anywhere, taking them piece by piece is usually a better approach. I used to get angry by error messages and things not compiling or tests failing, but I feel like my attitude shifted into "Hmm...why did that happen?"

The Bad:

- I am less interested in learning new frameworks unless they meet a threshold of almost instant productivity. For instance, Vue and Svelte are fantastic and come with a lot of benefits, but they have to compete with 5 years of muscle memory of React and the initial learning curve. My views on frameworks haven't really changed since this I wrote this [blog post](/writing/a-defense-of-frameworks/) and I'm hoping the root of that doesn't change but I hope I can re-examine my defaults on this.
- Speaking of productivity, I have side projects that I really want to ship and I'm not sure where I can make time to do the planning and product planning and designing that goes into them. That spiral never seems to end.

## Projects

I worked on a few things this year outside of work that I was really proud of:

- [Data Structures and Algorithms](https://github.com/charliewilco/data-structures-algorithms): I worked with a mentor to understand some CS fundamentals, like data structures that aren't common to TypeScript (like linked lists and trees), basic search algorithms and common interviewing questions. They're all documented in this repo and have accompanying unit tests.
- [Basic React Todo List](https://basic-todo-list.now.sh/): In one of the interviews I went through, I built a simple todo list. That alone, with a timer was awesome. It was like perfect, we just sat and built something together and I narrated what I did. A few months later I rewrote it with Hooks and then recently updated it again to use Immer and state reducers.

<figure class="Post__figure--right">
  <img src="/images/posts/me-teaching.jpg" alt="Speaking behind a podium">
  <figcaption>Speaking at Seattle React.js</figcaption>
</figure>

I gave several talks this year, about TypeScript and React called ["Trial by TypeScript"](https://seattle-react-ts-2019.now.sh/) and I have that at Seattle React.js Meetup. I really loved doing that and met so many great people from that community. I've been doing a lot more speaking the last couple of years in venues like this and I hope to do more of it.

I started a newsletter this year which you can [subscribe to](/subscribe) if you're interested (you can also subscribe if you're not interested). I was able to put out [a couple issues](/newsletters/) and have plans for more this month.

One of the other projects I worked on was my project, Downwrite. This is a markdown writing application that I've been working on. I really wanna ship it but I need someone to help me do some actual planning, I'm not a great project manager for myself. It's [open source](https://github.com/charliewilco/downwrite), I'm doing a big re-write to use serverless GraphQL and Apollo.

## Work Transitions

At the beginning of the year I was about a third of the way through my 18 month contract at Microsoft. I was planning on moving there full time, but that wasn't in the cards.

So I went out on interviews and I prepped for interviews. I read through books like _Cracking the Coding Interview_ and _Grokking Algorithms_. I had my resumée audited and did interview prep. I walked out of interviews, I was disappointed by some interviews, and I learned so much about myself, the industry and this process.

I wrote more about that process [here](/writing/technical-interviews-explained/).

Don't get me wrong, I met lots of amazing people and great engineers and made a few friends along the way in this process. But it wasn't a picnic.

### Interviewing

Walking out of interviews was something I never thought I would do, but was incredibly liberating. It gave me a sense of worth and value for my time and the time of the people interviewing me. I don't typically enjoy coding challenges as a thing, especially when the interviewer has made up their mind about JavaScript and have lots of opinions already. Any time the interviewer was a jerk about something, I offered to end the conversation or cut the meeting short.

During one very interview with an engineer, he wouldn't stop calling certain JavaScript APIs "bullshit" and how "fucking stupid" the language was, believe it or not, got too profane for **_ME_**. Then I said, "Hey, I think we're done here, thanks for taking the time, have a great afternoon" and I left.

I hung up on Amazon, twice. In one solution during a technical interview, I used the keyword [`arguments`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments), the interviewer didn't know this was a feature of JavaScript, didn't believe it was a thing for the last 25 years, convinced himself I was tricking him and forbade it's usage.

There were some I enjoyed quite a bit and learned a lot and the little algorithms were really fun. Like I said, I met lots of great people, the bad apples, however, were just a little more animated than the folks who let me nerd out about TypeScript or why typed languages are a cool thing.

The biggest thing I learned, is that my barometer for whether I can work someone is pretty well-tuned at this point, saying "no, this won't work" and moving on is a great way to not fight against what that metric is telling me. When I figured that out, cutting things short, declining to move forward was a much clearer choice to make. You're not obligated to participate in something that makes you feel disrespected or unprofessional.

### Take-Home Assignments

There wasn't one process that let me walk away without a take-home assignment. Some had an outrageous scope for the time allotted and I turned them down. Some were really really fun, like one I got to like build MobX from scratch and another one I got to build out little algorithms I had read about.

There's one I remember being really outrageous, where the company asked me to build out a whole screen to a pretty high fidelity in less than a week, it needed to be responsive, built with React and matched the company's branding guidelines, I had a good laugh about that one.

### Finding a Place for Me

Eventually after a couple offers, I ended up at the place I'm at now a small agile team, working out of Pioneer Square. I'm noticing I'm enjoying have a big impact on a small team, that leadership opportunities are being handed to me and the things I enjoy about programming like trying things and experimenting with approaches.

<figure class="Post__figure--left">
  <img src="/images/posts/work-desk-setup.jpg" alt="All my monitors at work">
  <figcaption>I feel like Dwight creating "Mega Desk"</figcaption>
</figure>

For instance, I made it a point to re-write the codebase in TypeScript and got no push back and was given the freedom to try and fit it in a really nice time-box. I started speculating that working with GraphQL would be beneficial for all the services we had to interact with and being able to generate React Hooks for a given query would be really helpful if we were dividing labor across the stack. To my surprise, the team welcomed the idea gladly, and it's what we're doing 5 months later and I'm (still) really excited about the work we're doing.

This was a big and stressful part of 2019 for me. And I'm just glad it's behind me while still I feel like took away so many important things, like small teams work for me and being in a place that values my input and is open to trying things is a great environment for me to work in.

## Conferences

I went to three conferences this year. I felt incredibly lucky to have been able to afford to attend these conferences and travel to the Netherlands for the one.

<figure class="Post__figure--right">
  <img src="/images/posts/framer-badge.jpg" alt="Conference badge with my name on it">
  <figcaption>I managed to get three of these in 2019.</figcaption>
</figure>

- **Framer Loupe**: I didn't intend to go to this one, but someone asked me to come and it was in Europe and I needed a break from the interviewing grind. It was really interesting going to a design conference. I spent a really long plane ride processing what this community was looking for since Framer uses React and TypeScript as their main interface for building prototypes. My biggest takeaway was that the line between engineer and designer is so wonderfully blurry at this point and that there's a weird obsession for these types of tools to build "production code" which feels like misappropriated energy.
- **TSConf 2019**: This was just affirming of all of the things I loved about TypeScript before and made me excited for the ways people were building really cool things with it. I reconnected with some friends and got just take a lot of new information in and make an Irish exit.
- **CascadiaJS**: I personally loved this conference, it was so nice to connect with the whole PNW JavaScript community. I saw a lot of people that I've gotten to know out here. There is much to say about this other than it was just a feeling of community and connecting with folks.

There's more conferences I want to go to, I went to React Rally in 2017 and I'm interested in going again. I definitely bought tickets to [React Summit](https://reactsummit.com/) in Amsterdam and I'm still going to see if I can repeat TSConf and CascadiaJS. There's also GraphQL Day in Berlin that I'd like to go to, but the goal for a few of those events is make someone else pay for it.

## Personal

<figure class="Post__figure--left">
  <img src="/images/posts/amsterdam-central.jpg" alt="Amsterdam Centraal">
  <figcaption>Amsterdam Centraal Station</figcaption>
</figure>

Well, I finally got to travel to Europe, had never been. I really want to go back, I'm thinking one of those conferences would be lovely to take me to another part of that continent, I'd love to go back to Amsterdam, but Berlin and coastal Ireland would be lovely. I was so tense about getting my passport in time and when it finally came, my dad commented out physically relieved I was and he actually took me to the airport for my flight and it was such a nice ride down.

This year I finally fell in love with flying, it always made me feel nervous for whatever reason. But there's something about being stuck in the air with nowhere to go that leads to the best time just getting lost in a book. Plus, you're up there close to God with all those free sodas.

<figure class="Post__figure--right">
  <img src="/images/posts/seattle-symphony.jpg" alt="Orchestra warming up on stage.">
  <figcaption>Seattle Symphony at Benaroya Hall</figcaption>
</figure>

I finally saw the Who perform when they came to Seattle. I loved hearing them live finally, even it was just Pete Townshend and Roger Daltrey with a backing band. The two of them did this wonderful stripped down version of "Won't Get Fooled Again" with Roger stomping along as it's own percussive element and Pete reinterrupting the synthesizer parts on acoustic guitar, (you can see it from an earlier part of their tour [here](https://www.youtube.com/watch?v=zbaiz048pSM)). They've been one my favorite bands since childhood. The Who have more US tour dates in Colorado this year and I **_really_** want to see them again.

But I also got see the Seattle Symphony at Benaroya Hall.

Google Stadia got released and I've been enjoying it so far, but it has made it clear how bad my television is and how bad it needs replaced.

I got new glasses this year and I'm told I need to wear way more often. It's an awkward transition because I dropped these and broke them a week ago getting out of a car.

Beer seemed to lose it's appeal in 2019, I got really into trying different wines. I'm pretty cheap when it comes to drinking if it's just me. [Ravage's Cabernet Sauvignon](https://www.honestwinereviews.com/ravage-cabernet-sauvignon-review) became my go to cheap grocery store red wine.

### Books Read

I did get through quite a few books in 2019. Here are a few of my favorites:

- _Amateur: A Reckoning with Gender, Identity, and Masculinity_ by Thomas Page McBee: This was such a fantastic read about re-examining masculinity and what makes it toxic and how confronting the roots lead validating the gender and body you're in. the author was the first trans man to fight at Madison Square Garden and this is his memoir of getting to that fight and unpacking what it means to be a man.
- _Ruined by Design_ by Mike Monteiro: This book was a manifesto on how to be a decent human being in tech, it outlines what responsibilities you have and whether we can clean up the messes of Uber, Airbnb, Twitter and Facebook. I'm both optimistic while growing more jaded.
- _Coders: The Making of a New Tribe and the Remaking of the World_ by Clive Thompson: I went to see the author on his book tour and it was interesting to read this. Since this is a world I inhabit, it's weirdly fascinating to see it from the perspective of someone who's looking at it with fresh eyes and answering the root questions of why things are the way they are and how they got to be that way.

<figure class="Post__figure--right">
  <img src="/images/posts/ff4-dr-strange-comics.jpg" alt="Fantastic Four and Doctor Strange comics">
  <figcaption>Mail days are the best days.</figcaption>
</figure>

Got really into Marvel this year. I found reading comic books and easy way to disengage and enter into a wonderful fantasy world where villians are actually stopped and not appointed to the Supreme Court or bankrupt companies while walking away with almost \$2 billion in cash. But the collector's editions that Marvel publishes, had like 4 or 5 issues inside them and they were the perfect size to devour in a single sitting. I loved taking them on plane rides. Plus everything going on with MCU's Phase 4 and not having another film until spring of 2020, it was great to still engage with these characters and speculate on what's coming next.

Some good Marvel titles:

- Nick Spencer's current run of the _The Amazing Spider-man_; this feels like perfect Spider-man, the way he was meant to be understood.
- Mark Waid's current storylines on _Doctor Strange_; I just love Doctor Strange, this is more cosmic and space driven than magic driven and it's a fun twist.
- _House of X_ from Jonathan Hickman; this was just pure hype that delivered and I was a fair-weather X-men fan to begin with
- _Nova Vol. 1_ from Dan Abnett; with all the Nova rumors with the MCU, I was really really eager to dive into who this character was and I was not disappointed.

### Family

I got to see my dad more this year than I had since I moved out to the Pacific Northwest. We had a big reunion and I spent time with both of my sisters and my sister's kids and my older cousin and his daughter. And I more affirmed in those ties and how much they all mean to me.

One funny thing that happened, my nephew Patch (5), was driving his mother up the wall when we were all together. I cut in and asked if he wanted to read with me. I had a Fantastic Four comic with me and he flipped through it and he could point out a lot of the characters like Ant-man and She-Hulk and Spider-man. That moment was sweet on it's own but it got better. Before they left I asked him if he wanted to take it with him on the plane and he asked "But do I have to mail it back to you?" and I said "Don't worry about it, it's all yours" and then he gave me a big hug. Then to make it better, he started school this year and kept it in his backpack for weeks.

## To 2020

I don't have any resolutions other than focus on the hobbies I care about, like reading, exercising and sitting and doing absolutely nothing. I'm just thankful, thankful I made it through, thankful to have connected with some many new people, thankful to have grown as a person.

Happy new year to everyone and I would love to hear how your 2019 turned out!


Twenty Nineteen


[Hooks](https://reactjs.org/docs/hooks-reference.html) are now a part of React starting in version [16.8](https://reactjs.org/blog/2019/02/06/react-v16.8.0.html). And I've been rather _mehhh_ about them, then I started using them and got a little more _aight_ about them, and finally I started using Hooks with TypeScript and was like _well alright_.

<figure>
	<img alt='Doctor Strange putting on his cape with confidence' src='https://media.giphy.com/media/QW9hGBwILym4oOifVa/giphy.gif' />
  <figcaption>The Hooks API is like your Cloak of Levitation, gives you powers, saves your sanctum being attacked by Kaecilius (maybe I shouldn't write blog posts and watch Marvel movies at the same time, tweet me if I'm wrong).</figcaption>
</figure>

## Generics in TypeScript

TypeScript has this concept of a "generic". When you're writing a function you may not know what parameter you're getting, what interface it matches, or what type it is, so as we add type annotations, we can add this "generic" type and allow the consumer to be able to provide their own type for the parameter.

```typescript
function identity<T>(arg: T): T {
  return arg;
}
```

In this very contrived example, we add `<T>` before the function parentheses and then we have `T` as a type to use. Now we can declare, our parameter has a type of `T`. This will let us either let TypeScript infer the type and know or let us explicitly define what type our function should work with.

```typescript
const id = identity<string>("user");
```

Or with a class:

```typescript
class LocalCache<T> {
  public items: T[] = [];

  add(item: T): void {
    this.items.push(item);
  }

  remove(item: T): void {
    const key: number = this.items.find(item);
    if (key) {
      this.items.splice(key, 0);
    }
  }
}

const cache = new LocalCache<string>();
cache.add("Hello");
cache.remove("Hello");
```

We don't need to know what `T` represents here. We just need to know it could be anything.

The best example of where generics can get powerful is arrays methods. Arrays can have anything in them. TypeScript can guess what the result of `[].map()` is going to be or we can tell it. That way when we're wrong, our compiler tells us.

```typescript
[1, 2, 3, 4, 5, 6].map<string>(n => n.toString());
```

Then there's `Array.reduce()` where you take an array, and break it down to a single element.

```typescript
const sum = [1, 2, 3, 4, 5, 6].reduce<number>((acc, val) => acc + val, 0);
```

This is a basic example. But `.reduce()` is great for iterating through a list to build any value you want. But you can declare a generic to both methods I described and know when you break the contract of that type.

> For more about `.reduce()` check this post out from Sarah Drasner, [_The Almighty Reducer_](https://css-tricks.com/understanding-the-almighty-reducer/)

Generics give us a way to be more explicit with our code without making assumptions. You can read more about Generics in TypeScript in their [docs](https://www.typescriptlang.org/docs/handbook/generics.html).

My point being, generics make hooks really strongly typed and can prevent you from making mistakes as you work and comeback to your work.

<figure>
	<img src="https://media.giphy.com/media/l0Ex0m8xQ74YNsfzq/giphy.gif" alt="Benedict Cumberbatch as Doctor Strange waving his hands in practice and making a weird face" />
	<figcaption>TFW all this handwaving makes sense</figcaption>
</figure>

## React Hooks with TypeScript

For the record, I gained all of what follows from reading through React's [type definitions](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts). The value of adding these type annotations to your code is that we won't be assuming a type of `any` and with confidence define the interface for our state and context in the same way we're used to with `React.Component`.

### `useState()`

This hook allows you to work with simple state. Normally you'd call it like this:

```js
function Counter() {
  const [count, setCount] = React.useState(0);
  return (
    <div>
      Count: {count}
      <button onClick={() => setCount(0)}>Reset</button>
      <button onClick={() => setCount(prevCount => prevCount + 1)}>+</button>
      <button onClick={() => setCount(prevCount => prevCount - 1)}>-</button>
    </div>
  );
}
```

If you want to add types, you can pass an explicit generic to `useState()` versus an inferred one. Using this is option about but it tells the next engineer your intention explicitly.

```typescript
const [count, setCount] = React.useState<number>(0);
```

This will tell us that `count` is a number, and that `setCount()` should expect only a number.

### `useContext()`

`useContext()` allows you the ability to subscribe to a context provider from `React.creatContext()` and receive updates from it, like passing state down without having to explicitly pass props down to a component. This hook makes working with the Context API more explicit IMO than using a `<Context.Consumer />` component.

```js
const DarkModeContext = React.createContext({});

function App() {
  return (
    <DarkModeContext.Provider value={{ darkMode: false }}>
      <SomeComponent />
    </DarkModeContext.Provider>
  );
}

function SomeComponent() {
  const { darkMode } = React.useContext(DarkModeContext);

  return (
    <div style={{ background: darkMode ? "black" : "white" }}>
      Hello Darkness My Old Friend
    </div>
  );
}
```

Working in TypeScript will let us give `createContext` and `useContext` a generic to define the interface for our context. When we call `context` now, TypeScript knows with confidence that it has a key called `darkMode` and that it's not an implicit any and it in fact is a boolean.

```tsx
interface IDarkModeContext {
  darkMode: boolean;
}

const DarkMode: React.Context<IDarkModeContext> = React.createContext<IDarkModeContext>({
  darkMode: false
});

function App() {
  return (
    <DarkModeContext.Provider value={{ darkMode: false }}>
      <SomeComponent />
    </DarkModeContext.Provider>
  );
}

function SomeComponent() {
  const { darkMode } = React.useContext<IDarkModeContext>(DarkModeContext);

  return (
    <div style={{ background: darkMode ? "black" : "white" }}>
      Hello Darkness My Old Friend
    </div>
  );
}
```

You can see this example on [CodeSandbox](https://codesandbox.io/s/mo2m2qy038).

### `useEffect()` & `useLayoutEffect()`

Neither `useEffect()` or `useLayoutEffect()` take a generic because they don't return a value to use. But it does take two parameters, `EffectCallBack` and the `DependencyList`.

```typescript
type EffectCallback = () => void | (() => void | undefined);
type DependencyList = ReadonlyArray<any>;

function useEffect(effect: EffectCallback, deps?: DependencyList): void;
```

You'll see this dependency list a lot when you're working with hooks. The idea is that, when one of those dependencies change, it re-runs the first parameter you passed the hook.

### `useMemo()`

`useMemo()` caches the results of expensive functions and returns the value. It takes 2 parameters: the expensive function to call and dependencies to track. When those dependencies change, it fires the expensive function again.

```js
const value = React.useMemo(() => getExpensiveValue(a, b), [a, b]);
```

#### What is Memoization?

Let's unpack what memoization is. Memoization is a technique that allows us to wrap a function to cache the results, so that if the same input gets called to that function again, the function doesn't rerun, it returns the results from the cache.

```typescript
interface IMemoizeCache {
  [key: string]: any;
}

// https://medium.freecodecamp.org/understanding-memoize-in-javascript-51d07d19430e
export function memoize<T>(fn: Function): Function {
  let cache: IMemoizeCache = {};

  return (...args: any[]): T => {
    let n = args[0];
    if (n in cache) {
      return cache[n];
    } else {
      let result = fn(n);
      cache[n] = result;
      return result;
    }
  };
}
```

Now let's implement a memoized function:

```ts
const addTen = (n: number): number => n + 10;

const memoizedAdd = memoize(addTen);

memoizeAdd(3); // 13
memoizeAdd(12); // 22
memoizeAdd(3); // 13
```

At this point the `addTen()` has only run twice even though we called the wrapped memoize function three times because it got only got two different inputs.

> Side note: typically when you need to memoize a function, it's doing something intensive and computationally expensive, not just adding ten to a number.

#### What about the hook version of this?

The way of this particular hook goes, this hook memoizes the value that gets returned from the first parameter.

```tsx
function getExpensiveValue(a: number, b: number): number {}

const value: number = React.useMemo(() => getExpensiveValue(a, b), [a, b]);
```

In this case, TypeScript would infer that `useMemo()` returns a `number`. But you can all so give it generic:

```tsx
const value = React.useMemo<number>(() => getExpensiveValue(a, b), [a, b]);
```

The second parameter of `useMemo()` is a `DependencyList` like `useEffect()` and like that hook those dependencies cause the first parameter to run again.

### `useReducer()`

`useReducer()` is my favorite hook. This is what people refer to as the Redux killer and honestly, it might be, but by itself is awesome regardless of any crimes it may or may not be acquitted of.

The idea behind state reducers is that you have some state and they only way that state gets updated is through dispatching an "action" object that describes the way that state should update. You have function that's your reducer, that takes in your previous state and returns your new state based on that description.

Let's take a look at a basic example:

```js
const initialState = { count: 0 };

// function
function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return { count: state.count + 1 };
    case "decrement":
      return { count: state.count - 1 };
    default:
      throw new Error();
  }
}

function Counter({ initialState }) {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      Count: {state.count}
      <button onClick={() => dispatch({ type: "increment" })}>+</button>
      <button onClick={() => dispatch({ type: "decrement" })}>-</button>
    </>
  );
}
```

Now in this example, we've created a state object with a `count` and described, only two ways that state can update, dispatching `{ type: "increment" }` or `{ type: "decrement" }` to describe how our state should change. So let's add some type annotations.

```typescript
interface IState {
  count: number;
}

interface IAction {
  type: string;
}

const initialState = { count: 0 };

function reducer(state: IState, action: IAction): IState {
  switch (action.type) {
    case "increment":
      return { count: state.count + 1 };
    case "decrement":
      return { count: state.count - 1 };
    default:
      throw new Error();
  }
}

function Counter() {
  const [state, dispatch] = React.useReducer<React.Reducer<IState, IAction>>(
    reducer,
    initialState
  );
  return (
    <>
      Count: {state.count}
      <button onClick={() => dispatch({ type: "increment" })}>+</button>
      <button onClick={() => dispatch({ type: "decrement" })}>-</button>
    </>
  );
}
```

You can see that example [here](https://codesandbox.io/s/flamboyant-nobel-sqk5e).

The generic we pass `useReducer()` is `React.Reducer<S, A>` and we pass two more generics into that `Reducer<>` interface, `S` for the state of our reducer and `A` for the action object we pass into `dispatch()`.

But we can also pass more values to `dispatch()` than just `{ type: "" }` for our action object. Whatever object you hand `dispatch()` will come through as the `action` parameter in our reducer function.

Let's look at this more complex example [here](https://codesandbox.io/s/damp-dust-2y5qs). First thing, I want to draw your attention to is how we're defining our action type.

```typescript
type Action =
  | {
      type: Actions.LOADING;
    }
  | {
      type: Actions.DATA_LOADED;
      payload: string[];
    }
  | {
      type: Actions.ERROR;
      payload: string;
    };
```

We're using a union type, to declare our action object can only match one of those objects at a time. When we fire dispatch we at no time, without error do this:

```typescript
// 🚫
dispatch({ type: Actions.LOADING, payload: ["", "", ""] });

// 🚫
dispatch({ type: Actions.DATA_LOADED });
```

This may seem like overkill, but it honestly doesn't take much to when your use cases are small and when they get more and more complex you'll be glad you chose that implementation to begin with (or at least that's been true for me, YMMV).

### `useRef()`

In classes, you can use getters and setters to store and update values. With React, this was a great way to preserve values between renders without updating state. Typically developers would use refs to hold on DOM elements between renders (but you can use refs for other things).

Let's make this clear, refs don't necessarily equal DOM elements: **refs represent any value you want to preserve between renders.** This could literally be anything, a cache of server responses, form values, (sure) DOM elements, **_anything_** you want to remain consistent between renders.

```js
const ref = React.useRef({});

// ref.current = {}
```

When you call `useRef()`, it returns a `MutableRefObject` which is an object that holds the current reference of whatever is being preserved.

```typescript
interface MutableRefObject<T> {
  current: T;
}
```

This hook takes a generic to represent whatever you're preserving.

```tsx
const count: React.MutableRefObject<number> = React.useRef<number>(0);
```

Since this is a _mutable_ ref object, to update the ref all we need to do is assign a new value:

```tsx
ref.count = 3;
ref.count++;
```

### `useCallback()`

`useCallback()` is similar to `useMemo()`, except instead of a value, it returns a memoized callback function. It takes a callback to be recreated based on the second parameter the `DependencyList`.

```tsx
React.useCallback(() => {}, []);
```

It does take a generic, the type of the function in takes:

```tsx
type CountCallback = (args: number) => void;

function useMemoizedCount(): CountCallback {
  const [count, setCount] = React.useState(0);
  const memoizedSetCount = React.useCallback<CountCallback>(n => setCount(n), [count]);

  return memoizedSetCount;
}
```

Now we can know that the function returned takes a `number` and returns `void`.

### `useImperativeHandle()`

If I ever run into a use case for `useImperativeHandle()`, I'll make a new post about it.

<figure>
	<img src="https://media.giphy.com/media/l2Je0ZBSQTGUhyzio/giphy.gif" alt="Benedict Cumberbatch as Doctor Strange opening some doors and making a confused face" />
	<figcaption>Me trying to figure out this particular hook</figcaption>
</figure>

### `useDebugValue()`

`useDebugValue()` is meant to display a value in [React's DevTools](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi) and it is **only** for custom hooks. This hook doesn't return anything, it just returns `void`. Ideally this is a string but it's generic so you can pass any value to it.

```tsx
React.useDebugValue<number>(3);

React.useDebugValue<string>(isOnline ? "Online" : "Offline");
```

The number 3, would print as a label next to the custom hook in the DevTools. Let's say you need to transform the value we pass as the first parameter, we get it in the callback as the second parameter.

```tsx
React.useDebugValue(date, date => date.toDateString());

React.useDebugValue<Date>(date, date => date.toDateString());
```

The second parameter is optional and it's `(value: T) => any` with `T` representing the value passed in as the first parameter. In this example it's `(date: Date) => any`.

---

<figure>
	<img alt='Doctor Strange all powered up' src='https://media.giphy.com/media/VGQX91gActNBd51Gwy/giphy.gif' />
  <figcaption>See? Hooks can make you powerful.</figcaption>
</figure>

That's all I got, enjoy using Hooks with TypeScript! 🐠🎣🤯💸👋


Hooks & TypeScript


Between Audible, the physical books on my shelves and side tables, Kindle and all the comics, I realized something uncomfortable: I'm reading like 9 or 10 books at once. If you were ever allowed the extremely rare privilege of being in my tiny apartment in Capitol Hill, you would find shelves, tables, chairs spilling with books.

I have books on my shelves that I've bought and never read (and they're just sitting there mocking me). I have books that I've read so many times. Audiobooks that listen to as I'm falling asleep, over and over again.

But reading tends to be the only real constant in my life. From year to year, career to career, season to season, there's always books to read followed by more.

---

I alluded to this in my post on [self-care](/writing/self-care) that I value reading as a context switch away from work. That is true. But I read for more important reasons than that.

I don't think reading alone makes you a better person or better than anyone else. I think the act of reading is completely selfish (like in a good way). But why do we read at all or why should we read at all? There's some kind of magic in it, disconnecting and immersing your mind somewhere else entirely, it's like a cheap journey without going anywhere. Reading can be an escape or an education but it's honestly whatever you decide it needs to be, and it's the one thing we have as a culture that's endured centuries.

There are personal reasons I read:

- I read because I need to acknowledge someone may have better and more fleshed out ideas than me.
- I read because being able to focus on something that requires immersion but no outcome is good for my mind.
- I read because I need stories and narratives.
- I read because I write things and I need to see the language being used.

The novelest Walter Kirn, said about developing a joy for reading:

> Alone in my room, I forgot my obsession with self-advancement. I wanted to lose myself. I wanted to read. **Instead of filling in the blanks, I want to be a blank to be filled in.**

<figure class="Post__figure--right">
  <img src="/images/posts/marvel-stack-jun2019.jpg" alt="The stack of Marvel comics on my shelf">
  <figcaption>Yea this pile just grew thanks to 2-day shipping.</figcaption>
</figure>

For me comics go quickly, maybe one or two sittings and books take much much longer. I'm often listening to an audiobook while following along with a paper copy. I have no idea why I do this, but it's something just propels me to read more than I otherwise would've. I take the audiobooks to work with me. Along with podcasts, I consume them way more than anything else while I'm coding.

Between paper, audio and struggling to focus, I feel surrounded by content; fiction, non-fiction, mysteries, thrillers, sci-fi, technical, biographical. There is no wrong book. There are books that just wrong for you. Austin Kleon wrote [_33 Thoughts on Reading_](https://austinkleon.com/2014/10/17/33-thoughts-on-reading/), he outlines some really freeing ideas about reading like "don't finish books you don't like" and "the minute I finish a book, I will start a new one", both are great guides to keep in mind. You know what everything on that list is golden. The bigger theme is reading is for you, there's no wrong way to do it, it's an activity you engage with mostly through immersive commitment and it should serve you not demand of you.

In his book _The Pleasures of Reading in an Age of Distraction_, Alan Jacob says:

> Read what gives you delight—at least most of the time—and do so without shame. And even if you are that rare sort of person who is delighted chiefly by what some people call Great Books, don’t make them your steady intellectual diet, any more than you would eat at the most elegant of restaurants every day. It would be too much. Great books are great in part because of what they ask of their readers: they are not readily encountered, easily assessed.

Kleon also wrote a set of directives on [_How to Read More_](https://austinkleon.com/2016/03/03/how-to-read-more-2/). He recommends keeping a log of the books you read, I've been tracking mine in [Notion](https://www.notion.so/charliewilco/780bcc73fc8045ee9afedba66d26a436?v=789707cbeacf4661b660aade1b8b95ae) (I kinda like Notion). This does two things: shows me what I'm reading and have to read but also what I have read, the completed stack growing is pretty basic motivation to keep reading.

### Just Fucking Do It

However you choose to read, _just fucking do it_.

My inner life is generally better when I spend an afternoon with no obligations. I go get a haircut, which is next to a terrible pizza place and after my trim, I stomach a slice and read through _the Stranger_, a free local paper. Sometimes this takes a different gastroenterological state: teriyaki and catching on all the "Read Later" posts and articles on my phone. I think the next incarnation of this is going to be a wine bar, with a great book.

It's a reminder. I have a lot of obligations (or at least feel like I do), and as I give myself away to each of those things there ends up being less to go around if I don't do things that are just for me.

Reading by it's nature is one of the few things left on the planet that can be only for you. Let it.


On Reading Books


I have loved using both [Formik](https://jaredpalmer.com/formik/) and [React Testing Library](https://testing-library.com/). At this point in the React community, I consider these tools to be nice sensible defaults of projects of any real size.

This afternoon, I needed to write some unit tests for some components that I had to add to my project and they were horribly broken.

```tsx
import * as React from "react";
import "@testing-library/jest-dom/extend-expect";
import { Formik, Form, Field } from "formik";
import { render, fireEvent, waitForElement } from "@testing-library/react";

describe("Very important form", () => {
  it("submits values and fires", async () => {
    const mock = jest.fn();
    const { getByText, getByTestId } = render(
      <Formik initialValues={{ name: "" }} onSubmit={mock}>
        <Form>
          <Field name="name" data-testid="Input" />
          <button type="submit">Submit</button>
        </Form>
      </Formik>
    );

    const input = await waitForElement(() => getByTestId("Input"));
    const button = await waitForElement(() => getByText("Submit"));

    fireEvent.change(input, {
      target: {
        value: "Charles"
      }
    });

    fireEvent.click(button);

    expect(mock).toBeCalled();
    expect(mock.mock.calls[0][0].name).toBe("Charles");
  });
});
```

What I want to validate is that `mock` was called when the form submits and to see the results of `onSubmit` include the value I typed.

## Identifying the Problem

### ⛔️ Jest's Cache

Normally, when I have tests like this don't pass, where everything looks good, I start to blame Jest itself. Jest has a pretty heavy caching system. This allows you to continually be watching test files and run them very quickly and its cache is a good thing. But occasionally (am empirically) that cache gives false positives and I have found that clearing this cache and re-running your tests can give you the validation that your tests are rightfully passing. You can do that by running:

```
jest --clearCache
```

And typically in your CI process (like Travis or GitHub Actions), you should include:

```
jest --no-cache
```

But running your tests locally on your machine, caching is a good thing.

And with the cache cleared, still broken.

### ⛔️ Maybe `act()`

React DOM's test utils package (`react-dom/test-utils`) has a utility called `act()` and React Testing Library has a wrapper around it too. `act()` (from what I understand) prepares a container to be updated by batching all updates like the way it would work in the browser. So things like updating the state or re-rendering components should be wrapped in `act()`.

Anytime you're performing an async operation, it's helpful to wrap things in `act()` and it's covered in the [FAQ](https://testing-library.com/docs/react-testing-library/faq) section of React Testing Library.

Wrapping the events that update the component like this:

```tsx
import { act, fireEvent } from "@testing-library/react";

act(() => {
  fireEvent.change(input, {
    target: {
      value: "Charles"
    }
  });
});

act(() => {
  fireEvent.click(button);
});
```

Didn't help, still broken.

### ⛔️ User Error

At this point, I read through (perhaps too quickly) both Formik and React Testing Library's documentation sites and not finding anything that stood out about the tests I was writing being wrong or missing anything.

I read through all of the documentation from Jest on using `jest.fn()` mocks. And nothing. 😭

At this point, I was incredibly frustrated, I uttered every swear word at an array of volumes at my computer and even perhaps invented new swear words. I contemplated switching professions, I went for a walk around the office and drank a glass of water. 🤬

My tests were still broken. 😤

### ✅ A mysterious solution found buried in GitHub Issues

Then I searched for "React Testing Library" in the Issues section of the Formik repo and found this [#1554](https://github.com/jaredpalmer/formik/issues/1554). Since, Formik runs it's validations internally, async, then calls the `onSubmit` props, we need to await the results. React Testing Library gives us a utility for this it's called [`wait()`](https://testing-library.com/docs/dom-testing-library/api-async#wait). We need to wait to see if `mock` is called and to checkout the results.

The solution looks like this:

```tsx
import * as React from "react";
import "@testing-library/jest-dom/extend-expect";
import { Formik, Form, Field } from "formik";
import { render, fireEvent, waitForElement, wait } from "@testing-library/react";

describe("Very important form", () => {
  it("submits values and fires", async () => {
    const mock = jest.fn();
    const { getByText, getByTestId } = render(
      <Formik initialValues={{ name: "" }} onSubmit={mock}>
        <Form>
          <Field name="name" data-testid="Input" />
          <button type="submit">Submit</button>
        </Form>
      </Formik>
    );

    const input = await waitForElement(() => getByTestId("Input"));
    const button = await waitForElement(() => getByText("Submit"));

    fireEvent.change(input, {
      target: {
        value: "Charles"
      }
    });

    fireEvent.click(button);

    wait(() => {
      expect(mock).toBeCalled();
      expect(mock.mock.calls[0][0].name).toBe("Charles");
    });
  });
});
```

And now our tests are passing.

## Conclusion

Feel your feelings. If your tests aren't passing with either of these libraries, see if using `wait()` or `act()` might help and swearing at your computer isn't the worst thing in the world but having a glass of water is also a good idea.


Formik & React Testing Library and Screaming at a Computer for an Hour


"Self-care" was something I'd had read about a lot on Twitter and I couldn't help but think of it as a troupe. Ask my therapist, well, ask her if I ever waive confidentiality but there's paperwork for that so not likely. But every time I heard "self-care" like most skeptics I conjured the most ludicrous and lavish examples that the internet hash-tagged into ubiquity. Images of spend money irresponsibly or being selfish for purposes of gratification and pleasure.

If you're thinking this is ridiculous, most definitions that come from a quick Google search will have to disambiguate from that what self-care actually is and does for you. Eventually, I discovered that's not self-care, that's pageantry. Self-care is literally, doing something to care for yourself and your health or well-being. It's not necessarily champagne, spa retreats, removing all meaning from the word "mindfulness", spamming Instagram with your candle business.

---

I've been having some hard days at work, I ended working close to 60 hours last week on top of attending a conference. I'm doing more [lead work recently](/writing/urgency-importance/). Sleeping has been rough going (which is my normal, but this is worse), relaxing seems like a chore, things I was super excited for like replacing. If my therapist is to be believed, self-care is essential to keep being a human.

Self-care needs to be an intentional choice, so when I get into binge mode by default and consume streams of content.

One thing that I've observed, is that I can't really do my job nor should I super be expected to if I can't function as a human. Self-care, taking care of yourself, or "humaning". Whatever you want to call it is essential to maintaining that functionality.

### A note about privilege and ableism

What I'm about to outline, is a framework I apply to thinking about taking care of myself, it is in by nature personal. And not every application can be applied to everyone, my hope is that after reading you see the framework behind the questions and can take the questions as starting blocks.

My biases in forming these revolve around my own privilege that comes from being white, cisgender, reasonably able-bodied, male and being seen (wrongly) as straight. The questions and particulars as to how I apply this framework come from that privilege that's not distributed evenly, and I can't in good faith continue without prefacing this fact.

### Back to Basics

When I get into this state I've described of being barely functioning, it's helpful to go back to the basics. Abraham Maslow's classic ["Hierarchy of needs"](https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs), represents a progressive state of needs, ranking physical needs as a bedrock for being able to the next level of needs and that level being the foundation for being able to attain the next set of needs. For example, it's hard to worry about whether you're loved or have a sense of belonging if you're starving and need shelter.

It's hard to focus on the whole litany of everything you're supposed to be or do as a software engineer if you can't keep your eyes open. So I started to develop a framework (because I am who I am) of questions to start to probe whether those needs are being met:

1. Did I eat something recently that was actually food?
2. Do I have clean underwear and matched socks?
3. Did I talk to a human being that doesn't reside in my apartment building?
4. Did I try and sleep in the last 36 hours?
5. Does the screen go all fuzzy when I try to look at it?

Yea that's a low bar. That's intentionally a low bar, some of these things sound trivial or worrying that you might need to double check. I've found in my life living off of McDonald's and delivery is a bad idea, eating a plate of eggs and ham is better. Having clean underwear and matched socks is evidence of laundry having been done recently and speculation around the idea of a shower has happened. Talking to other humans is a chore sometimes but cheap shots on Twitter aren't great substitutes for human interaction.

These concerns all certain around forming a baseline.

### Next Level

If those concerns are addressed I feel like I can move onto the next level of things. This group is more concerned with feeling like a person once you can do basic human things.

1. **Did I go to therapy this month?** _Mental health is so important. Therapy can be such a trope but it can also be an opportunity to confess in a space "Things are not okay and I don't know what to do next". Plus my therapist is awesome, she wears glasses and everything._
2. **Did I read a book made out of a dead tree?** _"Blue light is bad and a tree had to die for me to get this book in my apartment, I should read it." That's a little chant I say in my head sometimes to convince myself to read a book. Just remember disengaging from work can be as simple as a context switch and opening a physical book or closing your eyes and listening to an audiobook can do wonders to get you there._
3. **Is the bed made?** _This is a weird new obsession of mine from the last two months. There's books written about how this can help your outlook and I have no interest in reading them. For me, it's a reminder that my home and my place in it have value and that being in a place of rest won't be a burden later. Also it's really fun now that I figured out what the hell "hospital corners" are and how to make them._
4. **Is the mess in my apartment going to prohibit me from doing the stuff I need to do or the stuff I want to do?**

### Next Next Level

This layer actively preserves the previous too, in mind this goes `human → person → semi-responsible person`

1. **Is there anything nagging at me?** _Is there anything I'm ignoring that's keeping me up at night? That's not a cliche to me, there's a whole host of things that have real potential to interrupt my ability to sleep. These things usually revolve around money, or phone calls or messages that I tend to ignore. Occasionally this can be mounds of trivial things like: "Is Notion organized?" or "It's been a minute since I've written a blog post."_
2. **Is everyone just hard to deal with?** _This is usually a good question to ask when being around other humans reaches a new height of difficulty. Usually, if everyone around me is being a jerk, it's them being the jerk it's me and usually that indicates something wrong internally like lack of sleep, feeling restricted, something personal going on that they had no hand in._
3. **Do I actually know where I'm going?** _Often a source of lack of focus or productivity and in turn a lack of being well is a result of not having a clear understanding of why I'm doing what I'm doing or how it will be in service of whatever goal and worse not knowing what the goal was to begin with. Not understanding where you're going can confuse where you are. Sometimes this distance is where I'm hoping to be in the next hour or next three years, it doesn't matter, taking basic inventory of the why can only clarify the what._

### Ever Upwards

This is where I think we have some basic level of functioning and cognition and we move onto what can actually bring some excitement back into the work itself.

1. **Am I engaged in what I'm being paid to build or am I just applying a "paint by numbers" approach?** _Some times that's easy to do. Some times this is the job and that's fine. Just getting a clear answer to this can tell you a lot and give you coordinates as to what to do next. Say you're content with the work being simple, it gives you some reserves back to invest in the rest of your team or pick up some background task. If you're not okay with the answer being yes, it's a great opportunity for on a technical level automation or abstraction and on a career level the chance to say to your manager, you need something with more to chew._
2. **Is there any tech that I care about that I'd like to see at use at work?** _We all have little lists, maybe it's Rust or Go or Elixir or Vue.js. We all have things we want to learn and this list can shame or taunt us. Spending an hour of your time (or better yet your employers time) to do a "Hello world!" tutorial with one of the things on your list is a low-cost remedy to this._
3. **Why am I building what I'm building and who does it help?** _You can take as many tickets as you like, work your backlog until someone notices, but if don't understand who you're building it for, there's not a lot of point. Some times the answer to this question is unsavory, like you're building something so people in suits and put a PowerPoint presentation together to talk to other people in suits. Other times, what you're doing can bring someone real value. Find that answer._

### What about making software?

If you got this far and were expecting a post about software engineering and have been disappointed. I'm going to balance that binary tree in your heart.

First of all you can think of this outline as a framework, let's see how many stars on GitHub it gets.

Second, software is made by humans, ensuring the bare minimum care and humanity of anyone who needs to build things and affirming that humans actually have needs can only aide in the process of growing as an engineer. To put that more practically, I don't care how the performance of using observables in my application really impacts my users, if I haven't slept or eaten something proper.

---

I can't be a good engineer, if I'm not a good human. I'm done shirking that notion or battering with it. Most software engineers make software for other humans to use, if we can't acknowledge the baseline humanity we possess and care for it, why are we making things for other humans? If we can't, we're no better than the amassing pile of La Croix and Red Bull cans in the recycling bins.


Self-Care Primer


My partner got me stop drinking energy drinks almost a decade ago. They were very bad for me, expensive and increasingly worse tasting. So out of necessity I switched to coffee and other sources of caffeine to keep the lights on and make sure the ice cream didn't melt.

<figure class="Post__figure--right">
  <img src="/images/posts/tea.jpeg" alt="Pot of tea in front of bookshelf">
  <figcaption>Literal thirst trap.</figcaption>
</figure>

Over the last few years, I noticed I drink more tea (in addition to the coffee, the Coke Zero and the water people implore me to drink). I've tried to go off caffeine before (you can read about that [adventure](/writing/caffeine/)). Like most things, I quickly became obsessed with every detail, pots, kettles, strainers, styles of mugs, how tea is grown and the most effective brewing techniques. I spent a lot of money trying the most expensive consumer brands I could find, in search of the "good stuff". Herbal teas, black teas and a few green teas quickly became favorites and things like chamomile and sencha and jasmine were ones I found to avoid. Living with someone who also loved tea has only fostered and encouraged this obsession.

Then I found it. The perfect cup of tea, or more accurately the best cup based on taste, cost and ease of brewing designed for everyday consumption. First we start with the classic [PG Tips](https://en.wikipedia.org/wiki/PG_Tips), a British tea company (which you can find in most American supermarkets). I prefer their standard black tea in their compostable pyramid bags served with a small amount of honey and lemon.

### Recipe Details

#### Ingredients

- 1 Lemon wedge (at least 1/8 of the lemon)
- 1 Teaspoon of local raw honey
- Teabag
- 8-12oz of boiling water

#### Directions

1. Squeeze lemon into the mug, removing the seeds.
2. Deposit lemon and teaspoon of honey in mug
3. Drop in teabag
4. Pour water
5. Steep for 3 minutes
6. Remove lemon, squeeze again into the mug and remove tea bag.
7. Stir and enjoy

---

There are other teas I like, I'm very fond of Earl Gray and this [Black Tea with cherry](https://www.teaforte.com/store/gourmet-tea/black-tea/black-cherry/) but this recipe is my defacto.


Perfect Cup of Tea


I'm getting used to a new engineering team and frankly, they're getting used to me too. This isn't a bad process. It's really actually enjoyable, for a lot of different reasons, but chief among them is reconsidering your mode of working, your biases and your opinions. There are junior engineers and senior engineers and project managers and engineering managers and dozens of temperaments and personalities; each member of this team is in this room for a reason, they bring some unique value to the team.

One thing about this process I find really interesting is that reconsidering your biases and values can often make you an apologist for your own beliefs.

Among those beliefs is this question that I keep wanting a clearer answer to: _What makes us ship well?_

By well I mean, fulfills the business requirements with eyes on what the product team might want to commission the engineering team to do in later sprints (be it two sprints away or 6 months away).

I have lots of biases at this point, like React is going to be the best framework for building UI or that TypeScript is best tool out there when you need to write JavaScript, and I'm more than confident in using GraphQL to empower the front-end to build applications versus using microservices through just fetch requests alone.

Those are all technology specific. Those are good defaults to be debated and rehashed. But there are biases past just technology choices, there are also beliefs about what makes engineers productive. Through our collective experiences they help us answer the question: "what makes us ship and ship well?"

My experience working in a lot of different organizations is there's some really thoughtfully considered iteration or lawless deviation from an agile process, in which engineers review features and bugs, assign time and cost, then commit to those tasks in a given timeframe (usually about two weeks). That's one bias, deciding how to cost and assign value to those tasks. But when you commit to that body of work with your team, you make a lot of choices about what's important and what's urgent.

You're making a clear cut choice on what's important and out of that come other tasks, like side projects and so-called "background" tasks. Suddenly you're inundated with stuff to do. Then your work becomes contingent on someone else; you're blocked so you go pick up something else to do or go on Twitter. Or the inverse, someone else's work is contingent on you. And if neither of those things happens, the third case, which is by far my favorite, occurs, you pick up one of those "background" tasks and you get pretty far on it and now you're putting off other important things because the side thing took up your focus and it started to be really interesting or really valuable.

Some urgency and immediacy comes with blocking someone else. Pouring time you may not have into something you care about at the expense of those other things puts them at risk on missing your deadline. Being idle due to someone else is just as bad; it's like waiting for the grass to grow and being ready to be handed a rubix cube to solve that's on fire.

Suddenly, things aren't just important, they're urgent. There's more demand, there's more pressure. One of the hard things I've had to learn is just because something is important, doesn't mean it comes with the pre-qualification of also being urgent.

If I look at the tickets I'm assigned right now, they're all important, arguably it's the business justification for paying me to code. But building a codebase that's still easy to work on 6 months from now is also important and so is working in abstractions that are easy to share between teams, mentoring junior engineers is important and explaining to director levels why we're making certain tech choices is important. But looking at that slate, not all of them are urgent. Right now I'm blocked on a ticket, that doesn't make it more urgent or less important.

It's my experience and it informs my conviction: urgency and importance are too often conflated when you're building things and especially when you're trying to build things well.

Someone else's fire doesn't make it urgent for you and in that process, they'll re-gift you their anxiety to involve you in attempt to pour their fire. Their problem is important, it just doesn't have to be solved this minute.

Give yourself the beautiful gift of having real value over what's important and

_Also, if the environment you work in is a vicious game of white elephant, trading urgent requests and problems that don't involve you initially; quit. Right now._

So to answer my original questions, we ship well when we meet the requirements and deliver the features we're asked to build. We ship well when we have a collective understanding of what's important as a team and an organization. Lots of things are important, most things are on some level, but they're not urgent.


Urgency vs. Importance


For anyone who's interested in the interview process for an engineering position, this is a synopsis of the patterns that have emerged from my experiences:

1. **Initial Phone Screen**: This where you'll get a briefing on a company, a recruiter will layout the process and answer any initial questions at a high level, it's usually 30 minutes.
2. **Technical Phone Screen**: Here, you meet with an engineer or in some cases a recruiter who's been taught to ask technical question. In the meeting you'll answer technical hypothetical questions that related to computer science fundamentals or common engineering problems. Usually about an hour. The best in my opinion are usually conversations about things you're learning or just had done, but it's rarely up to the candidate what goes during this interview.
3. **Homework Assignment**: This is a take home project with a fixed amount of time to build a thing. Most times this is a week long thing with preset amounts of time asked to be spent on it ranging from 3 to 12 hours.
4. **On-site Technical Interview**: This is the troupe, the one where you're standing in front of a whiteboard solving more complex questions than a technical phone screen with an emphasis on how you're solving and why you're solve it the way you are, this is referred to as "whiteboarding" or a "whiteboard interview". The questions are usually highly arbitrary but involve computer science principles or common interviewing questions. Usually, this is a part of an on-site interview loop, this portion tends to run about 90 minutes to 2 hours.
5. **On-site Behavioral Interview**: This meeting is more of what people think of when they say interview, it's talking about your background, experience, what you bring to the table, but you're under immense scrutiny being ranked with a rubric of qualities that are highly volatile and subject to change.

Not every company follows this formula, it's usually a mix and match situation of all of these steps. But usually, if you're not just going through this process with one company at a time, it's likely you're doing this at a half a dozen companies. I talked to one friend and they went on something like 30 interviews in two months, on top of their full-time job.

---

There are lot of different things to say about this process, it's not always fair, it's often demanding, but it's the pattern of what I've experienced, having been through dozens of interview processes.


Technical Interviews, Explained


Looking at some documentation for a newer media query [`‌prefers-color-scheme`](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme). This media query will detect whether the user's system is in a light or dark mode. That's pretty cool, it seems like every 10 minutes I read about another application having a dark mode and now a native way to detect that is coming to browsers. I'm on board. The browser support is a little sparse. It works in current versions of Safari, Firefox and it's coming to Chrome 77, with no signals from Edge or Opera.

## Example

But how does this new media query work? Imagine combining the ability to detect the user's system theme with [CSS's custom properties](https://charlespeters.net/writing/variables/):

```css
:root {
  --dark: #333;
  --light: #f7f7f7;
}

@media (prefers-color-scheme: light) {
  :root {
    --background: var(--light);
    --color: var(--dark);
  }
}

@media (prefers-color-scheme: dark) {
  :root {
    --background: var(--dark);
    --color: var(--light);
  }
}

html {
  background: var(--background);
  color: var(--color);
}
```

See a demo [here](https://codepen.io/charliewilco/pen/MMwGqN).

That's pretty cool, 23 lines of CSS to dictate the style of your application. Which in the past you'd had to write with JavaScript to manage and it feels like it belongs in the CSS.

There is a catch here. If you use this simple implementation verbatim, the user **_has to_** switch their system UI to get your site to abide by their specific preferences.

## Why Dark Mode?

Before you start implementing a dark mode with this pattern, let's look at dark mode as a concept. I'm an Android person and according to Google (as reported by [the Verge](https://www.theverge.com/2018/11/8/18076502/google-dark-mode-android-battery-life)), dark mode in their core applications like Google Keep, Google Calendar and Messages and on my system UI is better for my battery life. There's a visual choice too, there have been varying reports that seem to center around the idea that a dark mode doesn't hook your brain into your device like a light version of the same UI. Also Twitter and Facebook both have or are going to pivot to having this type of theme switcher in their applications. Not really an iOS person but iOS 13 is going to have a dark mode similar to Android.

Those are some reasons; good or bad or indifferent, they are reasons.

### Ok, but Why not?

In this [post](https://www.maketecheasier.com/are-dark-themes-better-for-eyes-battery/) they make a good case that the high contrast dark modes can out a strain on your eyesight and stark contrasts suffer legibility issues.

Regardless of what you decide to do with this and as it pertains to the web, this feature has some real user implications. As you make design considerations about adding a dark mode to your application or site please remember one thing above all else:

> Please let your users opt out of their system default.

Your user knows what's best for their needs, empower them to make the right choice for them.

## Middle Path

So there's a middle path to be forged here. One pattern all the native applications with dark modes have, is having a switch to toggle the theme. So here's an idea: why can't we accept the users default and let them opt out if they want to? Good idea, Charles, I'm glad you said something.

It's not unreasonable to assume that if the user set their system to a dark theme, that they want dark themed applications. Native applications follow this pattern but how do we do that with web technology?

Let's start by moving some of that media query logic from the CSS back to the JavaScript (but we're going to use less of it) and just use a class that holds those variables:

```css
:root {
  --background: var(--light);
  --color: var(--dark);
}

.DarkMode {
  --background: var(--dark);
  --color: var(--light);
}
```

```js
// We're assuming there's some checkbox element and a root element in the DOM
function checkSystem() {
  const prefersDark = window.matchMedia("(prefers-color-scheme: dark)").matches;

  if (prefersDark) {
    root.classList.add("DarkMode");
  } else {
    root.classList.remove("DarkMode");
  }
}

function initDarkMode() {
  checkSystem();

  if (root.classList.contains("DarkMode")) {
    checkbox.setAttribute("checked", true);
  }

  checkbox.addEventListener("change", event => {
    root.classList.toggle("DarkMode");
    const isDarkMode = root.classList.contains("DarkMode");
    checkbox.setAttribute("checked", isDarkMode);
  });
}
```

See that same from before but with this approach [here](https://codepen.io/charliewilco/pen/PrKyJa?editors=1111).

Here we're checking whether that media query returns true or not, then adding a listen to the checkbox to toggle the dark mode on or off. We could do tons of more like store the theme choice in local storage or in a cookie where we could check and load that theme. If you're looking to progressively enhance this feature, more browsers support custom properties than this media query anyway.

Dark mode is great, I love this media query; it's super powerful and when you combine it with custom properties it's even more powerful. I love dark mode personally, but you need to let that user make that choice for themselves and the web is getting to a place where empowering to users to do that is much simpler than it had been.

## More Reading

- [The Benefits of Dark Mode](https://www.keepproductive.com/blog/benefits-of-dark-mode)
- [Dark UIs. The Good and the Bad. Dos and Don’ts.](https://www.toptal.com/designers/ui/dark-ui)
- [Google confirms dark mode is a huge help for battery life on Android](https://www.theverge.com/2018/11/8/18076502/google-dark-mode-android-battery-life)


Dark Mode for Actual Users


## Engineering 👩‍💻

These are the more industry / web tech things I've been spending time with:

- [**lit-html**](https://lit-html.polymer-project.org/): I started looking at UI frameworks that could compete on the level of React in terms of sharing components between different projects. I looked a little more closely at web components and this framework in particular. I like the concept of a framework's API intentionally being rolled into the browser's API so that the framework has an end. Like autoprefixer (not a framework) was a tool designed with the intention of going away. I like that.
- [**_Dark Mode for Actual Users_**](https://charlespeters.net/writing/user-focused-dark-mode/): I finally made time to write a blog post about something I care about, dark mode. There's a new CSS media query designed to check whether you're using a dark theme on your system. I broke it down and the implications on various implementation choices.

## Read 📖

### Articles, Posts & Misc. 📝

- **[_Seattle's Tycoon of Teriyaki_](https://www.eater.com/2019/6/5/18637620/john-chung-seattle-teriyaki-korean) from _Eater_**
- **[_Capitol Hill’s Long-Awaited Retro Record Bar Previews Its Vinyl-Filled Space_](https://seattle.eater.com/2019/6/3/18650172/life-on-mars-is-now-open-capitol-hill) from _Eater_**: I keep hearing good things about this place. Not sure if I'm going to end up checking it out, but it is around the corner from me.
- **[_Inside Google Stadia_](https://www.polygon.com/2019/3/20/18273098/google-stadia-games-price-release-date-chromecast-controller) from _Polygon_**: I have been fascinated by this concept as a non-gamer. The things keeping from doing any serious video games is three factors: making space in my life for the investment of something like an RPG, no previous experience or ownership with console gaming and the investment of a console device. Google Stadia aims to scratch off the last item from that list, by using just a controller, a Chromecast and your television or browser just using the surfaces you already have to stream games to you. I'm hooked on the idea and I've already signed up for the founder's edition and I'm ready for it.
- **[_An Open Letter to Bisexual People This Pride Month_](https://www.hrc.org/blog/an-open-letter-to-bisexual-people-this-pride-month) from _HRC_**: "Wherever you are in your journey with bisexuality is exactly where you’re supposed to be -- and Pride is a celebration of your identity, too." -- PREACH 💖💜💙.
- **[_Inside Microsoft’s surprise decision to work with Google on its Edge browser_](https://www.theverge.com/2019/5/6/18527550/microsoft-chromium-edge-google-history-collaboration) from _the Verge_**:

### Books 📚

- **[_The Sentence is Death_](https://www.amazon.com/Sentence-Death-Detective-Daniel-Hawthorne/dp/0062676830) by Anthony Horowitz**: I've read his last two books, this is a sequel to his last _A Word is Murder_. It doesn't have the same appeal but I'm hoping that changes.
- **[_Grokking Algorithms_](https://www.manning.com/books/grokking-algorithms) by Aditya Y. Bhargava**: Needing to get your CS fundamentals up to scratch? This is the book. Every other book makes me feel incredibly stupid and this one manages to break things down into simple concepts that are easy to digest.
- **[_Coders_](https://www.penguinrandomhouse.com/books/539883/coders-by-clive-thompson/9780735220560/) by Clive Thompson**: I saw Clive Thompson when he was in Seattle on his book tour. It's both strange and comforting to see the industry I work in, dissected from this perspective, the larger trends and with a focus on front-end engineers. This book is largely anecdotal but it's captivating and informative and well researched.
- **[_Amazing Spider-Man Vol. 3: Lifetime Achievement_](https://www.amazon.com/Amazing-Spider-Man-Nick-Spencer-Vol/dp/1302914332) by Nick Spencer**: Spider-man is the crown-jewel of the Marvel canon and this iteration of Nick Spencer working with such a packed character is definitely keeping pace with my attention.
- **[_Fantastic Four Vol. 1: Fourever_](https://www.amazon.com/Fantastic-Four-Dan-Slott-Vol/dp/1302913492) by Dan Slott**: Loving Dan's take on Marvel's first family; I've really really been getting into Fantastic Four.

## Watch 📺 & Listen🎙

- [Foo Fighters Meets 70's Bobby Caldwell - Live Looping Mashup by Elise Trouw](https://www.youtube.com/watch?v=Gl9GtO_vQxw): Just watch, trust me.
- [_It Might Get Loud_](https://www.imdb.com/title/tt1229360/): This is the story of the Edge from U2, Jimmy Page (Led Zeppelin and the Yardbirds) and Jack White (from the White Stripes and the Raconteurs, this was before the Dead Weather and his solo career), all meeting to discuss the impact of the guitar on their lives, what drew them to it and how they crafted some of the most beloved songs. I remember when this came out over 10 years ago and watching it again made me revisit all this music I've loved for entire life, it spoke of passion and conviction, but also of joy and craft. It's seriously a movie I should watch more regularly.


Weeknotes No. 3


## Engineering 👩‍💻

These are the more industry / web tech things I've been spending time with:

- [**Kotlin Overview**](https://developer.android.com/kotlin/overview): I started to get into Android development a little bit as a hobby (I'm boring) and I dived right for Kotlin over Java. Very early days on this pursuit but I'm enjoying the language so far. Small point of joy: functions are defined with the keyword `fun` versus JavaScript where you have to type out `function`. It just makes me 😁.
- [**Announcing TypeScript 3.5**](https://devblogs.microsoft.com/typescript/announcing-typescript-3-5/): I really can't write JavaScript without TypeScript anymore. Couple of cool features I'm glad are in the release: the `Omit` utility finally makes its appearance (which is very handy for passing around parts of objects or objects without certain keys) and there's better support for Union Types. It did add smart select, I'm just not sure why you can't smart select something and turn it into an interface declaration, I would use that way more.
- [**VS Code Roadrunner**](https://github.com/ruslanchek/vscode-roadrunner): This is a VS Code extension that turns [npm scripts](https://docs.npmjs.com/misc/scripts) into a GUI. It's nifty! And it's very useful when you're onboarding onto a new project.

## Read 📖

Other points of interest in things that I'm reading:

### Articles, Posts & Misc. 📝

- [**_Feedbin_**](https://feedbin.com/): This service continually gets recommended to me for an RSS reading service and there is a clear reason for that: it's very fucking good at doing at being an RSS reader. It keeps things in sync and lets me maintain my feeds. Right now, I'm using [Readably](https://play.google.com/store/apps/details?id=com.isaiasmatewos.readably) for Android and the website and [Reeder 4](https://reederapp.com/) for desktop. Very much worth the \$5 a month.
- [**_“Ethics” and Ethics_**](https://ia.net/topics/ethics-and-ethics) from Oliver Reichenstein on iA.net: A brutal discussion of ethics and morals in tech and how to have meaningful conversations about them.
- [**_Summer Reading List_**](https://www.nytimes.com/interactive/2019/books/best-historical-fiction.html) from NYT: A visually stunning reading list; a lot of the things on this list look like literary candy that I just really wanted to unwrap.
- [**_iTunes Expected to Be Retired After Over 18 Years_**](https://www.macrumors.com/2019/05/31/goodbye-itunes/) from MacRumors:
- [**_Huck: Sound and Vision Blend_**](https://huckleberryroasters.com/products/sound-and-vision-blend): This isn't something I read but something I tried. I see this coffee advertised to through Trade Coffee on Instagram and Facebook a lot, so being heavily susceptible to the power of suggestion: I tried it. It was good, it wasn't as dark as the description made it seem like.

### Books 📚

Finished _Marvel Comics, the Untold Story_ by Sean Howe and I really enjoyed. It was a very thorough history and it was interesting to see where certain plots came from, for instance, I didn't know the whole concept behind _Secret Wars_ was dreamed up by Mattel as a promotional gimmick that they actually failed to deliver on.

Other books I read this week included:

- [**_Amazing Spider-Man Vol. 1: Back to Basics_**](https://www.amazon.com/Amazing-Spider-Man-Nick-Spencer-Vol/dp/1302912313/) by Nick Spencer: I haven't read too many _Amazing Spider-Man_ titles and this one feels very accessible to me. So I got this and its follow up _Amazing Spider-Man Vol. 2: Friends and Foes_ 🕷.
- [**_Google It: A History of Google_**](https://www.amazon.com/gp/product/1250148227/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1) by Anna Crowley Redding: This is a little bit of light reading, it feels a little more like a coffee-table book and its pages are very visually appealing versus being information dense. It's pretty much an abridged everything you've ever heard about Google or the mythology behind the founding of the company. I didn't find it as interesting as I thought I would, mostly because there weren't any shocking moments and all of this history has happened in my lifetime 🔍.
- [**_Daisy Jones & The Six: A Novel_**](https://www.amazon.com/gp/product/1524798622/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1) by Taylor Jenkins Reid: I just started this novel and it's like a fake oral history of a band that doesn't exist. It's been getting mixed reviews but it came recommended to me, so let's roll those dice 🎲.
- [**_How to Write Short: Word Craft for Fast Times_**](https://www.amazon.com/How-Write-Short-Craft-Times/dp/0316204323/) by Roy Peter Clark: I've had this on my shelf for awhile and it's a really short guide to writing better in short formats and observing the way we communicate so much in so little ✍️.

## Watch 📺 & Listen🎙

- [**_Listen: Sufjan Stevens Shares Two New Songs For Pride Month_**](https://www.npr.org/sections/allsongs/2019/05/29/727582258/listen-sufjan-stevens-shares-two-new-songs-for-pride-month): If you didn't have a gay crush on Sufjan Stevens, you're doing something wrong 🏳️‍🌈. So these songs fit, I like Sufjan a lot and I just wish he'd put out a full-length album soon.
- [**_The Banach–Tarski Paradox_**](https://www.youtube.com/watch?v=s86-Z-CbaHA) from VSauce: This video unpacks the chocolate bar illusion (just google it) and the concept of infinity. It uses the [Banach-Tarski paradox](https://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox) and a really really interesting explanation of infinity to dissect this myth and your brain will get a work out.
- [**_White Lies_**](https://www.npr.org/podcasts/510343/white-lies) from NPR: This podcast reminds me a lot of [_Atlanta Monster_](https://atlantamonster.com/) buried secret, southern town, decades later, putting the pieces back together.
- [**_Up First_**](https://www.npr.org/podcasts/510318/up-first) from NPR: I needed a news podcast for the morning, I was churning through [_the Daily_](https://www.nytimes.com/podcasts/the-daily) before I got to the office.


Weeknotes No. 2


Blogging is hard so to assuage my guilt about the time gaps between posts, I thought I would try this format. Essentially the "weeknotes" format is a breakdown of what I've consumed or interacted with that was meaningful to me.

## Engineering 👩‍💻

These are the more industry / web tech things I've been spending time with:

- **[Static Analysis in JavaScript: A Technical Introduction](https://medium.com/codecademy-engineering/static-analysis-in-javascript-a-technical-introduction-859de5d444a6)**: I finally sat down and read Josh's REALLY LONG explanation of static analysis in JavaScript and its history and its place in your workflow. It's a very excellent primer to ASTs, listing and everything it includes.
- **[Introducing GitHub Package Registry](https://github.blog/2019-05-10-introducing-github-package-registry/)**: Like many engineers I'm interested to see the potential of having package registration co-existing with your source code. Between the registry, [Github Actions](https://github.com/features/actions) and acquiring [Dependabot](https://dependabot.com/blog/hello-github/), I honestly think they're giving npm, Inc. a run for the money. That's not to mention all the [new VS Code integrations](https://github.blog/2019-01-07-create-pull-requests-in-vscode/) and all the interesting new features from [Paper Cuts](https://github.blog/2018-08-28-announcing-paper-cuts/).
- **[MobX](https://mobx.js.org/)**: Been using MobX a lot at work and honestly, I hated it at first, and I started playing with [mobx-react-lite](https://github.com/mobxjs/mobx-react-lite) (it's essentially a hooks version of mobx-react) and then I started to really enjoy it. The more time I spend with this little library, the more I understand about classes in JavaScript, observables and all the niceties that come with using MobX with TypeScript.
- **[Demo - Accessible Toggle Switch](https://codesandbox.io/s/8px4rpm5zj)**: You've seen custom switches, iOS styled toggles with the checkbox hack and every derivation of that. But what I wanted to know, was how you could do this accessibly. So I ran across `role="switch"` ([docs](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Switch_role)) and made a little demo of using those attributes with React Hooks.

## Read 📖

Other points of interest in things that I'm reading:

### Articles, Posts & Misc. 📝

- [**_How Microsoft learned from the past to redesign its future_**](https://www.theverge.com/2019/4/29/18515776/microsoft-design-open-fluent-prototypes-history) from the Verge: This is a fun 10,000 foot view of some of the work I'm involved in at Microsoft.
- [**_Oh, bi the way #1_**](https://medium.com/@herong/oh-bi-the-way-1-67b37dba6d9d) by Heron Greenesmith: My pal Heron started a column about bisexuality and I'm mostly just looking forward to seeing her slay this space. Heron is always a thoughtful and considered writer and twitter-screamer about sexual identity, bisexuality and LGBTQ+ topics. 💖💜💙
- [**_17 Books by Queer Asian American Writers_**](https://electricliterature.com/17-books-by-queer-asian-american-writers/) from Electriic Literature: One of my favorite books _The Incendiaries_ from R.O. Kwon was featured on this list and a lot of the recommendations immediately went on to my Amazon wishlist (which is essentially just a bookmarking tool at this point).

### Books 📚

- [**_Atomic Habits_**](https://jamesclear.com/atomic-habits) by James Clear: Not sure how I feel about this book, but I'm giving it some attention. The idea is that making small shifts in perspective, adopting micro behaviors can have macro impacts on your real goals. Like most self-help books and books about motivation and goals there are a swarm of baseball metaphors that I don't understand. ⚾️
- [**_Meet Me in Atlantis_**](https://www.amazon.com/Meet-Me-Atlantis-Obsessive-Sunken/dp/0525953701/ref=tmm_hrd_swatch_0?_encoding=UTF8&qid=&sr=) by Mark Adams: I've had this on my shelf for a couple of years, I tried to make it my train book, but when I was commuting it was too early to read. This book is essentially the author, collection, contextualizing and presenting the assorted theories around the location of Atlantis and the disparity between these theories. It's interesting enough, but it's been sitting beside my bed where I try and get through a chapter every night. It's a very different genre than I'm used to and that's a good challenge 😉.
- [**_Marvel Comics: The Untold Story_**](https://www.amazon.com/gp/product/0061992119/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1) by Sean Howe: This is the audiobook I listen to when I'm at work or I'm coding. Howe goes through the whole history of Marvel comics, its formation, infighting, conception of popular characters and different eras of their publication history. The audiobook is pretty easy to drown out and the paperback is WAY better.💥
- [**_Nova: The Complete Collection Vol. 1_**](https://www.amazon.com/gp/product/1302911341/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1) by Abnett & Lanning: With the rumors about a Nova feature film in Phase 4 of the MCU, I thought it be interesting to actually read about his origins. I'm personally hoping Nova, Richard Rider, is the first "promised" openly queer 🏳️‍🌈 Marvel superhero but this gives me no indication of that. It's just false hope 💔. Anyway the story is interesting, it moves along well, keeps you engaged in what happens next and begins with the aftermath of the destruction of Xandar. So it's predicated on the "Oh shit, what do we do know?" plot device.
- [**_Doctor Strange Vol. 2: Remittance_**](https://www.amazon.com/gp/product/1302912348/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1) by Mark Waid: Speaking of comics, I'm super into Doctor Strange. I seriously bought at least 4 collector's editions of Doctor Strange. 👨‍⚕️🌀

## Watch 📺

- [**_Every Way to Cook an Egg (59 Methods) | Bon Appétit_**](https://www.youtube.com/watch?v=qWAagS_MANg): I seriously watched this 4 or 5 times and tried MANY, MANY of the methods described here. 🍳🍳🍳🥚🥚🥚🥚
- **_[Match Chain Reaction VOLCANO ERUPTION Amazing Fire Domino 2](https://www.youtube.com/watch?v=-kMrXH84ZcI)_**: GREEN FIRE 🔥🔥🔥🔥
- [**_Play Date_**](https://play.date/) from Panic Inc.: I just want one. Is that so wrong?
- [**_Google Stadia wants to be the Netflix of gaming_**](https://www.youtube.com/watch?v=VAlliyFZtXc) from the Verge: I really want Google Stadia to exist and to be affordable. I've been obsessed with the idea and just waiting for the details to drop.

---

That's all I got, maybe I'll do this again!


Weeknotes No. 1


Being on the internet, I've started to hear this word "serverless", a lot. And like most people I pointed out the weird obvious issue with it having servers. But more the point is that it's not a server that you don't have to manage. Instead of a server that just runs your app continuously with a defined start and stop, it's a single _lambda_.

_Lambda_ wasn't really a term I had heard or understood. A lambda is a lot like an anonymous function. Your server becomes a single function that responds to an event with a context, like a request. That function executes only when it's called and doesn't need to be run continuously waiting to be pinged.

### So, We Might Have a Problem Here

Zeit's project "Now", which I've used almost since the beginning, moved to this serverless concept for deployments, offering cheaper, faster deployments all around with their [Now v2](https://zeit.co/blog/now-2). And I use this service heavily for [Downwrite](https://next.downwrite.us), (which is forever in alpha / beta).

Side note: One of their other big projects, Next.js also migrated to a [severless pattern](https://nextjs.org/blog/next-8#serverless-nextjs) for server-side rendering your React application.

This presented a challenge because my API server, uses [Hapi.js](https://hapijs.com/) which doesn't use a single function by default to run. You instantiate a class and call `start()`:

```js
const server = new Hapi.Server();

const init = async () => {
  await server.start();
  console.log(`Server running at: ${server.info.uri}`);
};

init();
```

You attach routes and controllers to that server and when you ping one of those routes, Hapi responds. Hapi geniunely makes working on a REST API server very organized and very easy to grow, while being an absolute joy to use. Routes are easy to define in an object, controllers are usually very simple, it builds authentication models to each route, and you just pass an array of those route objects to your server:

```js
server.routes([
  {
    method: "POST",
    path: "/settings",
    handler: async (
      request
      h
    ) => {
      const id = request.params.id;
      const { user } = request.auth.credentials;

      return await db.find(id)
    },
    config: {
      cors: {
        origin: ["*"],
        credentials: true
      },
      auth: {
        strategy: "jwt"
      }
    }
  }
]);
```

And all of this works great if your server starts and stops. But serverless functions are reactive, they're called and return a value. Serverless functions, especially on Now, work more like this:

```typescript
import { IncomingMessage, ServerResponse } from "http";

export default async (request: IncomingMessage, response: ServerResponse) => {
  response.send();
};
```

They respond to an event versus running and waiting to be called.

With the way things stood before, that code running on these deployments would cause every request would time out and run continuously, driving up my bill and not serving my users.

### Oh Wait, It Doesn't Need to Be

Zeit also have a framework for Node servers called [micro](https://github.com/zeit/micro), which for all intents and purposes, follows this serverless model and gives helper functions for processing the body of an incoming request.

Hapi has an idea of an `inject()` method, where you pass it a payload to your server class and it calls the specified route and that route's controller and returns the expected result.

> Injects a request into the server simulating an incoming HTTP request without making an actual socket connection. Injection is useful for testing purposes as well as for invoking routing logic internally without the overhead and limitations of the network stack. -- [Hapi API documentation](https://hapijs.com/api#-await-serverinjectoptions)

Even though it's "useful for testing purposes" it really fits the needs I have for working with my serverless deployment target.

```typescript
import { send } from "micro";
import * as Hapi from "hapi";
import { IncomingMessage, ServerResponse } from "http";
import routes from "./routes";

async function createServer(port?: number): Promise<Hapi.Server> {
  const server = new Hapi.Server({
    port,
    routes: { cors: true }
  });

  server.route(routes);

  return server;
}

export default async (req: IncomingMessage, res: ServerResponse) => {
  const server: Hapi.Server = await createServer();

  const injection: Hapi.ServerInjectOptions = {
    method: req.method,
    url: req.url,
    headers: req.headers
  };

  const response = await server.inject(injection);

  send(res, response.statusCode, response.result);
};
```

Now, adding micro allowed me to make LITERALLY NO CHANGES to my routes or controllers and use all my original server code while allowing me to respond more nimbly to each request.

My tests were easier to write now that my server was an instance returned by a function:

```typescript
describe("Endpoints", () => {
  beforeAll(async () => {
    db = await prepareDB();
    server = await createServer(9999);
    server.start();
  });

  it("can create a user", async () => {
    const R: Axios.AxiosResponse<ICreateResponse> = await Axios.default.post(
      "http://localhost:9999/api/users",
      {
        ...createdUser
      }
    );

    token = (R.data as ICreateResponse).id_token;
    user = (R.data as ICreateResponse).userID;

    expect(R.status).toBeLessThanOrEqual(300);
  });

  afterAll(async () => {
    await server.stop();
    db.disconnect();
  });
});
```

My only real gotcha after this was starting Mongoose (a Node adapter for MongoDB), it needs to be started and stopped after each request.

### Conclusion

Serverless was a new concept for me but it wasn't as hard as I was making it out to be. Finding the right tools enabled to me to leverage all the code I had and ultimately a better experience to work with. You can see the source code for this and the rest of Downwrite on [GitHub](https://github.com/charliewilco/downwrite).


Going Serverless


Gonna go out a limb here and say I have had and still have some very modest level of caffeine addiction. Most offices I've worked in have unlimited collections of coffee, tea, soda, all free for the taking. Which to a man who doesn't value moderation, can be more than a little problematic.

In college, I never really liked coffee, so I guzzled Diet Coke (this was before Coke Zero was a thing) and many, many Red Bulls. My partner was really concerned about all the Red Bull. They read a lot about the effects of all the energy drinks on the market and persuaded me to replace it with something more natural, hence the coffee.

I started to notice two things: I was not focusing super well or really sleeping anymore, and I was very tired sporadically throughout the day. But I shrugged it off long enough, I told myself that I've always had these two problems but something in me snapped.

In the middle of November, I quit drinking caffeine. Full stop. Yes, this had some pretty gnarly withdrawal symptoms and godawful side-effects. I had throbbing headaches for more than a week, and I almost vomited twice. I had a series of meetings that I had to sit through all week, and imagined nothing but crawling into the deepest darkest hole with Tylenol, all six seasons of _Downton Abbey_ and a giant, tersely-worded "Do Not Disturb" sign.

For a point of reference, on an average day I was consuming roughly 500-600mg grams of caffeine. This took the form of 1 French press of coffee, 5 to 7 cans of Coke Zero and one or two cups of English breakfast tea; some days more, some days less (but not much less).

When the more adverse withdrawal stopped things started to level out. I slept phenomally for three nights in a row. I woke up and I was alert, I fell asleep so easily. Then the tiredness throughout the day I was experiencing before, came back. Except this time, only really drinking water and seltzer, I'm starting to realize I wasn't tired, I was really dehydrated. The energy came back and I had more focus again.

I started moving my phone out of my bedroom at night. It got recommended to me a lot. This separation started to help a little bit in the beginning, but I think it was the disconnect from anything on the phone itself that was helping more. As I did this more often, I noticed an actual improvement in my sleep quality.

About a week before Xmas, we had a deadline at work. I went back to pounding caffeine: 2 cups of coffee, four cans of Coke Zero, two days in a row. The results were interesting. My stress level was higher, my headaches were worse, I wasn't more focused, just more annoyed; I had a momentary burst of energy without a whole lot of focus, just nervous manic energy. So it was back off it again.

Then for Xmas, I visited my family in Pennsylvania, which included a major time-zone shift, a 3 hour difference. The jetlag killed. I was wide awake at 1AM which in Seattle was 10PM. This pattern continued to be hard to shake for the whole week even having small amounts of caffeine and Melatonin.

After all of this, we're 6 weeks out from when I started this little experiment, and I'm not sure what it is: correlation vs causality. Is it the presence of more water or the absence of caffeine / fake sugar? No clue; this far out, I feel genuinely better only having a quarter of the caffeine I was having before and that's where I'm going to stay: small amounts of coffee or tea with copious amounts of water.


Quitting Caffeine


Server-side rendering a React application can have a lot of moving pieces. We'll look at the basics of server rendering those applications and the needs our applications would have.

But what is server-side rendering and why should I change my application to adopt this?

Server-side rendering your React application means leveraging a server to send an initial render to your client. I like to think of this as one hand washing another. Typical client-side applications send your user an empty `<div>`, a single bundle and a 🙏. This leads to your user having to wait for that bundle to load and parse before we get to an initial paint. Studies have shown, this leads to mistrust of your brand and confusion of your UI on your user's part. Because we go to the URL, see an empty screen, then a loading state, then our application.

Consider the application below, it's a simple list view that show's the latest

<figure>
  <img src='/images/posts/CRA-loading.gif' alt='A gif of an application, loading' />
  <figcaption>URL -> empty screen -> loading state -> data -> useful application</figcaption>
</figure>

### Rationale

Single page apps, have historically use the browser as the runtime, often sending an almost empty `<body>` tag and bundled JavaScript file to execute and essentially boot the application. In re-reading [_Isomorphic JavaScript: the future of Web Apps_](https://medium.com/airbnb-engineering/isomorphic-javascript-the-future-of-web-apps-10882b7a2ebc) from 2013, a lot of the problems Spike Brehm outlined for single page applications are still relevant.

1. Single page apps have a single point of failure.
2. Single page apps lack effective SEO.
3. Single page apps suffer performance concerns.

In [_7 Principles of Rich Web Applications_](https://rauchg.com/2014/7-principles-of-rich-web-applications) from Guillermo Rauch, published in November 2014, he outlines the fundamental ideals that should govern building web applications that confront indirectly the concerns from Spike Brehm. His first remedy is ["Server rendered pages are not optional"](https://rauchg.com/2014/7-principles-of-rich-web-applications#server-rendered-pages-are-not-optional).

In using a pattern for server-side rendering your application, you typically can have one hand washing the other. We get an initial render from the server, which includes our previous script tag and React "hydrates" our client and takes over from that initial static render.

This serves the purpose of being able to serve open graph tags in the `<head>`, content to scrape, which beyond SEO makes sharing URLs easier, and more importantly, it gives the client some real context to your application and immediate feedback.

### One Hand Washing the Other

In a basic setup, instead of calling returning some JSON data, we're going to call `renderToString` from `"react-dom/server"`

```js
// server.js
import express from "express";
import React from "react";
import { renderToString } from "react-dom/server";
import App from "./components/App";

const app = express();

app.get("/*", (request, response) => {
  response.send(template());
});

app.listen(3000);

function template(props) {
  const app = renderToString(<App {...props} />);
  return `
        <!DOCTYPE html>
        <html>
        <head>
            <meta charset="utf-8">
            <title>React SSR</title>
        </head>

        <body>
            <div id="root">${app}</div>
            <script src="./client.js"></script>
        </body>
        </html>
    `;
}
```

The `content-type` in Express.js will infer that you're sending pre-formed HTML not just a string of HTML and we need to start this Express server.

```bash
node server.js
```

Now we need to make an adjustment to the client application:

```js
import React from "react";
import ReactDOM from "react-dom";
import App from "./components/App";

ReactDOM.hydrate(<App />, document.getElementById("root"));
```

Instead of calling `ReactDOM.render` we call `ReactDOM.hydrate`. This does the same thing as a render, expect better, it gives cues to the renderer as to what do with that initial render from the server.

So far that's all the implementation we need to get started. But there are

#### Design Considerations

- **Components only has a truncated lifecycle: `constructor()`, `UNSAFE_componentWillMount()`, `render()` 😳**. For the initial server render we don't have the full lifecycle that we're used to on the client. This makes a lot of dynamic work like fetching data, subscribing to a store, adding a listener of any kind, go right out the window; (well lack of a `window` really).
- **Essentially: we don't have `setState()` 🚫**. We can initialize state in the constructor, call the initial props inside that state, but we can't call setState in `render()` or `constructor()`.
- **`matchMedia`, `localStorage`, `fetch` are all gone, kinda ☠️**, since we're rendering on the server none of the things on the `window` object. We can mock out globals like `fetch` easily enough with packages like [**isomorphic-fetch**](https://github.com/matthew-andrews/isomorphic-fetch). If we need some data from the client, safest bet is use a [query parameter](https://expressjs.com/en/guide/routing.html#route-parameters) in the URL or in a cookie.

#### Fine Print

JSX isn't valid JavaScript. So when you call your component inside of `renderToString()`, you're going to need to transpire that code first. So you will need a server bundle and client bundle.

#### Routing

We're using React Router, I'm willing to bet your application uses that too. React Router uses the History API and `window.location` to determine what components to render on the client. But you can do same thing on the server, so that your server render, renders the view being requested by the user.

To get started, hoist wherever you're calling `<BrowserRouter />` to the very top level where you call `hydrate()`. Then, call `<StaticRouter />` on the server.

```js
ReactDOM.hydrate(
  <BrowserRouter>
    <App />
  </BrowserRouter>
);
```

```js
renderToString(
  <StaticRouter>
    <App />
  </StaticRouter>
);
```

Now we can pass the URL being pinged and render just that page for the client. The request header from Express has the URL.

_Side note_: We have to give `StaticRouter` a context object to give the client from the server. It can be an empty object.

```js
function template({ location, ...props }) {
  const context = {};
  const app = renderToString(
    <StaticRouter location={location} context={context}>
      <App {...props} />
    </StaticRouter>
  );
  return `
      <!DOCTYPE html>
      <html>
      <head>
          <meta charset="utf-8">
          <title>SSR</title>
      </head>
      <body>
          <div id="root">${app}</div>
          <script src="./client.js"></script>
      </body>
      </html>
  `;
}

app.get("/*", (request, response) => {
  const markup = template({ location: requet.url });
  response.status(200).send(markup);
});
```

#### Data-fetching & Authentication

In our example from earlier, our initial client render showed a loading spinner, when the component mounted we made a `fetch` request and when data comes back from the API we render the data. But we can hoist this function that calls the API, call it on the server and avoid the loading spinner all together.

We start here by just isolating the API request.

```js
// api.js

const URL = "https://github-trending-api.now.sh/repositories";
export const getRepos = async (...args) => await fetch(URL).then(res => res.json());

// component.js

class Container extends React.Component {
  state = {
    repos: []
  };

  async componentDidMount() {
    const repos = await API.getRepos();
    this.setState({ repos });
  }

  render() {
    const { repos } = this.state;

    return repos.length === 0 ? <Spinner /> : <RepoList repos={repos} />;
  }
}
```

Then on the server:

```js
async (request, response) => {
  const { TOKEN } = req.cookies;
  const data = await API.getRepos();

  response.send(template({ repos: data }));
};
```

Now we have that data making our initial render full of content that's valuable to the user instead of the loading spinner.

The only hole left in this is duplicate fetches. We need to check if that data exists first. The best way to do that is this detailed technique from Tyler McGinnis in [_"Server Rendering with React and React Router"_](https://tylermcginnis.com/react-router-server-rendering/). Essentially:

1. Serialize the data in your template literal and assign it to something like `window.__INITIAL_DATA__`
2. Check to see if there's something on that key
3. When it's time to actually fetch more data on the client, remove that key off the `window`

In that example, we've separated the data fetching from the component. Sometimes you'll want to see maintain coupling a component's data fetching to the implementation. It is possible but it's a little 😖. Next.js uses this pattern with a static method called `getInitialProps` which abstracts the hardship of coupling to the framework level. In order to couple, we need to be call that externally from the component anyway.

You can also make authenticated API calls if you're using a token based system. When you store your token in your cookie, your 🍪-based authentication allows you to be able to grab your token from the server and call the same endpoint as that user.

```js
async (request, response) => {
  const { TOKEN } = req.cookies;
  const data = await fetch("endpoint/", { headers: { Authorization: TOKEN } }).then(res =>
    res.json()
  );

  response.send(template({ data }));
};
```

#### Hooks and Suspense

[Hooks](https://reactjs.org/docs/hooks-intro.html) are a new API coming to React. They make previously stateless function components, stateful without the trouble of the class API and lifecycle methods. Given our design considerations, Hooks, give their default value when rendered on the server.

```js
const ThemeContext = React.createContext({ dark: true });

function App(props) {
  const [open, setOpen] = React.useState(false);
  const context = React.useContext(ThemeContext);

  return (
    <div
      className="App"
      style={{
        background: context.dark ? "black" : "white",
        color: context.dark ? "white" : "black"
      }}>
      <h1>Hello {props.name}</h1>
      {open && "I AM OPEN"}
      <button onClick={() => setOpen(!open)}>Toggle</button>
    </div>
  );
}
```

In this example, theme is set to `true`, the open state is set to `false`.

Suspense is another API coming to React. It allows you to suspend rendering your component until a resource is available. I honestly can't get a good pulse on the implementation of server-side rendering. My hope is that it simplifies things by just making the data fetching functions fire on the server without any configuration.

[In this video](https://www.youtube.com/watch?v=z-6JC0_cOns), Andrew Clark details an experimental implementation of Suspense and server-side rendering. But I'm still waiting for a clearer implementation to emerge 🍿⏱🌷👏⚡️🔥.

### Super Professional Expert Opinion

**Don't travel this process alone 🚀.** You should be using a framework 🛠 to handle the rougher edges of things like routing, data-fetching and bundling. I recommend [**_Next.js_**](https://nextjs.org/).

But here are a couple other frameworks that stand out:

- [Razzle](https://github.com/jaredpalmer/razzle) + [After.js](https://github.com/jaredpalmer/after.js)
- [faceyspacey/react-universal-component](https://github.com/faceyspacey/react-universal-component)

Not surprisingly, Next.js handles a lot of the issues I've been describing in a very elegant way to shift your focus back to your product vs managing all these concerns. Besides this, it works well _today_ without waiting for new APIs to land.

### Slides

I was very glad to have given this as my first talk at [Seattle.js](https://www.meetup.com/seattlejs/). You can see the slide deck [here](https://seattlejs-server-side-react.now.sh/), (I totally built this with [mdx-deck](https://github.com/jxnblk/mdx-deck)).


Server-side React


I feel like I've been falling into front-end engineering roles for years. I'm mostly self-taught (and that story is detailed [more here](/writing/a-defense-of-frameworks/)). Some concept or problem never quite clicked right, something I don't know how to describe well or even understand. I shrug it off, I get back to the job at hand, fervently googling, finding a good fix and moving on. Lately, I'm noticing I want to grow more deliberately versus as just a byproduct of my experience.

Don't get me wrong: **_practical experience is good_**. Top shelf; would recommend.

But I don't feel like I grew as an engineer as exponentially as I wanted to and I didn't know what to do other than getting a CS degree (which I didn't feel like investing time or money in). Or more succinctly, I plateaued on experience. So I started working with different senior engineers and seeking advice and cobbling together something of a curriculum.

This post is basically 5 quick behavior changes and shifts in thinking that have helped me grow more as an engineer in the last summer.

If you wanna save some time, watch this older [talk _"JavaScript Masterclass"_](https://www.youtube.com/watch?v=v0TFmdO4ZP0), by Angelina Fabbro from JSConf US 2013. I watch it pretty regularly and still learn a lot from it, every one of her points is still relevant 5 years later. Below are things I've been trying to do, most of those come from that talk.

### 1. Read the Source Code

**Read the source code of the projects you use**. I use React almost everyday, [Next.js](https://nextjs.org/) just as much. I spend time browsing these repositories a lot. I don't understand all the code I read; that's okay. Occasionally I learn something.

This process takes about 20 minutes, a few times a week of the projects you use. With Next.js I found settings that weren't well documented, I understood more about the way data-fetching works in that framework and more importantly made sense of _work I was currently doing_.

I feel like you'd get more diminishing returns on projects you don't use or care about. Like if I read Angular's source code, I wouldn't necessarily get any value from it, because I have never used it.

### 2. Spend Time in Another Language

JavaScript is my first programming language. I worked in PHP for a little bit, but primarily just JavaScript. But I get tunnel visioned since I know how to get things done without having to think too much about it. Spending time in another language, where that cursory knowledge doesn't exist, forces you to rethink why you're making the choices you're making.
Vacation in another language; ReasonML and Elixir are pretty damn cool and so is Python or C#.

Coming back to the work you do every day, knowing why the pipe operator exists in Elixir or why C# has namespaces or how immutability works in Python, has made me appreciate JavaScript more and want to see the overarching design patterns in programming.

### 3. Test &mdash; Let the Errors Guide You

This one feels like common sense. This is more of a shift in perspective. Errors used to piss me off, so, so much. I watched a preview for Ben Orenstein's [_Refactoring Rails_](https://www.refactoringrails.io/) course and one guiding principle was:

> Write the code you wish you had. Let the errors guide you.

First, this makes me want to write more unit tests that are unit tests and not [pinning tests](http://wiki.c2.com/?PinningTests); meaning that tests cover the objective versus the hyper specific implementation you have. Then, it gives me a different way to look at errors, instead of angry demands from a cold indifferent universe but as guide-posts towards code I want to have in my project.

Static analysis is often a great stop gap to testing and arguably can give you more immediate and relevant value than unit testing alone. I had to learn TypeScript when I started my current contract. The process of learning how to use TypeScript made me rethink how I want to write JavaScript to make sure my code is easier to read, share and annotate.

### 4. Learn Big O Notation

Big O is the runtime of an algorithm. It measures how long a piece of code will take to run, the input and how much memory they use. There are different types of algorithms: Constant, Linear, Quadratic, Logarithmic, Factorial. The more iteration, the longer your code needs to run.

To be honest, I don't understand this concept really well. My main take away was that arrays and for loops were not a great answer for everything. Sometimes Maps and Sets in JavaScript were better answers and led me to spend time reading and finding ways to implement them. But the awareness of other options makes a huge difference, in that you're less isolated with the wrong primitives.

If you want to read something about Data Structures and Big O read [_‌Itsy Bitsy Data Structures_](https://github.com/jamiebuilds/itsy-bitsy-data-structures), by Jamie Kyle. It makes these difficult concepts easier to understand.

https://medium.com/cesars-tech-insights/big-o-notation-javascript-25c79f50b19b

### 5. Try Vim

This is more of a bonus. Lately, I'm using a Vim mode inside VSCode because my team really loves the workflow with shared settings; I really miss terminal Vim.

But working in Vim makes you think about how you navigate around a file and how inefficiently you move. Vim uses an idea called "modal editing" which means you update text by switching in and out of modes. Normal Mode doesn't allow you to type, where Insert mode actually allows you to add code to your file. The common wisdom is that you don't live in Insert mode but you should _normally_ be in Normal mode and this switch just causes me to be more deliberate about what I write. It's just a mental switch.

---

That's all I got so far. Small behavior changes and shifts in thinking. As always: YMMV.


Exponents


I love this site. I love working on it and planning / writing posts. But like anything we love, it can fall victim to neglect.

I made two major updates:

1. Removed custom fonts.
2. Added a dark mode.

Now I loved and still love the previous font I used, Operator Mono, I still use it for my editors, but it didn't make sense anymore. It makes an extra request and [system fonts](http://markdotto.com/2018/02/07/github-system-fonts/) are good enough for GitHub.

Dark modes are cool. macOS has an official dark mode, Twitter has a dark mode, YouTube; this list goes on and on. This website needed one. My implementation of this uses React's [Context API](https://reactjs.org/docs/context.html) and localstorage to add a class onto the `<html>` element and swap the [custom properties](https://arwhd.co/2016/09/09/css-variables/). Gist of that [here](https://gist.github.com/charliewilco/aa2528ba0d47a79739a0c046ae0b735c).

I've written a lot of blog posts over this past year, some of which I've shared because I haven't really finished them or didn't think them through all the way. Definitely working on that. But I'm essentially backfilling those posts, from the date I wrote the bulk of them. Also, I migrated some of the older content from [ARWHD](https://arwhd.co/) and my [archived site](https://archive.charlespeters.net/).

Hoping the minor tweaks encourage me to write more.

### Open source

Content notes aside, I finally open sourced the code on this site. It's available on [GitHub](https://github.com/charliewilco/charlespeters.net). Over the years, it's used WordPress, Jekyll, Metalsmith and now Gatsby. I finally have a build pipeline and deployment system that makes me really happy. I push to GitHub, I merge to master, it builds in Travis CI and deploys to [now](https://zeit.co/now). I used to manually FTP into a WordPress hosting setup and move files, then GitHub pages and a few other implementations. Now, I have something a little more sturdy and less error prone.


Small Updates


Four years ago, I worked at an agency and oh my did I write a lot of CSS. From project to project, a lot of CSS would have a lot of commonality. Patterns emerged, I needed custom buttons, a page wrapper, a flexible grid system, a type scale. I open sourced them on GitHub (because who hasn't ran down that rabbit-hole in the name of GitHub stars and immortality) and made them easy for me to find and update (well not so much update). I started to find that I'd need these in almost ever project I touched, from job to job. A lot of these patterns never changed much.

In building these patterns, I found the language underneath really rigid to work with and the environment pretty unintuitive. A lot projects tried to fix this and no matter what preprocessor or abstraction came along, the underlying problems remained:

- Flawed language features
- Admittedly bad early design features
- Browser adoption of critical features
- The Cascade
- String matching as inheritance

CSS has a low barrier to entry. It's easy to read and doesn't have a whole lot of different variation to the language. You define a selector (an element, an id or a class) and attach a map of declaration styles to it. With that low barrier to entry, some of these "problems" come from having that simplicity come with a lot of power, like the cascade.

Don't get me wrong. This is the only real option we have to style the web. In one way or another, either through a pre-processor, a CSS-in-JS solution, we eventually get CSS somehow. But that begs the question, how do we work in it if it's riddled with flaws? I've gotten to a point of real frustration and solutions that don't tackle the issues at hand and I'm honestly not sure what will.

So I'd like to outline what hasn't historically worked well for me and document why I feel it hasn't. A lot of this is for the purpose of collecting my own thoughts in one consolidated place versus shitposting to the nth degree on Twitter versus suggesting what might help going forward.

## Finger Pointing

_Wait, if you know CSS you solve all those things you just listed as "problems"_. I would say that's true, also in the same sense if you rig an election, you can also say you won the race. Of course, knowing CSS, having experience with language and the various hacks and CSS patterns will give you the ability to be semi-productive in shipping; that part isn't in dispute.

### String Matching

Okay, so we can't do much about browser adoption or about what happened in 1996 so please explain the inheritance issue.

So let's take this given CSS and markup:

```css
.Module {
  background: goldenrod;
}
.ModuleOther {
  background: aqua;
}
.Module {
  background: pink;
}
#uniqueID {
  color: blue;
  background: red;
}
```

```markup
<div class="Module ModuleOther" />
```

Here's a [demo](https://codepen.io/charliewilco/pen/MBLyJj?editors=1100).

Dollars to doughnuts, that `<div>` is a wonderful shade of browser default pink and not aqua much less goldenrod. Classes aren't immutable values. They can be overwritten very easily.

The order of declarations being written in the stylesheet matters so much more than when it's being "invoked" onto the element. The element should have been aqua.

Now that coupled with you can increase the specificity of the selector:

```css
div.Module.ModuleOther#uniqueID {
}
```

_Side note: I will never understand why developers who wrote CSS ever felt the need to call a selector `div.className`. I know what it achieves, but it always looks and feels like a hack. You don't gain anymore semantic value and you make your elements harder to refactor. I don't always know that this module will be a `<div>` and, I don't know, it's always felt weird to me. But then again I didn't start writing CSS until 2011._

This is by far my biggest issue of the design and implementation of CSS. I understand how to work around this through a discipline (either a naming structure), it's just very difficult to enforce or communicate those disciplines. Linters are one thing, but it's also the easiest thing to ignore when you're trying to ship a feature.

On top of that, when we depend on class names to be present or absent in our UI we're trying to application logic, we're setting ourselves to have unpredictable application state. I mean something like detecting if an element contains and `.active` class. I've shipped code like that to prod and I've regretted it and it's created really WEIRD BUGS.

### Cascade

Okay, here we go again, let's attempt to find some territory that all the other the blog posts and conference talks and think-pieces haven't.

I like the Cascade, but only when it helps and only to a point. I just don't like how inconsistent it is. At the root of the document I can set a global typographic style to my application. Something like:

```css
html {
  font: 400 100%/1.6 system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica,
    Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
}

input,
textarea,
select,
button {
  font-family: inherit;
}
```

With that snippet, everything in my application is now set to use the same typeface, it's a nice default to work with. But it only applies to a subset of surface properties, not layout properties.

For instance if I also styled html like this:

```css
html {
  padding: 1rem;
}
```

[Demo](https://codepen.io/charlespeters/pen/mjvgdO).

I could use the wildcard selector `*` to set everything to have a padding, but it applies to everything and isn't a component of the Cascade feature of the language. Simply put, it works, just not as a result of the cascade, just because it targets everything. The cascade is strongest when the relationship between nodes in the tree is very clear and it's often not in dynamic applications.

This doesn't seem like a problem when looking at the simple demos. At any scale beyond that magnitude, the cascade falls apart.

As the codebase grows and the number of components and different parent + child dependencies develop in your CSS, you fight the cascade constantly. We need the default text color to be `#333` but this module has a white background and the text inside of it needs to be `#202020`, and more more needs and changes arise without time to curate or take inventory.

At this point, I'm always wondering with a codebase: how do you know when to delete CSS that've you written? Because we have a cascade to work with, you have to run the code in order to know what it does. Over time, your stylesheets only grow, it's hard to know how to prune them.

Immutability would change this issue almost right away.

## Abandoning Solutions

Okay, I get it, this is a tough a garden to tend and weed; it's hard to manage and work with but still people manage and applications still get shipped almost continuously. Why not just cut straight to how to do that?

Okay, I will. Hang on.

The most common solutions to dealing with the language and implement flaws of CSS are two fold: strict naming methods and a rigid architecture.

### Naming Schemes

This is a common practice. It sounds super complicated but it's just a pattern that you choose to follow when you write a selector.

BEM is one such pattern.

```css
.Block__element--modifier {
  /* Declarations */
}
```

This makes it clear to the author, you're intending for a new set of styles, that are distinctly attached to a set of elements and variations. The relationship between the styles and markup are clarified.

Implementing a naming scheme in your CSS has just enough barrier to entry as authoring more CSS. It's something you can just chose to do.

_Side note: In practice using [Pascal casing](https://www.quora.com/What-is-the-difference-between-Pascal-Case-and-Camel-Case) makes scanning your work a lot easier._

Like I said before you can [lint](https://github.com/postcss/postcss-bem-linter) for it, but it's not an easy thing to enforce. Seriously, I've never had a manager who was cool with blocking a pull request because it failed some lint rule in the middle of a sprint and it's certainly not gonna make the rest of the team happy. But that's more an issue with the development more than the language, but still doesn't get fixed.

The bigger issue here is that these are strings, they're not immutable. I can very easily overwrite one of them. There are [tools to solve this type of analysis](https://github.com/johno/immutable-css) but that only points to one source of your CSS, your application can consume more CSS from third-party stylesheet.

### Architecture

Naming your CSS selectors is one thing, maintaining it over time is another. Maintaining CSS is a tough needle to thread, it's difficult on an agile team and it's more difficult when you don't decide how to add new CSS or how your CSS is layered together.

ITCSS is an approach that was put together by Harry Robert and I've outlined some details [here](https://obsidian.charlespeters.net/itcss). ITCSS defines "layers" of where and how certain styles should be grouped together. You have 6 layers:

1. **Settings & Tools**: Global Variables, mixins, functions
2. **Generic**: A reset or normalize for your CSS
3. **Elements**: Styles devoted to default HTML elements without classes
4. **Objects**: Non-visual modules, a grid, page container
5. **Components**: Distinct visual UI modules, cards, buttons, input groups
6. **Utilities**: Single use classes to override defaults

```css
/* Objects */
.Wrapper {
  margin: 0 auto 16px;
  max-width: 56.24rem;
  width: 100%;
}

/* Components */
.Button {
  background: #147aad;
  color: white;
  border: 0;
  border-color: transparent;
  padding: 8px;
  border-radius: 4px;
  transition: color 250ms linear, background 250ms linear, border 250ms linear;
  cursor: pointer;
  display: inline-block;
  font-weight: 500;
}

/* Utilities */
.u-red {
  color: #d04d36;
}
```

Employing an architecture ensures that the cascade is kept in check, because the order of each layer purposes overrides the previous and gives sufficient context to other engineers on where and how to add CSS into the codebase.

But again like a naming convention, it only matters when it's maintained / enforced / applied. This is also prone to error when you start to load in CSS after your main outputted bundle. If you're not in control of those styles, it's harder to know whether your structure works and because it's a practice, it's not easy to test or lint against.

### Functional CSS / f(css)

Functional CSS or _f(css)_, is a completely different solution to working with this language. It's a simple concept that treats every selector, like a pure function. A pure function, has a single input and output:

```javascript
function squared(x) {
  return x * x;
}
```

When that idea is applied to CSS, it translates into a selector only having a single or common value.

```css
.bg-red {
  background: red;
}
.px3 {
  padding-left: 16px;
  padding-right: 16px;
}
.tl {
  text-align: left;
}
```

This works because it only applies styles to the element that you made a conscious choice to apply versus inherit. [Tachyons](http://tachyons.io/) and [BassCSS](http://basscss.com/) are some of the front-running solutions in this space.

## Adopted Solutions

This is more about how I've adopted some of those solutions and my approach to authoring (or not authorizing CSS). For some perspective, I've worked on two agile teams that focused on shipping product bi-weekly, done agency work and have spent a lot of time prototyping solutions and features over the last 6 years.

### Level.css

For my mileage, having sensible defaults to work with at the beginning of a project is much easier. This addresses the first three problems I listed at the beginning of this post (back when I had credibility and hope). By using `box-sizing: border-box` and having forms inherit the global styling of the document, it's easier add modules with confidence and have the right things cascade (again not evil, just not always helpful).

[Link](https://charliewilco.github.io/level.css/)

### Obsidian.css

Obsidian.css is a solution that follows the ITCSS architecture and BEM naming convention and collects a lot of the early patterns from at least 1500 words ago before this blog post, well became this blog post.

Obsidian.css is a framework like Bootstrap but, I've mostly used it as a way to communicate to teams how we could and might structure our project and provide a point of reference to work from as we onboard new team members or start a new project.

[Link](https://obsidian.charlespeters.net/)

---

One thing I'm sure you're wondering at this point, is there anything beyond naming pyramid schemes and buying into architectures. And to be honest I'm not sure.

If human discipline is the only thing maintaining your API, you're trusting the worst and an incredibly flawed & brittle system to maintain your solution. And if don't believe that humans are the worst, I have a case study for you. It's called: Twitter.com.

My only real conviction at this point is removing the human decision making component (read [bike shedding](https://phinze.github.io/2014/05/24/useful-tech-terms-part-1.html)) from shipping UI. Meaning that automating, testing, and experimenting with new solutions should be a regular practice.

So you might be wondering if I specifically mean a CSS-in-JS solution. But can one of them salvage this at all? _No_, it cannot. Although, if you image CSS as a Diet Coke that's both flat and warm, essentially those solutions can give the illusion of bubbles, so kinda touches on one of those problems; but that's a different blog post.

I think the weakest part of CSS-in-JS, most CSS-in-JS solutions are coupled to an implementation like React or Vue, or to a build pipeline like through Babel plugins or certain Webpack settings. But this only seems to an issue for engineers writing applications that are bolted onto an existing application that doesn't have one of those pieces already. If you're building something more contemporary, you're already using one of these pieces.

But things like [styled-components](https://www.styled-components.com/) or [JSXStyle](https://github.com/jsxstyle/jsxstyle) where you're defining a component that represents a set of style and invoking that component applies those styles to the element, makes it much clearer as to how and when you can remove or refactor your UI. So at least checks a few of those boxes on my list.

---

2200 words later and you never really arrived a point other than solutions aren't all that great. Do you have any hope at all?

<figure>
	<img alt='GIF of Sherlock turning over in frustration to ignore people' src='https://media.giphy.com/media/BAWZwuWPdXneE/giphy.gif' />
  <figcaption>Nope.</figcaption>
</figure>

Honestly, my non-snarky answers are: be aware of the limitations of CSS, pick / enforce / maintain a solution whether it's ITCSS or styled-components or [TypeStyle](https://typestyle.github.io/) or BEM or Sass or some hybrid approach. None of these solutions is going be a silver bullet, there are no silver bullets to cast.

_Side note: But what doesn't solve the problem is picking a fight with a maintainer of one of these solutions and suggest they don't know CSS or too stupid to understand CSS; that never helps anyone._

The answer that I keep hoping for is _better primitives_ to work with on the web. I think React exposes a nicer developer experience and empowers a lot of great UI to be built without a lot of effort but I think the answer is not being bound to the DOM or to stylesheets and replacing them with something that isn't bound to either and exposes a different set of conventions.

## Further Reading

- _[Designer Oriented Styles](https://the-pastry-box-project.net/james-kyle/2018-january-22)_ from Jamie Kyle
- _[CSS and Scalability](http://mrmrs.cc/writing/2016/03/24/scalable-css/)_ from Adam Morse
- _[Creating the “Perfect” CSS System](https://medium.com/gusto-design/creating-the-perfect-css-system-fa38f5bcdd9e)_ from Lindsay Grizzard


I Just Can't with CSS Anymore


For the last week, I've needed something to distract myself with. So I started to notice (again) a lot of familiar chatter about front-end frameworks being the wrong choice for beginners, that beginners need to focus on understanding the fundamentals.

First, I want to say it's weird that we as a community do this. We don't do this with back-end frameworks. No one bats an eye referring to themselves as a Rails developer or a Phoenix developer or, **gasp**, a WordPress developer. Now that I got that off my chest, I can layout, my feelings in the clearest way possible.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Left: Long term investment.<br>Right: Don’t get too attached.<br>- <a href="https://twitter.com/adactio?ref_src=twsrc%5Etfw">@adactio</a> <a href="https://twitter.com/hashtag/aeabos?src=hash&amp;ref_src=twsrc%5Etfw">#aeabos</a> <a href="https://t.co/DoTatuLCen">pic.twitter.com/DoTatuLCen</a></p>&mdash; Greg Greiner (@greggreiner) <a href="https://twitter.com/greggreiner/status/1011603906361733120?ref_src=twsrc%5Etfw">June 26, 2018</a></blockquote>

Comments like this, really bother me. They give the implication that you aren't a qualified developer, "enough", or valuable to the longevity of your own work. This implication is a poison that goes way way way too easy.

### Frameworks give context to fundamentals

I started to learn to code in 2011. I picked up HTML and CSS because I had a professor that I hated. For the web design portion of my graphic design degree, he forced everyone to use Dreamweaver and if you remember that particular program, it was a nightmare to navigate and a lot of professional web designers told me that they "just used HTML and CSS in a [Coda](https://panic.com/coda/)". So I focused on doing that, my professor hadn't really designed a website in years or worked outside the world of academia in a decade so I didn't really trust him that much.

I honestly found HTML and CSS pretty easy concepts to pick up. CSS clicked a lot more for me than a program like Photoshop or Illustrator. Then, in the process I tried to learn JavaScript and I tried to read a lot of books on the subject. And I failed, miserably.

The onus of having to build something and provide value to the people I worked for and to the users we worked led me to different JavaScript frameworks. The classic: "well we have to build a dashboard, Heroku uses Ember.js for theirs, sounds like a good idea" -- as poor as those intentions I've had dozens and dozens of conversations just like that. So I took a tutorial on [Ember and Firebase](https://www.youtube.com/watch?v=Cs3Fdup7aUo). It put those fundamental parts of JavaScript in actual context, I quickly saw the difference between an Array and an Object, methods and functions because very obvious, class inheritance was something else entirely. But it enabled learning and way-finding within a manageable context and left me with a skeleton to build the _next thing_.

Fundamentals are great, but there are diminishing returns on basics. Building with a framework early vs from scratch you gain:

- Understanding the complexity of the application you're building
- The ability to see trade-offs early

### Frameworks enable productivity

I've written about productivity across a team with [CSS](/writing/i-just-cant-with-css). But the other side of that is lack of need to communicate the fundamentals of a framework or choices about conventions. This helps you focus on the problem your team is being paid to solve.

Even as an individual, clinging to a framework, things can very quickly become isolated as nails and your framework becomes a pretty powerful hammer.

<figure>
	<img alt="GIF of Thor with Hammer" src="https://media.giphy.com/media/Ch1zCx8tu6DQY/giphy.gif" />
  <figcaption>This makes you Thor. You get to be Thor.</figcaption>
</figure>

Not surprisingly, finding other people who are `{Angular,Vue,React}` developers trying to solve the same problems often exposes you to modules that are low cost to bring into your projects.

### Frameworks aid in a job hunting

I've only ever gotten jobs I really liked because they were hiring "React" developers. This had two benefits: showing me what I needed highlight in my skillset and gave me something to discuss in an interview.

Also from that experience, there's an pretty obvious benefit of working with frameworks that often goes underappreciated. I don't like Angular; not my thing. But because I know that, I can filter out all the jobs I don't want.

### Just Know _Your_ Edges

Find tools that make you productive in building the things you ultimately want to build or see exist. But you as an engineer have a finite capacity, you only have so much brain space, hours in the day. You have limits: edges. Understanding that you do, allows you to work with the capacity you have and not a projection of skills you're being convinced that you need.

### This is probably an unhelpful story

A good programming friend of mine, [Sean Washington](https://twitter.com/seanwashbot) and I have often chatted about the role of frameworks. He loves Vue. I can't get into it. He's indifferent to React, I don't think there's a day I'm not wondering if my component's are artisanal enough (you don't want them to unmount too soon, it takes care and patience, thank you for coming to my TED talk). At this point if Sean and I ever work together on a project, the framework doesn't matter. If one of us wants to prototype something for the other, that's the important part.

Because the reality is having worked in any framework that enables you to understand the underlying language it's implemented in, teaches you the language and good fundamentals and you gain more experience along the way.

Now, this React developer, this Next.js fanboy, this GraphQL gambler, has stuff to build.


A Defense of Frameworks


I remember watching X-men for the first time in the 90s. It came into syndication in my small town in Pennsylvania around 1999; I was 8. I loved it so much, the idea of a secret war, people who were fundamentally different than the totality of humanity and the yellow spandex.

I don't know where in my little 8 year old heart it came from, but I started to develop an infatuation with Cyclops. He very quickly became my favorite character. I became rather irritated with Jean Gray (Cyclop's wife), glad to see him in charge of the X-men, locked in scenes of bravery and adorned in that perfectly sketched yellow spandex. Episodes that featured him prominently were my favorites by default and ones I immediately wished I had taped (yea the days of VCRs). I very much wanted to be his very best friend and wanted Cyclops to accompany me to school and keep me company while I did everything. I was the only boy, with two other sisters who weren't much for company, I simply thought it would be perfect to have another boy around.

What I didn't realize at 8 was that this was my first innocent crush on a member of my own gender. I had been aware of other crushes I had on characters on TV before, like the pink Power Ranger and Melissa Joan Hart but it didn't really connect with me at that time that there was something more to the yellow spandex.

Skip forward a couple of years, my attraction to women wasn't nearly as mainstream as my peers. While other boys my age were lusting over Angelina Jolie's breasts, I was obsessed with Jenna Fischer's wit in the Office and her revolving ensemble of cardigans. This stark disparity was very evident to me, I often felt like I needed to overcompensate. I felt like I never belonged around boys my own age and like most outcasts, my behavior often invited ridicule and feeling out of place made me an oddity. "Gay" and "fag" were often the most commonplace appellations.

Fast-forward a little further ahead, on a break from a large evangelical university, I was 17 or 18, I was reconnecting with my former youth minister, we were walking in park by my house and I started to express that these desires I had felt for other guys and mostly attractions were existing along side those that I had felt for women. To this pastor, I had "come to Christ" and with him learned so much about Scripture, which fostered a deep reverence for the poetry in there and mercy Christ offered. He referred to what I felt as _"same-sex attraction"_ that it was a temptation like lust and should be avoided and resisted like any other temptation.

From my observations, conservative Christian circles often conflated lots of things about sex and desire. A lot of that territory to those in power and speaking / preaching on those subjects had a very unrealistic view of what sex and healthy desire was all about. That's not to mention the unhelpful shame, rhetoric and orchestrated behaviors that were largely unhelpful in resisting these "temptations".

So called _"same-sex attraction"_ didn't really encompass my experience and the materials I was given to read to make sense of it seemed like they didn't make space for me either. Much to my regret, I sat on those feelings for a few more years, not acknowledging them, not giving them voice of language. There persisted a churning of quiet shame over these feelings that I never felt good talking to other about. But the subject of lust and sex never grew cold.

Every conversation and prayer group that was just for "guys" focused on the fundamental idea that God was offended and intolerant of every erection we garnered, and masturbation was a trap in which temptation could become normalized and we'd become immune to hearing God's spirit, that our "future wives" wouldn't want to marry us and we were diluting God's mercy. That was a tough pill to swallow.

None of the gatherings gave me any hope about sex or sexuality in general. They all seemed to sell the idea that everything would work itself out in heterosexual marriage that followed an awkward rubric of criteria that made no sense.

In college, I studied the New Testament and deepened my love of the scripture and started to see deeper veins and stronger themes that echoed this idea that God was firmly in the business of embracing and reconciling all things to himself (Colossians 1:19-20). Being at a large evangelical university, lots of people had their minds made up about so many issues like homosexuality and gay marriage, along with gun ownership (because blessed are the piece makers) and abortion. I didn't have those convictions, and I loved scripture too.

But I could never find a Biblical or logical reason to understand why two committed adults who loved each other couldn't have a valid marriage. Or for that matter, why "sanctified" marriage needed to look like an almost autocratic ruler demanding a woman to be the sole subject of their reign and a combination of house-keeper/porn star/infantile subordinate.

Needless to say, I was very skeptical of vision of sexuality and marriage that Christianity had conjured so far.

Then I found the book of Acts. This book changed everything for me. In Acts, God calls a African eunuch to be baptized and sends an angel to one of his followers to "call nothing unclean that [He] had called clean" (Acts 10). The followers and friends of Jesus were being charged as these radical wildfire agents of His mercy who could not or would not get their shit together.

Then I studied the so-called "clobber passages" about homosexuality in school. These so-called proof-texts for claiming that homosexuality in any form was a sin and a super devious sin, did not seem to hold up to very basic scrutiny (silly things like history, context, audience). They didn't feel at all connected to the God who charged his people with tearing down the dividing wall of hostility (Ephesians 2:14) or was interested in reconciliation or cutting a new deal with His people. Every time I heard these passages read, they were laced with petty aggression and were so alienated from a God who governed all things (Isaiah 9:6) or a God who fearfully and wonderfully made his creation (Psalm 139).

In the last two years, I've started to look at this a little differently.

Let's assume or confess that more often than not that when people speak against homosexuality they do so using the Bible as a prop for their own prejudices and insecurities. And let's just work with the understanding that God is not surprised or offended by His creation. But above all, let's just carry on with the idea that God meant what was canonized in Scripture about mercy and about lines being crossable and about embracing those that are different.

Let's assume, that my desires to have sex with another man or have snuggled close to Cyclops as a young boy or that every early locker-room experience was not the cause of some uncontrollable sin that I need to fight against.

Could we assume God is not surprised by these desires? Yes. Could we reasonably infer that this was a fundamental piece of my fearful and wonderful creation? Sure.

Well, that changes literally fucking everything.

Bearing witness to my desire and identifying as queer has led me to a fundamental truth: God is a creator, fully aware of the intricacies of His creation and not at all surprised by my desires. That understanding my bisexuality is to understand the contours of His design of me and accepting a deeper invitation to His mercy, and that I was more than welcome no longer to feel ashamed or disgusted by any of this. 💖💜💙


Bi Design


In a typical React Component, you would render a child as another React Element.

```javascript
<Parent>
  <Children />
</Parent>
```

In the "child as function" paradigm, instead of returning an element below, we're using the Toggle component to have encapsulated state that's common to multiple components. Since this logic is repeated we can abstract it into its own class and call individual instances of it.

```javascript
class Toggle extends Component {
  state = {
    open: false
  };

  toggleOpen = () => this.setState({ open: !this.state.open });

  render() {
    return this.props.children(this.state.open, this.toggleOpen);
  }
}
```

Now we have an instance of Toggle we can repeat over and over again.

```javascript
const Accordion = () => (
  <Toggle>
    {(open, handleToggle) => (
       <div>
        <h1>Title<h1>
        <span onClick={handleToggle}>Show Details</span>
        {open && <Details />}
       </div>
    )}
  </Toggle>
)
```

So in our Toggle component, we're returning a function to be the only child, and passing in the state and a handler to that function. Then when we call an instance of it like in the Accordion or the Thumbnail, the state is encapsulated to this instance. This leaves the child component to be a stateless pure piece of UI, not knowing how it gets opened, only that it can be opened or closed.

Also this pattern gets called "Render Props", where instead of mapping the function to the `children` prop, it's mapped to a prop called `render` and called inside the JSX itself versus as a child. Render Props seems to be more of the conventional name for this pattern and now has [official documentation](https://reactjs.org/docs/render-props.html), but the idea remains the same.

```javascript
class Toggle extends Component {
  state = {
    open: false
  }

  toggleOpen = () => this.setState({ open: !this.state.open })

  render() {
    return this.props.render(this.state.open, this.toggleOpen)
  }
}


<Toggle
  render={(open, handleToggle) => (
    // rendered contents.
  )}
/>
```

### Why?

You might be wondering: this doesn't seem much better than just passing down state to a component or moving this into my store's reducer, so why should I bother? And I would counter: that was an obnoxiously specific question to ask of a blog post, let me see if I can give a simple response.

Our `<Toggle />` component is a really simple example and I'll demonstrate more in a moment, but it outlines a piece of UI logic that you only need to write one. Simplifying this logic allows you to compose with this idea versus reproducing it. There are loads and loads of UI components that need to be toggled: checkboxes, modals, accordions, dropdown menus. But all those are in reach by calling a new instance of `<Toggle />`.

Declaratively composing UI makes every logic decision verbose. Functionality lives in the Component tree, and when you're declaring those components or searching for your component later, you're documenting your choices more clearly.

React gets simpler when you stop adding things to it (ref: ["In the Mouth of the Beast"](https://charlespeters.net/writing/in-the-mouth-of-the-beast/)). Using "Just Components" can get you pretty far in a codebase without a lot of effort. In my experience, these patterns make on-boarding developers to a project more streamlined, since everything is being composed of declarative components (think pure functions). The verbosity is easier to take in and keep everyone on the same page. Beyond just that, it's in a parlance that people who already use React understand: Components.

### Using the Pattern

Below we're using rendering a list of results from a fetch call. We're using a function as child component simply to set the state of network call and as a child of that instance, calling our list.

```javascript
const List = ({ results }) => (
  <ul>
    {results.map((r, i) => (
      <li key={i}>{r.body}</li>
    ))}
  </ul>
);

class Fetch extends React.Component {
  state = {
    data: [],
    status: undefined
  };

  componentDidMount() {
    fetch(this.props.url)
      .then(res => ({ status: res.status, data: res.json() }))
      .then(result => this.setState(result))
      .catch(err => console.error(err, "Something else to handled this error like an adult"));
  }

  render() {
    return this.props.children(this.state.status, this.state.data);
  }
}

<Fetch url="https://jsonplaceholder.typicode.com/posts">
  {(data, status) =>
    status === 200 && results.length >= 0 ? <List results={data} /> : <span>{status}</span>
  }
</Fetch>;
```

Now every time I need to perform a `fetch()` request, I just have to call the component.

### A Few More Examples

Just so we're clear on the fact I'm not making this up, there's quite a number of use cases for this pattern out in the wild.

#### [React Media](https://github.com/ReactTraining/react-media)

> A <Media> component listens for matches to a CSS media query and renders stuff based on whether the query matches or not.

```javascript
<Media query={{ minWidth: 320 }}>
  {matches => (matches ? `I am at least 320px wide` : `I am not`)}
</Media>
```

#### [Downshift](https://github.com/paypal/downshift)

> Primitives to build simple, flexible, WAI-ARIA compliant React autocomplete/dropdown/select/combobox components

Downshift is one of those amazingly extensible components that you'd think is necessary to use some state management solution or require a lot of setup. I won't bother with an example snippet, because it's seriously worth it to go read those docs. Here's a demo of building a [simple autocomplete](https://codesandbox.io/s/M89KQOBRB).

#### [Holen](https://github.com/tkh44/holen)

> Declarative fetch in React

```javascript
<Holen lazy onResponse={handleResponse} url="api.startup.com/users">
  {({ fetching, data, fetch, error }) => (
    <div>
      <button onClick={fetch}>Load Data</button>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  )}
</Holen>
```

#### [Motion](https://github.com/chenglou/react-motion)

What `react-motion` does is it allows you to be able to interpolate style and puts the updating value through an animation within scope. I could be wrong, but I think this might be the original "Function as Child" component.

```javascript
import { Motion, spring } from "react-motion";

<Motion defaultStyle={{ x: 0 }} style={{ x: spring(10) }}>
  {interpolatingStyle => <div style={interpolatingStyle} />}
</Motion>;
```

---

Happy composing ⌨️ ⚛️ 👩‍💻


Function as Child

Kill Your IDE


I have worked with [React.js](https://reactjs.org/) for a while now. This library has gotten so much adoption, and it's no longer in its infancy. Major companies have adopted React as a core piece of their application beyond Facebook: Twitter, Airbnb, Dropbox, Walmart. It's here and I have the distinct impression it has more staying power than the adoption of almost any other framework or library.

But why do teams adopt React? I think it's a combination of working incrementally on UI and state management is weird on the client side. Since React has a very small surface area where its API is concerned.

The massive adoption led an increased assortments of different types of applications and vastly different needs centered around the simple API.

Managing state can be complicated but talking about it might be more complicated if we're not clear on what state is or represents in an application. What is state? State can be anything. It's a description of what's going on in your application. We can capture anything we want in state: is this modal open? did an error occur? what posts did our API respond with? is this setting on or off? what text is in this input field? We could be here awhile, so I trust you're starting to get the idea.

In React, Components compose other Components. and those components have descendants. Every component can manage its own state or be handed that state via a `prop`. You can lift up a descendant components's state to an ancestor.

In this example we're passing the state of `submitting` down the descendant and elevating the state of the `field` to the the Ancestor component.

```javascript
class Ancestor extends React.Component {
  state = {
    submitting: false,
    error: null
  };

  onSubmit = payload => {
    this.setState({ submitting: true });
    fetch("/endpoint", {
      method: "POST",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify(payload)
    })
      .then(res => res.json())
      .then(response =>
        this.setState(state => {
          let submitting = response.status === 200;
          return {
            submitting,
            error: !response.status === 200
          };
        })
      );
  };

  render() {
    return <Descendant submitting={this.state.submitting} onSubmit={this.onSubmit} />;
  }
}
```

In this component, we disable the input if the form is submitting so that input value doesn't change and on submission we grab the state of `field` for the fetch request.

```javascript
class Descendant extends React.Component {
  state = {
    field: ""
  };

  onSubmit = e => {
    e.preventDefault();

    this.props.onSumbit({ field: this.state.field });
  };

  render() {
    const { field } = this.state;
    return (
      <form onSubmit={this.onSubmit}>
        <input
          value={field}
          disabled={this.props.submitting}
          onChange={e => this.setState({ field: e.target.value })}
        />
      </form>
    );
  }
}
```

These examples are simplistic and obviously a little contrived. But what if we had to make this state known the whole of our application (we'll refer to this as application level or global state)? We'd have to continually pass state down from Ancestors many levels up, which can get nasty and hard to track and force us to use `shouldComponentUpdate()` to keep this in check so our more nested components aren't re-rendering unnecessarily.

As more applications grow and depend more on React the more global state we might need.

### Raising the Beast

One of the reasons I resisted learning React while I was working on an Ember.js application, was that at the time (mid-2015), a lot of promotion around React by other developers was always React + another library; React + [Flux](https://reactjs.org/blog/2014/05/06/flux.html), React + Alt, and finally React + Redux. React was getting billed as something to complement other pieces of an application architecture versus something that could stand on its own. The original React announcement was about using `Backbone.Router` and React at Instagram, whereas at the time Ember 2 and Ember Data was a complete solution for the application I was building, the subliminal message about React was it wasn't a solution outside of something.

So as someone not using React consistently and skeptical about changing my workflow or tools while I was already semi-productive, the message was to use React; you need a lot of other moving pieces to build an application.

Turns out that's not true. When building an application with React and using a polyfill'd fetch (which is available in most modern browsers), React Router (which is just some components) can get you pretty far with very little overhead.

I don't want to be dismissive of using Flux or Redux. A lot of teams have been very productive with these tools and built very cool applications with these tools.

But I think there's maybe a fundamental flaw in beginning with a state management solution versus growing into that need. One thing that I found true of my experiences working in an application using a global state management solution, is there's a [sunk cost fallacy](https://youarenotsosmart.com/2011/03/25/the-sunk-cost-fallacy/) associated with making these choices.

While I was working on a team using Flux and React, we had the constant conversation about trade-offs we made in previous sprints committing to building Flux stores and the boilerplate code we had to write to setup that pattern. The cost to eject was too high to consider refactoring when we ran into issues. Once we had this pattern setup, the temptation to continually add to the global stores was way too within reach and too hard to resist. This made our team mistrustful of using a Component's localized state to handle basic UI-level state (like toggling checkboxes and inputting text in input fields).

The other issues I kept finding to be true is that having `props` passed through the `connect()` method from Redux or the `Store.getState()` from Flux makes it harder to manage where the state we're passing down or handing to lower level components is coming from, and prevents us from naming things very clearly. Being verbose shouldn't be a crime.

In the 3 bigger applications I've worked on, complexity becomes a beast that's hard to tame. Then when it comes to adding features or refactoring components / reducers the understanding of which components get touched by your changes is harder to get a handle on and raises the cost and time of working an application over time.

### Getting Swallowed Whole

For most of 2017, I was working on an application that used Flux and React that we inherited from an offshore team. It was engulfed in Flux stores and getting global variables rendered from a .NET app sprinkled in the codebase. Each feature took whole sprints, technical debt was a little hard to calculate and unit testing was a little bit out of the question because the components weren't well defined.

React wasn't necessarily a defined point in our front-end stack application was swallowed by no real authentication flow, tying UI state (like open modals and input fields) to a Flux store and server rendered global variables.

While I was at React Rally, [Michael Chan](https://twitter.com/chantastic) gave a talk called ["Back to React: The Story of Two Apps"](https://www.youtube.com/watch?v=T9-Mb_axNgA&t). He talked about his experience working on applications at Planning Center and kept talking about React not being a missing piece to fill the UI layer of an application but the totality of your application.

<figure>
	<img alt='Emma Watson excitedly agreeing' src='https://media.giphy.com/media/TgrUtxYDPubgk/giphy.gif' />
  <figcaption>Me the whole time listening</figcaption>
</figure>

He outlined 5 liberating constraints to approach your application:

1. _Know whose mouth you're in / who's driving_ -- tries to answer the question of what role does React play in your application. Is it controlled by a server side framework passing down props or a state management solution or a client side router? Understanding who owns the pieces of that application and where they come from is a critical piece of productivity.
2. _Optimize for change_ -- defining the criticality of a component and noting the pre-optimization of abstraction. Not easily or eagerly abstracting your components. The cult of re-usability is real folks.
3. _Know your component shapes and master the patterns_ -- There a few patterns React that are really popular [presentational and container components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0) or knowing and unknowing components, [Higher order components](https://reactjs.org/docs/higher-order-components.html), [Function as Child](https://medium.com/merrickchristensen/function-as-child-components-5f3920a9ace9) and [Render Props (which is more or less the same as FaC)](https://medium.com/merrickchristensen/function-as-child-components-5f3920a9ace9). You should know them all and understand which is more needed than the other in your use case.
4. _Avoid the edges_ -- knowing your edges. Your ability to be productive with tools with libraries that you can master. Adding newer libraries will often let you feel all pain of them as they battle test their concept. Choose tools that enable productivity and lower overhead.
5. _Partner don't depend_ -- the idea that you should stop delegating to OSS and accept that when you `yarn install` a dependency you're adding another piece to take ownership over. Likewise, to guard your stack from unnecessary dependencies which goes back to avoiding the edges.

He brought up this quote:

> Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. -- Edsger W. Dijkstra

Simplicity isn't easy. It's a struggle to maintain and curate. This helped me understand the beast our team raised and failed to tame. Complexity and short paths swallowed the needs of our application and we lost the thread of our own productivity.

### Climbing Out of the Mouth of the Beast

If our best answer to not creating a beast out of our front-end application is abstinence then it's a non-answer; ie. just don't use Flux or Redux. Human nature favors the discipline of abstinence like meteoroids favors resisting gravitational pulls -- we all end up crashing and giving in at some point.

<figure>
	<img alt='Star Wars GIF' src='https://media.giphy.com/media/wOHcSNT2r0m40/giphy.gif' />
  <figcaption>This is no cave! -- Han Solo</figcaption>
</figure>

But understanding how to limit the needs of your application is the first step. We can start tame the beast by limiting the influence of a global state library. Writing a list of all the things that need to be global in your application; usually that's like a JWT, the user's timezone or some user preference like a current theme. Likewise understanding what good use cases of a state management system are are really important, there's a great blog post called [_You Might Not Need Redux_](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367) that is definitely worth reading.

Most applications don't have much global state, but a lot of applications have state related to current view they're in (via a client side router and React Router is great for this).

The other upcoming thing we could employ is the [new Context API](https://github.com/reactjs/rfcs/pull/2) being proposed and there's a [polyfill](https://github.com/thejameskyle/create-react-context) you can experiment with today. Context has been a part of React since it's inception, it's not really widely used because it's [documentation](https://reactjs.org/docs/context.html#why-not-to-use-context) comes with the following warning:

> If you want your application to be stable, don’t use context. It is an experimental API and it is likely to break in future releases of React.

Context lets us pass down state on as-needed basis by calling into the `context` of an Ancestor component as high up in the hierarchy that we like (even the top level component). In theory, we could have a top level presentational component that has state passed into context and anywhere we'd like in our Route components (via React Router) call into that context. Which I honestly believe that this is the future of working with global state.

---

Our applications can get out of hand quickly. The cost of adding features needs to remain low for ongoing productivity. Mastering your application and taming it is an important tenant for keeping that cost as low as possible.

I personally believe that state management solutions are overused and they need to have as light of an influence as possible on your application. And the more I keep to that central tenant, the more productive I've found myself being in an application's lifecycle.


In the Mouth of the Beast


Recently I've been needing to make a lot of demos really quickly. Every time I needed to mock out some UI components like a table view or a list view, data was really important. But Lorem ipsum is unpredicatable and most users would never input such shitty Latin. Cierco is never going to use your app, I'm sorry.

By the way, Luke Wroblewski cover this pretty vividly:

> Using dummy content or fake information in the Web design process can result in products with unrealistic assumptions and potentially serious design flaws. A seemingly elegant design can quickly begin to bloat with unexpected content or break under the weight of actual activity. Fake data can ensure a nice looking layout but it doesn't reflect what a living, breathing application must endure. Real data does. -- [Luke Wroblewski](https://www.lukew.com/ff/entry.asp?927)

I've typically stubbed out an object to match the design I needed, copy that same object a dozen times and there, you got yourself a poorly maintained fake array. This data is fake, now if you need to do something quick and dirty, we should aim for something that takes the shape of the data we need and looks similar to the API we need to work with later on. In other words, not as fake data.

I never want to create a manual stub ever again. It is so tedious. Manual stubs aren't effective because you'd need manually change something everywhere if you need tweak part of your object. Let's try and avoid that.

### Randomly Creating Fake Data

So let's try something a little different to work with. Create an empty array.

```javascript
const List = Array(50).fill();
```

There's a probably a better way to create a fake array but I can't think of one. I'm not on trial. Get off my back. I'm sorry writing code in public makes me tense...

Okay, I'm better now.

Now we need to create our fake schema. I'm going to use [Chance.js](http://chancejs.com/), it's a great way to randomly produce predictable results we can start to work with.

I need to create a member list for a directory application in a coding interview a month ago and here's what I did:

```javascript
import Chance from "chance";

const schema = chance => ({
  id: chance.guid(),
  avatar: chance.avatar({ protocol: "https", fileExtension: "jpg" }),
  memberSince: chance.year({ min: 1980, max: 2017 }),
  maritalStatus: chance.weighted(["Single", "Engaged", "Married", "Divorced"], [1, 2, 3, 4]),
  name: chance.name(),
  age: chance.age(),
  phone: chance.phone(),
  email: chance.email(),
  address: [
    {
      name: "Home",
      value: chance.address()
    },
    {
      name: "Work",
      value: chance.address()
    }
  ]
});

List.map(i => schema(new Chance()));
```

We can use Chance to make a schema like object that's similar to the data we need to work with and not copied and pasted by hand. And when we need to change the shape we can change it in one place and have less to manage.

At the end we're mapping through the `List` Array we created because `Array.map()` returns another Array. Now we're passing a new instance of Chance to make sure each item in the new Array is unique.

Map through the results and get a new array of each of those empty spaces filled with your schema.

```jsx
import data from "./path-to-the-other-shit";
import Cell from "./some-stateless-function";

class App extends React.Component {
  state = {
    results: data
  };

  render() {
    return (
      <Wrapper>
        {this.state.results.map((result, i) => (
          <Cell key={i} {...result} />
        ))}
      </Wrapper>
    );
  }
}
```

### Bonus Points

Deploy this sucker! I've found that it's probably a good idea to not make the client-side do something the server will inevitably do, don't. It's not so hard to deploy a simple server with an instance of this faked data. [Zeit's `now`](https://zeit.co/now) (which I love and it's what this site is deployed on) makes it less burdensome to work with.

All you need to deploy the same code is:

`index.js`:

```javascript
const { send } = require("micro");
const data = require("./path-to-the-other-shit");

module.exports = async (req, res) => send(res, 201, { results: data });
```

`package.json`:

```json
{
  "name": "mydemo",
  "start": "node index.js",
  "dependencies": {
    "micro": "latest"
  }
}
```

Then run this in the root of that project:

```bash
now
```

And `now` will give you a URL you can do a GET request to and have it return your randomly faked data that similar to what data you're actually looking for in your demo or proof-of-concept.

---

I keep finding this takes maybe 10 minutes or less to setup and has so much payoff as I'm working on something.


Mocking Data Quickly


Your life in terms of programming languages:

**Python** is the boy you kissed in the woods at Bible camp. You liked it but you're not sure who to tell about it. Best keep it a secret and use that knowledge a little later on.

**PHP** is your first serious relationship. You're pretty insecure about what you want, but it comes along at just the right time and convince yourself it's what you want. You spend all your time trying to figure out how to make it work and realize there isn't a lot of depth there and eventually break it off and never look back.

**JavaScript** is the one you marry. You fall head over heels in love with JavaScript. You can't stop thinking about it, you want to rebuild all your projects in JavaScript and only see a future with JavaScript. JavaScript pushes you and causes you to grow and reminds you who you are and has real personality. You have so much fun together and you never run out of libraries to work with and there is nothing but endless adventures and ideas waiting for you.

Then things start going off kilter a little bit and you wind up with prototypal inheritance to the point where you don't know where you are anymore and you only had pure intentions to begin with; you still love the language but feel stuck all the time.

**Ruby** is the one you see on Facebook every once and a while and go 'what would life be like if I had given them a chance in college instead of having my head up my ass’. You have a lot of unresolved feelings about Ruby. Even if you wanted things to work out with Ruby, you're not sure how to get started, ultimately you just leave it alone.

**Elixir** is the one you consider leaving JavaScript for but don't. Elixir seems cool, it's all the things you're missing from Ruby, but you've made your life with JavaScript; so you're conflicted. You work up the nerve to finally get alone with Elixir on your project and you realize there's all this baggage with Erlang and you remember why you loved JavaScript to begin with.

**Swift** is the one you spend time with after you and Javascript mutually decide to take a break. Swift reminds you of JavaScript, except it's very focused on what it wants and how you should use it. You think things are going great until the App Store audits your project and then you realize, JavaScript may have had its faults but it NEVER DID THIS SHIT TO YOU. So you open your browser, open your devtools and `console.log('I still love you')` and all those feelings come running back.

**Haskell** & **oCaml** are like relationship counselors. They're not as dysfunctional as your current project and spending time with them gives you perspective and clarity you bring back to your relationship with JavaScript. With their help, you learn to love JavaScript more and give you the tools you need to not things get so bad with JavaScript ever again.

**Flow** isn't so much as a language as it is the thing you use alongside JavaScript forever. Flow helps you understand JavaScript better and gives your relationship parameters to function better within.

**C#** is the one you drunk call. You're buds with C#, just friends, nothing more. But then you have a few, rethink the potential that exists and annoyingly drunk call C#. C# doesn't care because they don't take you seriously either, asshole.


Your Life in Programming Languages


With the product I work on, we have a series of [_micro-frontends_](https://micro-frontends.org/), like independently deployable microservices but instead of server-side endpoints, they're front-end applications. So far all of these applications are written in React.

We inherited a large codebase from an offshore team and it was littered with, you guessed it, Bootstrap, being used for a lot of the styles being written. This created a problem, to render a button, we needed the Bootstrap markup, class names and the CSS overrides to make it follow the design styleguide; if you're counting that's four decencies for a single button.

As we spread out into other micro applications we wanted to maintain the consistency of the UI elements, having the chained dependency like Bootstrap. We had a few guiding principles as we started to develop sharable components:

- Reduce the number of external dependencies
- Every piece of UI should be a pure instance of UI
- Components should have reuse in mind, not exclusively feature focused
- We should document the levels of composition

Early on, we decided to err on the side of if the design team has a Sketch symbol, there is a good chance there should be a corresponding React component.

### Conception

We started on a single micro-frontend application fresh. This gave us the very wonderful opportunity to examine the granular pieces of UI without any external dependencies.

The result being something where the essential UI components are available on demand and serve a single instance of UI without muddling markup. For long lived applications, hell even short-lived applications, I value composition over inheritance every time.

```jsx
import { Card, Button, Input, CheckBox } from "@scoped/ui-core";

const NewForm = ({ onSubmit }) => (
  <Card title="User Preferences">
    <form onSubmit={onSubmit}>
      <Input label="Arbitary User Inputed Value" />
      <CheckBox label="Boolean Preference" />
      <Button onClick={onSubmit} />
    </form>
  </Card>
);
```

In this paradigm, we had a canonical `<Button />` and `<Input />` that was aligned with the design guidelines and was easy to prototype with when working with other designers.

### Result

So we ended up with a file tree like this:

```js
├── Button
│   ├── Button.scss
│   ├── index.js
│   └── readme.md
├── CheckBox
│   ├── Checkbox.scss
│   └── index.js
├── Input
│   ├── Input.scss
│   └── index.js
├── MultiSelect
│   ├── GridSelect.scss
│   ├── SortedListSelect.scss
│   ├── gridSelect.js
│   ├── index.js
│   └── sortedListSelect.js
├── PinningRibbon
│   ├── index.js
│   └── pinning.scss
├── Popover
│   ├── Popover.scss
│   └── index.js
├── Scroll
│   ├── Scroll.scss
│   └── index.js
├── StatePicker
│   ├── Tag.scss
│   ├── index.js
│   └── tag.js
├── Tombstone
│   ├── Tombstone.scss
│   └── index.js
├── UIDropdown
│   ├── UIDropdown.scss
│   └── index.js
├── UIModal
│   ├── ModalLoadingIndicator.js
│   ├── ModalLoadingIndicator.scss
│   ├── UIModal.scss
│   └── index.js
├── UIToolTip
│   ├── UITooltip.scss
│   └── index.js
```

### Documentation

One wonderful outcome of writing components with a strict pattern and maintained convention was that a lot of documentation we got for free. We used [React Styleguidist](https://github.com/styleguidist/react-styleguidist) to generate our documentation and by simply having inlined comments, `propTypes` and `defaultProps` a lot of documentation came out of work we had already done.

Modifying the components that generate the layout of the documentation itself was a little tedious but worth it to gain the control we wanted over our presenting our component library to each other.

The best part however was by including a Markdown file with a code snippet in each components directory, React Styleguidist output a live editable example in our documentation.

### Builds

Our style guide components has gone from living as a part of our application's monorepo, it's been it's own standalone repository / package and back again. Every iteration of this collection of components has let us experiment with the builds and distribution. The common threads are always: Babel, `require()` statements for Sass files, and an entry file that exposes the components through something like `export { Input } from './Input'`

A couple of things we noticed were that having lots on non-JavaScript dependencies (like a Sass file or a bitmap image) ended up involving more tooling to make sure the `require()` and `url()` statements resolved the correct paths. Aliases from webpack made this a little easier. Then sussing out the differences between `peerDependencies` vs `dependencies` is tricky alchemy but moving them back into the monorepo helped sort that out.

Sidenote, if you ever think, 'nah my font files can live in with my project', you are wrong. Your fonts belong in a CDN, trust me, we learned the hard way.

### Future

Every person on our team loves working on this project and everyone of us brings a different set of ideas to where to take it next. Fortunately, working on a small agile team, we can really experiment to see what works and doesn't work. When it works, great; when doesn't, there's always next sprint.

Lately we've played around with [styled-components](https://www.styled-components.com/) because being able to identify where your styles relate to your component is highly valuable and strings of `classNames` are a weak identifier of that.

We've always wanted to experiment with static analysis with [Flow](https://flow.org/) and our UI library is a small enough collection and with a large enough surface area to really see any potential gains. And we've been feeling like `propTypes` are an expensive metric to find out this information at runtime when finding out at compile time.

### Key Observations

- Isolating UI to be the purest instance of that component often requires coordination but worth it in the long run.
- I value composition over inheritance every time. Encapsulating styles to their immediate need and immediate need only makes sense.
- Breaking down components into anything like `GridColumns` or `Flex` may seem over-engineering but it helps simplify the composition of larger components, especially if those components take props to change their layout eg. `<Column md={5} />` or `<Flex wrap space='between' />`.


Building a React Component Library


I always enjoy these types of posts where the author exhaustively documents the tools they use and why they enjoy it so much or whether they're on the fence about it. There are blogs dedicated to this whole concept, eg. [_the Sweet Setup_](https://thesweetsetup.com/) or [_Tools and Toys_](http://toolsandtoys.net/). We get attached to our tools, more often than not we spend 6+ hours a day in front a glowing rectangle interacting with the tools we choose in exchange of our livelihoods.

Now before this post gets more nihilistic, I'll just dive in.

<figure>
  <img src='/images/posts/desktop-screenshot.png' alt='Current Desktop' />
  <figcaption>Desktop background from <a href='https://unsplash.com/photos/VlVhOro5tf4'>Max Delsid</a></figcaption>
</figure>

### Main Workflow

[**Caprine**](https://sindresorhus.com/caprine/) is a standalone Messenger.com wrapper with native macOS notification support. Switching to Android, there are dozens of Google-centric chat options, but Messenger has become my preferred communication platform. Plus there's a transparent dark mode for Caprine which is just 🔥🔥🔥.\*

[**Hyper**](https://hyper.is/) is a terminal built in React and Redux and is comparable to Atom Editor. I flit between this and iTerm 2 pretty frequently. I spend most of my time using a terminal, but Hyper is just special; it's so customizable and extensible with a language that I can write: JavaScript. Hyper sometimes freezes and chokes, but overall it's pretty stable. It's still awesome, maybe it's the novelty of an HTML/CSS/JavaScript terminal or the fact I started playing with it when it was still called Hyperterm. I'm hoping it will perform a little better in future and 2.0 will kick some serious ass ⚡️💕😀.\*

[**Now**](https://zeit.co/now) is an instant deployment tool that rivals any I've ever used. Simply running the command `now` will set off a deploy that uses a project's `package.json` to build your application, and your app can be static or Node.js based or use Docker. It's incredibly fast and every deployment is immutable so if something is corrupt with your current deployment, going back is very simple. You can buy domains from `now` and manage your aliases for deployments. Plus with the desktop application you can drag and drop files and folders onto the menubar icon and get an instant deployment of them as well.👍\*

[**Atom**](https://atom.io/) is a text editor / IDE. I have used Atom since its beginning in February 2014. Back then Atom was an alternative to Coda 2, and I wrote about [customizing it](https://arwhd.co/development/2014/09/25/making-atom-home/). Since then, I jumped between Atom and Vim full time. One of the major advantages it has for me right now over Vim, is the Git integration, the Flow plugins and the `Find in Project` search. I work in a large monorepo at work and that feature alone is so useful. With [`vim-mode-plus`](https://atom.io/packages/vim-mode-plus) working in Atom, all the muscle memory of Vim key-bindings haven't really gone to waste 💻⌨️🛠💎🌈.\*

**Sketch** is a vector design tool. I like it and Figma is cool too, but I'm more of a creature of habit. I wrote a long time ago about [how I use Sketch](https://medium.com/bpxl-craft/working-with-sketch-d10849739c8b) as a sideline to designing in the browser. Now that I've transitioned to more of a front-end role, I find Sketch really valuable for communicating initial intention with designers and having a point of reference ✒️📐💗.

[**Kaleidoscope**](https://www.kaleidoscopeapp.com/) is a really advanced file diffing/comparison tool, When I was at Black Pixel, I used this tool almost everyday. Lately, I've been finding it useful especially for negotiating between drafts or doing a comparison between two different repositories🔭🌈⚡️.

[**Tweetbot**](https://tapbots.com/tweetbot/mac/) for Twitter because some habits are just hard to break. I have used some version of Tweetbot since 2011. Some habits just die hard. Tweetbot at the time of its initial release had lots of awesome extensions like Read Later support and inlined images from Instagram and drafted messages. I anxiously waited for their macOS application to be released and was an early beta tester. But as the years went on, it became a very aesthetic alternative to Twitter's main UI, with features that were marginal improvements over the feature set Twitter offered (kinda the best you can expect from a third-party tool). Lately, I still use Tweetbot for Mac, but in the mobile side of things I use [Twitter Lite](https://lite.twitter.com/content/lite-twitter/en.html) or [Fenix for Android](http://mvilla.it/fenix/) 🦅🐦📲.

**Vim** is my tool for writing code. Vim is more of an ethic than encapsulated application. Vim has a very ubiquitous feature set (modal text editing, registers, buffers) with specific key-bindings. I want to make the ergonomics of typing code its own post. Anyway, when I want a specific desktop application for Vim, I tend to reach for [VimR](https://github.com/qvacua/vimr).

[**iA Writer**](https://ia.net/writer/) I really like writing on the train and on my phone. I've used iA Writer for 3 years now and its feature set is pretty solid. It has fantastic markdown support, has support for Google Drive and includes a Night Mode. The main reason I love working with it is that it has no toolbar or any distraction and it places a huge intention on flow.

### Menubar Utilities

[**Lungo**](https://sindresorhus.com/lungo) is a replacement for the long-lived [Caffeine](http://lightheadsw.com/caffeine/). It prevents your Mac from dimming or falling asleep. Lungo has a retina icon (Caffeine stopped getting updated in 2009, I think) and app icon is just nice ⏰☕️.

[**Battery Indicator**](https://sindresorhus.com/battery-indicator) is an alternative the native battery indicator on macOS. The one thing that it does is give you more feedback about your battery life at a glance 🔋🔌.

[**Spectacle**](https://www.spectacleapp.com/) is a window management tool. It lets you move around the windows that you have open to given presets and across different displays (that's the feature that sold me on this tool). I [used to](https://arwhd.co/workflow/2015/08/22/Keyboard-Shortcuts/) use Hammerspoon (and then Phoenix.js), which I liked a lot but required a lot of configuration and struggled to easily configure moving windows between different displays.

[**Kap**](http://getkap.co/) for screen capturing and GIF creation. It's a great a menubar app from some of the folks who work on Hyper. It replaces liceCAP for me and exports to video file or GIF.\*

\* = [Electron](https://electron.atom.io/) based application

### Equipment

- Macbook 12" 2016
- [Baron Fig](https://www.baronfig.com/pages/blackbox) & [Squire Pen](https://www.baronfig.com/pages/squire)
- [LG UltraFine 4K Display](https://www.apple.com/shop/product/HKMY2VC/A/lg-ultrafine-4k-display?afid=p238%7CsYm6sF50j-dc_mtid_1870765e38482_pcrid_167372724180_&cid=aos-us-kwgo-pla---slid--product-HKMY2VC/A) -- _most of the time, I have the laptop open underneath the display._
- Nexus 6P

### Services & Honorable Mentions

I tend to use [Pocket Casts](http://www.shiftyjelly.com/pocketcasts/) for podcasts and that's becoming a pretty infrequent occasion. I use GitHub of course. Slack is a regular application I use, I'm just pretty tired of it. I am really coming to enjoy [Spectrum](https://spectrum.chat/) for online community forums. [Talky.io](https://talky.io/) is great for video calls. I use Instapaper for collecting posts I want to read but amass only to forget about for months at a time.

Online IDEs are always up in the air for me. Lately, I tend to use [CodeSandbox](https://codesandbox.io/) for front-end demos and [Glitch](https://glitch.com/) for Node.js demos. CodeSandbox has so much potential, it's essentially CodePen Projects hopped up on steroids with a magic amulet. The fact I can have an instance of `create-react-app` in my browser immediately and have that instance be sharable is a really powerful too.

Oh, my partner and I use Project Fi instead of AT&T. It's essentially the same quality at half the price. Referral code: [https://g.co/fi/r/P34ACN](https://g.co/fi/r/P34ACN).


Current Tools & Toolchains


Up until about 6 months ago, I had never really written any unit tests for code I had written. It just wasn't a part of my routine. When I started working on a team full-time, testing felt like it pretty much consumed every decision I made.

But upfront, before we get started, I should probably tell you I do not care about the semantics and differences between TDD and BDD. I'm only really interested in the practical, in-the-weeds ideas on testing; honestly I don't know why those two strategies are often pitched as mutually exclusive.

With the product I work on at Onvia, we have two types of tests:

1. Our integration test suite, which is the end-to-end test
2. A pile of unit tests we inherited and other assorted piles of unit tests we don't run very often (and by we, I mean me)

Integration testing is very high value; it puts a strict emphasis on user needs, user flows and edge cases. They take a good bit of time to write and are very frequently run against features or discover points of failure system-wide aside from changes. More technically though, it's built using Nightmare.js and Mocha/Chai.

### Code Coverage

Typically, we don't worry about code coverage. I wish we would, but it's a shared opinion that code coverage numbers aren't a significant enough evaluation of overall system health, and if we're going to quantify value of code coverage it does rank lower than integration testing or unit testing.

### Unit Testing

Our unit tests largely revolve around the React components that we write. In a perfect world, every component gets `propTypes`, a unit test and component-level styles.

_A quick note about Mocha. I really don't like Mocha, Chai, Sinon or Istanbul. I don't like them enough to consider other sources of caffeine. I have a huge bias for [Jest](https://github.com/facebook/jest). I like it a lot (mostly because I have the most familiarity with it). It very easily covers the concerns of the previous 4, it's faster, it doesn't silo the documentation into too many random places, and it can help auto-mock dependencies and uses snapshot testing which I love for working with React components. Now back to your regularly scheduled blog post._

So I've started to ask a lot of questions about what testing code is for and the role it should play as we're building shared UI components.

> If unit testing is about testing the code I wrote without the bother of everything else, where is there more value in testing? Will a user ever arrive in a context where they reach this component in isolation like this? The code that's tested comprises a UI that goes out in front of users. Wouldn't it follow that testing the user facing portion of it is just as valuable as testing a block of code?

I don't think we as UI engineers ever want to test React or its lifecycle, there are teams at Facebook who are in charge of that. I expect React to do the things it says on the tin. I want to test if my `<Component />` performs what I design it to do.

A lot of tests I write test whether the input of something is a certain type, like an object, an array, a date and an HTML element. Frankly, this kind of checking can get resolved with static type analysis with [Flow](https://flow.org/) or [TypeScript](https://www.typescriptlang.org/).

So if I'm testing a React Component and the previous two sets of details, writing a unit test becomes a little more difficult. [This post](https://medium.freecodecamp.org/the-right-way-to-test-react-components-548a4736ab22) gives a practical look into a lot methods to writing unit tests for React, but using snapshots can resolve a lot of that very quickly.

Well, then what do we test? Testing the composition of components can be an investing idea. Let's say we had this component for a new feature:

```jsx
class Feature extends Component {
  state = {
    title: "",
    body: "",
    dateAdded: new Date(),
    preferences: this.props.preferences
  };

  onSubmit = () =>
    fetch("/api/endpoint", {
      method: "POST",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify(this.state)
    });

  render() {
    return (
      <form onSubmit={this.onSubmit}>
        <Input
          label="title"
          value={this.state.title}
          onChange={e => this.setState({ title: e.target.value })}
        />
        <Area
          value={this.state.body}
          onChange={e => this.setState({ body: e.target.value })}
        />
        <footer>
          <Button title="Cancel" onClick={this.onCancel} />
          <Button
            disabled={this.state.title.length !== 0}
            title="Submit"
            onClick={this.onSubmit}
          />
        </footer>
      </form>
    );
  }
}
```

We could use [Enzyme](airbnb.io/enzyme/) to mount this component in a JSDOM environment (with mocked XHRs) and use Enzyme to pretend to interact with the component. We could write several test cases like this:

```js
describe("Feature", () => {
  xit("submits form w/o preference");
  xit("doesn't submit form w empty fields");
  xit("unmounts the Component on Cancel");
  xit("posts with new date");
});
```

This gives a look at what I feel is the value of testing your components: single encapsulation of a user-facing feature and then dealing with what this component should do with a focus on user behavior.

By giving these tests a user focus, your acceptance criteria for your story can easily be ported to be your actual test cases.

If you're going to write a unit test at all for your code, (seriously, type checking can get a shit-load done for you if you lean into it), there should be a baseline for working on unit tests.

[Snapshot testing](https://facebook.github.io/jest/docs/en/snapshot-testing.html) with Jest is a topic worthy of its own post but I think it can be really valuable. A snapshot creates a tree that describes the React component in a snapshot file (commit these into version control). As you're working through a refactor, your test runner will run against the snapshot and verify that it's still rendering correctly. On the surface this doesn't seem really valuable, but most of the time you're working on a refactor, we want to make sure we're not causing any changes to the UI and our components are handed back the `props` and rendering the same way. Since they're fairly easy to write they're the kind of test that feels trivial to have as a part of your workflow.

```js
import React from "react";
import Feature from "../Feature";
import renderer from "react-test-renderer";

describe("Feature", () => {
  xit("submits form w/o preference");
  xit("doesn't submit form w empty fields");
  xit("unmounts the Component on Cancel");
  xit("posts with new date");

  it("renders correctly", () => {
    const tree = renderer.create(<Feature />).toJSON();
    expect(tree).toMatchSnapshot();
  });
});
```

Unit tests should be very easy to write, mocking out dependencies is tedious and isolating the scope of our module is time consuming. The more labor-intensive this process becomes the harder it is to write tests. That's one of the things I love about React + Jest: the isolation comes for free with good component hierarchies and Jest + Enzyme make mocking out dependencies relatively straight-forward.

### Acceptance Testing with Nightmare.js

But there's value in what I've come to understand as ['acceptance testing'](https://www.viget.com/articles/acceptance-testing-react-apps-with-jest-and-nightmare). In a really boring explanation it's a way to measure our software against user's needs and/or business requirements to see if it's "acceptable" for release. For more of the context, I see it as a technique to observe our whole UI and user flows versus testing just a single component.

In the case of something like Next.js or CRA or any locally running application, we could use Nightmare.js or Puppeteer to `visit()` our whole application at `localhost:3000` and start making assertions about our application in a real browser environment, not mocked out one, under real conditions.

```js
import nm from "nightmare";

describe("New Feature to update profiles", () => {
  it("Feature updates profile", async () => {
    let page = nm().goto("http://localhost:3000");

    let result = await page
      .type(".Feature input", "Allison")
      .click(".Feature [type=submit]")
      .wait(".Profile")
      .evaluate(() => document.querySelector(".Profile h1").textContent)
      .end();

    let cancelledResult = await page
      .type(".Feature input", "Allison")
      .click(".Feature .btn-cancel")
      .wait(".Profile")
      .evaluate(() => document.querySelector(".Profile h1").textContent)
      .end();

    expect(result).toContain("Allison");
    expect(cancelledResult).toContain("Sandra");
  });
});
```

I think that by itself has more value than just unit tests by themselves. It gives us the opportunity to apply user-facing language to the features we're making. Like I said earlier about unit tests: giving these tests a user focus, your acceptance criteria for your story can easily be ported to be your actual test cases. Acceptance testing is the more traditional venue for these tests, but having this ethic in both places ensures you can be giving feedback to other members of your team _in the same language that you were tasked with for the feature in front of you_.

---

### Key Observations

So I don't have much of a point in this post other than being exposed to a lot of different types of UI testing, but here are some trends I've observed in the process:

1. React is really good at isolating concerns for testing.
2. Unit testing should be low-hanging fruit, and I've come to find that Jest and Enzyme can make unit tests easy to write when you write components that are simple and logical to follow, ie. valuing composition over inheritance.
3. Snapshot testing is trivial to execute and wonderful for sanity checking in any large refactor.
4. Tests need to have a user facing value wherever possible.
5. Recreating the universe is wonderful and everything but there's a value on how our application runs under real conditions.

### Further Reading

- [Acceptance Testing with Nightmare.js & Jest | Viget](https://www.viget.com/articles/acceptance-testing-react-apps-with-jest-and-nightmare)
- [How designers can use unit testing to build resilient and happy design systems | Vox Media](https://product.voxmedia.com/2016/4/20/11458814/how-designers-can-use-unit-testing-to-build-resilient-and-happy-design-systems)
- [The Right Way to Test React Components | FreeCodeCamp](https://medium.freecodecamp.com/the-right-way-to-test-react-components-548a4736ab22) — _this one is super practical_
- [Testing React Applications with Jest | Auth0](https://auth0.com/blog/testing-react-applications-with-jest/) — _super barebones example_
- [Testing React Component’s State | Anthony Ng](https://medium.com/@newyork.anthonyng/testing-react-components-state-b57bfc712b90) — more about using enzyme for testing react components
- [Testing React Apps with Snapshots | Jest](https://facebook.github.io/jest/docs/tutorial-react.html) — using snapshot testing with jest


Testing UI


When I started working full-time Onvia, we worked on an account page; simple stuff, a user can see their details and update them. One mock our dev team was handed was simple, 4 card components displaying the information with a toggle to switch it into a form to update the info. Interactions were very minimal, because the point of this particular view was to be information dense, providing the user with information about not only their profile, but their subscription information and tailored contact information.

But the place we were struggling with was giving users meaningful feedback after they performed their given action, cancel or update. So we iterated on the fly. The initial mock was mostly showing the distinct two views (default and editing) but not the interaction. I like calling this type of thing _pair prototyping_. Like pair programming except you both do something other than check Twitter.

A more dedicated UX designer and I sat down, I pulled up the initial set of components in a browser. They pulled up Sketch. We're using React so the logic never really had to change and we could choose what to render. The logic was simple, if `edit` is true, render the form with the same props that were used for the default card view, submitting fires a post request, if the response is successful, show an indicator and switch `edit` to false to switch back the default card view. We focused on what we could render, since we isolated the `<SuccessIndicator />` into a single component we could change it to essentially whatever we liked given.

The UX designer could see the code I was writing and since it's Sass (yea we're using Sass, for reasons...bad ones), it was easy to call out what UI styles needed to change. At the same time, I was able to give them feedback in a real browser context, they could also see these iterations done in real time via some hot module replacement.

<figure class='SuperFigure'>
  <div class='Grid'>
    <img alt='Iteration of Card Design #1' class='Grid__image' src='/images/posts/pair-proto-card-1.png' />
    <img alt='Iteration of Card Design #2' class='Grid__image' src='/images/posts/pair-proto-card-2.png' />
    <img alt='Iteration of Card Design #3' class='Grid__image' src='/images/posts/pair-proto-card-3.png' />
  </div>
  <figcaption>
  Ultimately, we went through 4 or 5 different styles of updated indicators. Then we mutually decided to use the first indicator because it wouldn't obscure or context shift the user too much.
  </figcaption>
</figure>

---

Collaboration like this goes back to what I was talking about in my [previous post](https://charlespeters.net/writing/centaurs/). Feedback, mutual respect, meaningful interaction, done in practice. More often than not, when we're able to use this type of dynamic in prototyping, we end being more confident in the product we're deploying and get to the results much quicker.

Typically I work with what we'll call an "embedded teams". A single team is comprised of members of the engineering team, two front-end, two back-end, a product manager and a dedicated UX designer. In an ideal world, this collaboration can happen very easily with the given dynamics, but it's not always easy. It's part of my focus to lower that barrier to entry. As we're sprinting as an engineering team we have access to resources to deliver the user stories we're committed to (...we're agile...I really just want to be spry, that's so much better of a word, it's lively but less acrobatic), but what ends up happening is our backlog is in a constant state of flux with priorities shifting (which in a business focused on delivering value that's what _should_ happen). As a result, it's anything goes and this collaboration becomes imperative versus it being a luxury.

I like self-induced pandemonium. It's like eating leftover Chinese food first thing in the morning, something bad is inevitably going to happen, and instead of dodging the bullet you learn very quickly how to live with shrapnel. Ya ummm, this analogy is getting away from me.

But anyway, there's this echoing idea in this industry, that UX is everyone's concern; from back-end engineers, to front-end developers, to salespeople. But this idea is useless if it's not put into practice.


Pair Prototyping


We have gotta be done with the 'should designers code?' discussion right? What about the follow up conversations about the nature of what a designer is and the narrowing definitions of code itself? Do we need another several-thousand word Medium post about these loose and undulating definitions? The Gettysburg Address was a 272 words and Psalm 23 is only 116 words; I don't really know what I'm getting at other than your fucking think-pieces should be shorter than the Magna Carta.

Beyond that, these aren't interesting discussions. They impose rhetoric on tactile behavior and they often narrowly scope the work and value of complicated work.

When we finally find someone who withstands the really brittle definitions of what we call a designer who can also write code and speak into that language, then they get assigned this appellation "unicorn". That's word doesn't do a whole lot to cloak the complexity or even sound reassuring. Personally, I think it's always sounded a little reductionist. Supposedly the term "unicorn" is about scarcity versus about being mythical. But at the end of the day unicorn is a horse with an extra appendage, and from fables lost in the Great Flood. How does that instill confidence or value to this supposed renaissance person?

If you're going to pick something fictitious to describe these hybrid super humans, why not something strong and powerful? My preference, _Centaurs_. Centaurs are powerful creatures that roam in herds and is something that's actually two things.

---

### Space Between

I'm noticing more companies are investing in this intersection and placing more emphasis on the nimble ability to be ambidextrous. There's definite expanse between the two extremes of design and development but that doesn't mean that there isn't value in exploring people sit in that expanse. Maybe a better question is: are the extremes of these two disciplines actually extremes?

I would say no. These two groups are typecast as dreamers and schemers; with designers defining the experience and developers executing that experience. This has never been my relationship with other designers or other developers. The best version of the dynamic is exposing intention and enabling possibilities from both parties.

Communicating intentionality is difficult and [design tools haven't helped](http://jon.gold/2017/08/dragging-rectangles/). It seemed like there was a solid 6 months in 2015 where everywhere I looked people were talking about the slew of prototyping tools that were either coming out or shutting down. Static assets don't communicate intentionality, user flow or even animation.

The best dynamic between these implied extremes is mutual respect and lowering the barrier entry on either "end". When it's easy for engineers to give feedback and help iterate through the design process and easy for designers to interact with working prototypes, each "end" is more informed. This doesn't mean living in each others pockets, it's realizing that there's value from every member trying to deliver the same experience.

Should designers jump into code and help with prototyping? Absolutely. Should engineers ask more questions early in the formative stages about what they're developing? Absolutely. Should there be a Freaky Friday moment where designers become developers until they realize they were better off before and realize their true worth? I'm going to let a more existential person answer that question.

Both "ends" of this spectrum are really the same set of talents applied in different mediums with the same goal in mind. I believe in more in the idea of centaurs than I am of unicorns who can do everything. Centaurs have a herd-mentality and roam together.


Centaurs


Quick, what are the two most useful features of every CSS pre-processor out there? Top of that list are probably variables and concatenating files. There have been rumblings about CSS getting native variables for a few years now and they're finally in the wild in major browsers.

These native variables are called "custom properties". To me they're one of the coolest things in CSS today. They give you as a developer the ability to natively keep values consistent without the help of a build process.

### Browser Support

- Firefox 31+
- Chrome 49+
- Safari 9.1+ / iOS Safari 9.3+
- Android Browser 51+
- Opera 36+
- Edge [In Development](https://developer.microsoft.com/en-us/microsoft-edge/platform/status/csscustompropertiesakacssvariables/)

_from [Can I Use](http://caniuse.com/#search=custom%20properties)_

### Using Variables

You can define a custom property in the root of your project and call it with the `var()` function. The only trick to defining a custom property is that you need to prefix them with the double dashes `--`. It may be a little odd at first, but it prevents naming collisions with reserved words and values. It's also worth noting these custom property names are case sensitive.

Custom properties store any value you want. It can be a color, a `calc()` function, measurement, a string or any other value you would normally define in CSS.

```css
:root {
  --base-color: #147aab;
}

a {
  color: var(--base-color);
}
```

You can also define a custom property at the selector level and then that property is scoped to that parent selector.

```css
.Block {
  --theme: #147aab;
  border-top-color: var(--theme);
  padding: 1rem;
}

.Block__title {
  color: var(--theme);
}
```

You can optionally set a fallback in the `var()` function if that named variable isn't available. For example, if the variable `--theme` isn't available, it will use the hex value in the second parameter.

```css
.Block {
  color: var(--theme, #ffc600);
}
```

You can redefine custom properties at breakpoints.

```css
:root {
  --blue: #5886a7;
}

html {
  background: var(--blue, #ffc600);
}

@media only screen and (min-width: 20rem) {
  :root {
    --blue: #147aab;
  }
}
```

### Working with Numbers

Custom properties store values but you can't interpolate them like you can with Sass with the `#{$variable}px` or similar syntax. You can store a unit-less number but you can't just append a unit when you're calling that custom property. To achieve this you can combine the unit-less value with the `calc()` function.

```css
:root {
  --size: 1.5;
}

h1 {
  font-size: var(--size) rem; /* Doesn't Work */
  font-size: calc(var(--size) * 1rem); /* Works Perfectly */
}
```

### Mixin-like Properties

There's another [spec](http://tabatkins.github.io/specs/css-apply-rule/) related to custom properties with the `@apply` rule. It's similar to a Sass mixin in that it applies groups of styles, but it's static so it doesn't take any parameters like Sass mixins would.

```css
:root {
  --awesome-headline: {
    text-transform: uppercase;
    letter-spacing: 2px;
    color: var(--base-color);
  }
}

h1 {
  @apply --awesome-headline;
}
```

As of the time of writing this post, you can only use `@apply` in Chrome behind a feature flag. But maybe that will change soon. There is a [PostCSS plugin](https://github.com/pascalduez/postcss-apply) that will let you compile those values.

### Examples

This is an example of applying custom property to a parent element and applying it child elements.

<p data-height="436" data-theme-id="4981" data-slug-hash="EgjzWA" data-default-tab="css,result" data-user="charlespeters" data-embed-version="2" class="codepen">See the Pen <a href="http://codepen.io/charlespeters/pen/EgjzWA/">Custom Properties</a> by Charles Peters (<a href="http://codepen.io/charlespeters">@charlespeters</a>) on <a href="http://codepen.io">CodePen</a>.</p>
<script async src="//assets.codepen.io/assets/embed/ei.js"></script>

This is an example of updating a custom property's value with JavaScript.

<p data-height="300" data-theme-id="4981" data-slug-hash="ORVrQy" data-default-tab="css,result" data-user="charlespeters" data-embed-version="2" class="codepen">See the Pen <a href="http://codepen.io/charlespeters/pen/ORVrQy/">Changing CSS Custom Props</a> by Charles Peters (<a href="http://codepen.io/charlespeters">@charlespeters</a>) on <a href="http://codepen.io">CodePen</a>.</p>
<script async src="//assets.codepen.io/assets/embed/ei.js"></script>

### Further Reading

- [CSS Variables: Why Should You Care?](https://developers.google.com/web/updates/2016/02/css-variables-why-should-you-care) from Google Developers
- [Custom Variables Spec](https://drafts.csswg.org/css-variables/)


CSS Variables


As much as front-end developers have fallen in love with PostCSS, the truth remains that people are still writing Sass at their day jobs. Sass is still really popular and for good reason. Sass is widely adoptable by most platforms, it's easy to get started with and a really enjoyable syntax.

But all of those things can be a hindrance. A lower barrier to entry can lead to a lack of structure and organization. Personally, out of all the Sass codebases I've stepped into, not one of them was adhered to a structure or any guidelines.

Reference:

- https://css-tricks.com/sass-style-guide/
- https://sass-guidelin.es/

### Nesting

Don't. No good can come from nesting, resist this temptation. Yes nesting empowers that author to group related CSS and bubble out the parent selector. My issue with nesting sits with the person who has to read that code later who didn't author it. It can really quickly turn into a tangled mess. If you insist on using nesting (again it does have benefits but I don't feel they're worth it), move all the base declarations for parent into a single `&` and then add an extra space between each nested child declaration.

### Variables

- Use clean variable names.
- Take stock of the `!default` flag
- Use local variables with commented purpose.
- Move computation into it's own variable

### Extends

In my opinion, using the `@extend` method is a bad idea, the output is less than ideal because it creates a lengthy selector parse. I do not recommend it. It's probably better to move those declarations you want extended into a base class you apply as a utility. The native `@apply` method seems like a better option to accomplish an that type of extend. Browser support is negligible but the PostCSS toolchain is really helpful for transpiling things like this, there's a plugin that's experimenting with the specification.

Reference:

- [Apply Spec](http://tabatkins.github.io/specs/css-apply-rule/)
- [PostCSS @apply](https://github.com/pascalduez/postcss-apply)

### Mixins

Mixins are cool. They're helpful. Supposedly they're better for performance as they're not chaining selectors to each other. My opinion of mixins is they're useful for grouping values together that need to printed out with slight variation. It's better to try to avoiding to hide magic them. Use them to print out values for certain properties.

Dropbox's Scooter, takes an interesting approach to using mixins in their project. They use default variables to define a naming prefix to a class plus any default values for that class. I'm assuming this is so those base values can be overwritten and these mixins reused later. But the default values outside the mixin are interesting, this ensures that when the mixin is called even if there's no values passed into it, it doesn't return an error.

Never use mixins to output vendor prefixes. There are better tools for this like Autoprefixer.

Reference:

- http://csswizardry.com/2016/02/mixins-better-for-performance/
- https://github.com/dropbox/scooter

### Functions & Directives

- Namespace functions with a hyphen. Like web components there maybe reserved words in CSS, so it might be better for functional values like `color()`, `url()` or `var()` for future Sass compilations to use a hypen to denote that your Sass functions are different from native CSS functions.
- `@for` `@each` loops are cool. But keep them small and nimble.

### Partials

- Partials are my favorite part of Sass. They're in my opinion the best part. They give you the ability to break down your CSS in smaller chunks.
- Put variables related to that module at the top of the file
- Put media queries at the bottom of the file. mqpacker is good at consolidating all of them for you.
- Index directories of partials with an `_all.scss`, they can really clean up your main Sass file where you want all the project partials concatenated.

### Linting

- Sass lint
- Stylelint

Reference:

- https://github.com/sasstools/sass-lint


Writing Sass Today


About a year ago, my dad was on a tirade about something (it runs in the family a little bit), he was trying to do something fairly common from his phone. If memory serves, he was trying to send a spreadsheet he got as attachment to another person. He bemoaned how unintuitive and complex this process was, the language around the interactions in the UI being unclear and the lack of assurances that spreadsheet had been sent.

He’s almost 68. It’s not uncommon for him to be frustrated with technology and the new demands it presents to him.

The next thing he said has stuck with me ever since. He said (a little exacerbated, but clear nonetheless), “There’s just too much…” He paused and motioned his arms as if to entice the word he was searching for to appear. “…too much…friction in this whole thing. I guess that’s what you’d call it, friction. Why can’t this damn thing be any easier?”

I like the way he put that.


Friction


I’ve never thought so much about a gadget I’ve bought or wanted so much as I have with the Apple Watch. When the iPhone first came out I thought it might be cool, but it wasn’t until the 3GS was released that I really started salivating for one. Same is true for the iPad; I scoffed at the first couple iterations of it and when one was released to market with Retina Display, it’s all I wanted.

But the Apple Watch was a little different. I didn’t really want it at first. The watch, like the Apple TV, [doesn’t have any web views](https://medium.com/bpxl-craft/apple-tv-a-world-without-webkit-5c428a64a6dd#.wscvvmtdz), so not a whole lot do with anything I could reasonably create for it. But it’s a new interface method all the same, so I was a little curious but not \$400-curious.

I finally cracked and got the Apple Watch, mostly because everyone else I work with had one and I didn’t want to be the odd man out. The tide has pushed me to do worse things.

Now two months later I’m still not really sure what you’d want to do with this thing. It’s not an ideal replacement for a FitBit. It’s not a device really meant for composing anything. And its main strength is to alert me to things I otherwise would’ve reached to my phone for.

<figure>
  <img src="/images/posts/applewatch.jpg" alt="Apple Watch on Wrist" />
</figure>

### Where it Shines

At best the Apple Watch is really great at telling me things on the fly. For instance: if I’m close to things I need to find in Seattle, like Kings Street Station or when buses are due, if my wife is texting me, getting DMs from Slack and Twitter (via Tweetbot) or if I need to be in a meeting (from Fantastical).

Other than that, I haven’t found a whole lot of use for the watch. (Except Calcbot, it’s the best calculator app on the market on any device it runs on.)

### Consumption

There are lots of remote apps for NPR One, Overcast and Instapaper that connect to their iPhone counterparts to control the players in those apps. It doesn’t exactly blow my hair back. Plus there’s nothing in me that makes me feel like I want to read emails or read Facebook Messages or my credit card statement from my wrist.

News apps like the New York Times sending headline updates to my wrist are quick and interesting and make me more interested in the topics at hand (_see what I did there_). I would love to see [a certain awesome news reader](http://netnewswireapp.com/ios/) follow suit.

### Horizons

To-do lists and productivity apps seem like a real avenue in their infancy on the Apple Watch. When most apps are trying to have a tethered experience to the iPhone (or worse a retrofitted iPhone experience) these apps feel more complementary. For some reason having a reminder hit you on your wrist is more intimate and less obnoxious than having it on my phone interrupting an existing task I’m performing. Crossing things off in Clear always feels productive and that I’ve accomplished something.

(I haven’t checked out Omnifocus yet, but I definitely think I should in the coming year. I’ve only heard good things.)

IFTTT & Do Button are really convenient together and having those predefined tasks set-up and being a button press away trump things like Launch Pad Pro (which I am very fond of).

On a separate note, gaming hasn’t ever really been a lot of interest; even still I’ve spent a fair amount of time with quick-fix games like Boxpop and Letterpad. I’m excited to see more.

---

Every time iMore publishes a best Apple Watch apps listicle, I’m quick to devour to it, and always on the look out for different applications to try, so send any recommendations my way.


2 Months of Wearables


Have you ever opened up a pomegranate? It’s a gigantic pain in the ass if you haven’t. To make the least amount of mess you have to score the open tip of it over a glass bowl[1] full of the hottest water your skin can stand. You need to score so there’s a light cut around the thing so it’s divided into quarters.

<figure>
  <img alt="Innards of a red pomegranate" src="/images/posts/pomegranate.jpg" />
</figure>

You rip that bastard open with the least amount of force you can so it doesn’t go anywhere other than the bowl. Inside of it seeds nested in clusters inside the flesh of the pomegranate. You have to rip the flesh off of seeds without puncturing them. And you need to do this with your hands in the hot water. The flesh protecting the seeds will float to the top as the seeds sink to the bottom of the bowl.

Now to add insult to injury you can’t do this without finesse. You’ll puncture the seeds and stain your hands. When you’ve actually managed to remove all the seeds from the flesh of the pomegranate. You can’t do anything with them until you’ve dumped the shreds of skin and flesh of this and dumped the remaining seeds in a colander so they can be rinsed.

Even after all that to get the juice out of the fucking seeds (which look like blood red popcorn kernels) you need to press and smash them and let the juice run into a container to hold it because you can’t eat the seeds. (Actually most of a pomegranate other than the juice can kill you, it makes kiwi skins almost cuddly.) And as luck would have it, you don’t really get that much juice out of this ordeal; it’s less than 3 ounces in most cases.

So there you have it. Lots of awkward tedium for so little gain. Isn’t Mother Nature a real bitch?

---

[1] I’m not sure why it’s better if the bowl is glass but out of the handful of times I’ve done this literally fruitless endeavor it doesn’t work super well in plastic bowl.


Fucking Pomegranates


I switch between browser and editor, from editor to terminal and then into the company chat at sporadic times. The amount of those transitions accrue to the point where it’s time to think critically about whether there aren’t easier ways of do it.

Personally I love workflows and tooling, so the idea of using only using my keyboard to make these transitions would be the height of efficiency to me. Luckily with a little work, it’s not that far off.

### Legend

- ⌘ = Command
- ⌥ = Option / Alt
- ⇧ = Shift

### OS X

There’s not much default in OS X that isn’t super typical stuff (`⌘ + S` for save, `⌘ + T` for new tab, `⌘ + W` to close) but one I didn’t really know about was `⌘ + Tab` that will let you cycle through your open applications. Now I know that one is a little more well known but I didn’t really know about until late 2012. The other two things I do is disable any trigger for Spotlight search and alias ZSH to where I keep my main projects.

### Hammerspoon

[Hammerspoon](http://www.hammerspoon.org/) should be every hacker’s magic wand for manipulating OS X to do whatever you want. You script things with Lua to work with OS X, I mostly use it for window resizing and management. I adapted Brad Cerasani’s config a little bit to make it more my own (you can find that config in my [dotfiles](https://github.com/charlespeters/dotfiles)). So these are the current shortcuts configured in Hammerspoon:

- `Ctrl + ⌘ + ⌥ + ↑` forces a window full width
- `Ctrl + ⌘ + ⌥ + ←` forces a window half width to the left, full screen height
- `Ctrl + ⌘ + ⌥ + →` forces a window half width to the right, full screen height
- `Ctrl + ⌘ + ⌥ + 1` forces a window to 400px wide to the left
- `Ctrl + ⌘ + ⌥ + 2` forces a window to 768px wide to the left
- `Ctrl + ⌘ + ⌥ + 3` forces a window to 1280px wide to the left
- `Ctrl + ⌘ + ⌥ + 4` forces a window to 1440px wide to the left
- `Ctrl + ⌘ + ⌥ + ⇧ + ←` forces a window half width to the left
- `Ctrl + ⌘ + ⌥ + ⇧ + →` forces a window half width to the right
- `Ctrl + ⌘ + ⌥ + ⇧ + ↑` forces a window upward
- `Ctrl + ⌘ + ⌥ + ⇧ + ↓` forces a window downward

### Alfred

Next up is [Alfred](https://www.alfredapp.com/), it’s productivity booster that lets you launch applications and do a whole host of other miraculous things. My hotkey is `⌘ + Space` and from there I launch applications, run terminal commands, search bookmarks & package managers.

- Launch Terminal with a command `> command`
- [Control Rdio `rd pause`](https://github.com/leejones/alfred-rdio-workflow)
- [Search NPM’s registry `npm <query>` (ie. `npm react`)](https://github.com/willfarrell/alfred-pkgman-workflow)
- [Github Commands `gh <query>`](https://github.com/gharlan/alfred-github-workflow)
- [Add an entry to Fantastical `cal <specifics>`](https://github.com/robb/Fantastical-Alfred-Workflow)
- [Search all of Google Chrome bookmarks `ch <query>`](http://d.pr/f/gkwy)
- [Jump to something in Slack `slk <query>`](https://github.com/fspinillo/slackfred)

The other than the first thing in that list, all of those require a 'workflow' (a script that plugs into the API). In order to use Alfred workflows, you will need to pay for [Powerpack](https://www.alfredapp.com/powerpack/).

### iTerm

I pretty much live on the command line, I love iTerm2. It’s perfect, absolutely perfect. The one great modification I make is that when I open a new pane or new tab, I make it open the same directory I’m currently working in. These are most used shortcuts:

- `⌘ + D` split pane horizontally & to open a new prompt
- `⌘ + ⇧ + D` split pane vertically & to open a new prompt
- `⌘ + [` or `⌘ + ]` Jump between panes
- `⌘ + ⇧ + [` or `⌘ + ⇧ + ]` Jump between tabs
- `⌥ + Space` show iTerm window

### Chrome

Pretty much, I always use Chrome for pleasure and profit, this should ease working with it:

- `` ⌘ + ` `` Cycle through Windows
- `⌘ + ⌥ + I` Open DevTools
- `⌘ + ⌥ + J` Open Console
- `⌘ + (1 through 8)` Jump to the first 8 specific tabs
- `⌘ + 9` Jump to the last tab

---

That's all I got. Hammerspoon is a huge deal to me to have a scriptable method of moving windows + Alfred, I really don't feel the need to touch my mouse or trackpad much.


Expedite Your Workflow with Keyboard Shortcuts


We have a problem with graphics editors. There hasn’t really been an intentional application for designing user interfaces in, ever. Adobe keeps trying to make Photoshop for the web and for UI design, and it keeps coming up short for me and probably for a lot of other people. But remember, Photoshop is like 25 years old. And Photoshop is a photo editing software; layout, typography is an afterthought and lot of things you’re looking for are hidden or in layer styles.

So let's face it, Photoshop has a big learning curve (or at least for me it did), and it has a really high cognitive overhead. The value of a tool is for it to get out of your way while you work and aid you in the task at hand. If Photoshop can't do that, it's time to find another tool.

If you’ve spent any time on Designer News or worse in the comments of Designer News, you know that Sketch wants to be the king of the hill for UI design. It’s supposed to be this magic bullet of UI design tools and I feel like it really has the potential to be just that.

### Me & Sketch

As for me, I was pretty tired of Photoshop. I was working with a few guys who included all the details about interaction in Photoshop notes in this pixel-perfect mockup, and the mockups themselves didn’t help us make responsive designs or patterns. I was so exhausted with that type of non-reality. So I went to Sketch as an alternative to Photoshop mostly for that reason.

I loved that I didn’t really need to watch any tutorials to feel productive in Sketch. After fumbling with it and remembering it wasn’t another Adobe product and that muscle memory started to wear off a little bit, it felt like the thing I needed to complement working in the browser.

I mostly work in CSS (via a preprocessor) and design mostly in the browser. I have a pretty nice workflow for doing that and even moreso I always feel like I'm designing with more context in the browser. But sometimes I still need to use a graphics editor to work with color or play with typography (working with fonts in the browser to me is still kind of labor intensive for just quick impressions).

So I normally take the [Style Tiles](http://styletil.es/) approach to most design I do in Sketch. This usually ends up being how objects look next to each other, feeling the impact of colors near each other or building a small type systems to play with hierarchy. The only real thing I use it for is to play with vector objects; Sketch makes working with (already made) SVG files really handy.

I rarely work in a literal mockup (mostly because there is no fixed size in web design). But fortunately, if I had to, Sketch has a ton of features to help.

### A Sketch Workflow

These are the plugins and tools I've found helpful and those that I actually use. For the most part I shy away from too many plugins. Less complication here is better.

#### Plugins & Add-Ons

- [Sketch Toolbox](http://sketchtoolbox.com/)
- [Sketch Tool CLI](http://bohemiancoding.com/sketch/tool/)
- [Content Generator](https://github.com/timuric/Content-generator-sketch-plugin)
- [Sketch Plugins by Cemre Gungor](https://github.com/cemre/cemre-sketch-plugins)
- [Nudg.it](http://nudg.it/)
- [RightFont](http://rightfontapp.com/)
- [Sip](http://theolabrothers.com/sip)

#### Symbols

One Sketch feature I'm mystified by is symbols. You make a group of objects and create a 'symbol' of it, then you can repeat it else where in the document. But they're inseperable; if you change the size, dimensions, or color of one of the symbols all of them mirror those changes. It's good if you need to make a header or consistent page element but I can't see where you'd use it elsewhere.

### Icons

For the most part I'm still really not comfortable drawing in Sketch, hopefully that just comes with time. I still use Adobe Illustrator for icons and making vector graphics that have any complexity to them. If you have any good tutorials on drawing icons in Sketch, please tweet them to me ([@charlespeters](https://twitter.com/charlespeters)).

### Resources & Articles

- [Design & Code](https://designcode.io/sketch)
- [Sketch Land](http://sketch.land/)
- [Sketch Resources](http://learn.ustwo.com/sketch-resources/)
- [LevelUp Tuts](http://leveluptuts.com/tutorials/sketch-3-tutorials)
- [Medium Posts](https://medium.com/sketch-app)
- [Prototyping with Gulp, Sketch & Framer](http://www.darrinhenein.com/rapid-prototyping-part-one/)


Working with Sketch


Responsive typography isn't as hard as we make it out to be. After a lot of experimenting and a lot of screwing it up, I found the best way to respond to different screen sizes is to have a straight forward approach.

### Use REMs

REMs are a relative unit of measurement in CSS that's similar to EMs, except instead of being relative to the font size of container, it's relative to the root font size of the root of the document (hence the 'r').

There's an old approach from Jonathan Snook using REMs that's popular but I don't think is a great idea[^1]. Jonathan advocates (I don't know if he still holds this position) that you should set your font-size on your html element to 62.5% so that 1.4rem can equal out to be 14px. I've heard this volleyed again on Twitter not too long ago and I can't say I agree.

1rem equals 1x of the default browser size. So let's say the default browser font size is 16px, 1rem would be 16px, 2rem would be 32px and so on. But the default browser font size could be anything; it's something the user can decide in their browser settings, so it's not a reliable metric to depend on.

If we design with a pixel based mentality, we're working against the browser and the user.

I tend to set the html size to 100% and with media queries set it to 92.5% and let everything I've declared in REMs size accordingly. Much less resistance. For reference, .875rem to 1rem are an ideal body text size. A great headline size is about 2.25rem.

Browser support of REMs is pretty good IE9+, and if you need to support an older browser there are ways you can still use REMs. If you're doing smart things like using a [build step](http://arwhd.co/development/2014/06/25/codekit-vs-grunt-js/) there's Grunt tasks and Gulp plugins to set a pixel fall back.

### As Few Font Families as Possible

This is more of a performance note versus being strictly related to responsive design. But you never know the bandwidth on your user's end so it's still relevant when designing for multiple devices.

You should declare as a few different font families as possible. Let's say you're using a sans-serif like Freight Sans on all your headlines and everywhere else on the site, but on your paragraphs using Freight Text. Declare Freight Sans on the html element and use a reset to let forms inherit the font-family, and only on the paragraphs declare Freight Text.

Example:

```css
html {
  font: 400 100%/1.5 "Freight Sans Pro", Helvetica, sans-serif;
}

p {
  font-family: "Freight Text";
  font-size: 1rem;
}

.sidebar h3 {
  font-weight: 700;
  text-transform: uppercase;
  letter-spacing: 2px;
}
```

By comparison, declare font-weight and font-size as often as you want, provided it's trusting the cascading parts of CSS. I know it might be a weird thing to harp on but I've been in the mindset of using as few font-family declarations a possible. I also wish I had actual numbers behind this, but I've seen my sites load faster on mobile devices since implementing this mindset.

From a logical standpoint, by declaring fewer font families, you're writing less declarations and less CSS (and smarter CSS) and which means less for the browser to render, letting it use the cascade it the way it was meant to.

This is my speculation, not gospel. I would, however, love to see real performance stats on this.

### Icon Fonts

Just don't.

If you're thinking about using an icon font, I have a bunch of [free SVG icons](http://charlespeters.net/justafewicons/) you can use for free. They're seriously free and better for the internet. Not every device supports `@font-face`, and depending on a font for your icons can't provide you any real fallback. STOP USING ICON FONTS.[^2]

### More CSS to Consider

Go for unitless line-height.

> Unitless line heights are recommended due to the fact that child elements will inherit the raw number value, rather than the computed value. With this, child elements can compute their line heights based on their computed font size, rather than inheriting an arbitrary value from a parent that is more likely to need overriding. [^3]

You can set a max-width on paragraphs to close to 33rem to 38rem to maintain a readable amount of characters on a line (45-75 characters). You also might want to consider setting `word-wrap: break-word` for long links. There's nothing worse than reading a blog post on your phone and having a long horizontal scroll because there's a link in a comment.

---

Those are my approaches and best practices to responsive typography; there's lot to consider and it's constantly evolving. But I think this is the path of least resistance. I also have a [repo up on Github](https://github.com/charlespeters/type-findings) that's just a list of articles and resources about typography for you guys to check out.

[^1]: [_Font Sizing With REM_](http://snook.ca/archives/html_and_css/font-size-with-rem)
[^2]: ["Leaving Pixels Behind: A Vector Workflow for designers" by Todd Parker](https://docs.google.com/presentation/d/1CNQLbqC0krocy_fZrM5fZ-YmQ2JgEADRh3qR6RbOOGk/edit#slide=id.p)
[^3]: [_Line-height_](http://css-tricks.com/almanac/properties/l/line-height/)


Responsive Typography


For the last couple of weeks there's been a lot of conversation about a [bait-and-switch company](https://medium.com/@sachagreif/in-the-past-couple-years-startups-have-started-realizing-that-good-design-can-make-the-difference-2fdeb90d390a) and about [doing free work](https://news.layervault.com/stories/30799-young-jerks-doesnt-work-for-free). And they all make amazing points in some clever ways. I need to be more of an evangelist of design and it's value.

But these are only great conversations to have for anyone trying to make a living designing things (websites, posters, promotional things, logos and identity and everything I'm not mentioning). We're forgetting that there's another side of this, the people paying us to do the designing we love doing. It begs the question for someone trying to commission design work, looking at budgets and pricing: what value does design have for me?

I'm trying to [be better at giving these kinds of answers](http://arwhd.co/rwd/2014/05/23/defining-rwd/) to clients and people I'm pitching. A lot of the small business owners I talk with are interested in the bottom-line and understanding why they shouldn't pay for a service like Fiverr or 99Designs. I never find myself thoroughly prepared to give satisfactory answers in these situations.

But I think the answer might be simpler than I might be making it. Design isn't as much about choosing colors and lusting over typefaces (not to say that isn't amazing) as it about making and collecting thoughts and making them tangible and sharing them with others, just like any other form of communication. It gets lost in the abstract because it _can_ more visual than something like written communication.

That doesn't entirely answer our question yet. When we can make thoughts about who a business is, what they do and what values they have we start to really discern the value. We can build loyalty with their audiences and customers. We can distinguish them from other businesses like them. We show the extend of which they care about communicating with their audiences/customers. We can build systems to commuicate with them better.

At the root of things, that's design work we end up doing in one way or another and I would think that anyone would find valuable.

I'd like to find more/deeper/better answers to what value design as to those on receiving end of it, I don't think I've reached it in this post. I want them to get the most value of the services I can provide. But mostly I want to understand how to provide them better.


The Value of Design


It is no secret that I am often cynical and at other times radically depressed. Somewhere along the way I find it really helpful to know that life is composed of moments that pour out in so many different varieties. Some are wonderful, some are unpleasant, some are downright cruel; there are even some moments that even drown out the others.

In some of those moments that I find particularly awful or depressing, I try to list some of the things that make me the happiest. Most of the times I find myself doing that, I think about the moments that on the surface are trivial but are really beautiful and drown out all the unpleasant moments.

Our lease is almost up and the apartment we fell in love with too quickly has lost its luster. It's in a far too noisy corner of Main Street and not really handy to anything that we need like a pharmacy or store or our bank. Plus the property management make us feel like we're in a state ward. _We are definitely planning on finding a different place._

That conversation has been compounded with a few other conversations Sabrina and I keep circling: starting our family, furthering our careers, buying a car, moving to the PNW. There is quite a bit up in the air and it's generally a fucking drag.

One moment when I looked at my project lists then my bank statement and reconsidered my whole life trajectory, I remembered another moment. It happened when Sabrina and I were closing in on more definitive plans for the future.

We found ourselves lying disarranged on the bed. She was wearing my Radiohead t-shirt with absolute apathy to their best albums or their most celebrated songs. She stole it a long time ago and severed everything I loved about Radiohead and assigned its meaning to the fact it's comfortable and that it's mine. She did the same thing to my Foo Fighters hoodie but that was more about how warm it is than perhaps anything romantic.

But I watched her lie there, chasing a list of possibilities, each more absurd than the last, her smile was perfect. It could've cut through from this world to the next.

We entered the realms of truly just ridiculous speculation when in a moment of pure daring, one of us suggested that we buy a car and a hitch to pile in only the things we needed: clothes, work stuff, and the mountain of books amassing in the living room. Every city an obstacle in the path of the journey we would take. No destination would satisfy our thoughts and only the movement and momentum could bring us any joy. I can't remember which of us proposed that idea, but her eyes lit up like a pinball machine and she let out this sigh that comprised the whole of my universe. It stretched each of these possibilities and exalted the most absurd as the formalized battle-plan for just a second.

The ceiling fan rotated, chasing each of these ideas, clacking, moving the air and drifting us back to reality. She closed her eyes and laughed something sweet and somber and I would not have traded that moment for anything.


Moments


We find our hero, strolling through the men’s room, happening upon Henry Kissinger’s pair of glasses abandoned in the toilet. Homer Simpson, with much excitement puts them on and immediately rattles off:

> The sum of the square roots of any two sides of an isosceles triangle is equal to the square root of the remaining side.

From one of the stalls, Homer is corrected by an irate individual who shouts, “that’s a _right_ triangle, ya idiot!” To which Homer defeat lets out an inflated and always timely “D’OH!”

It’s a reference to the Wizard of Oz, where the Scarecrow receives his diploma from the Wizard. The Wizard reassures the Scarecrow:

> Why, anybody can have a brain. That’s a very mediocre commodity. Every pusillanimous creature that crawls on the earth—or slinks through slimy seas has a brain! …from the rock-bound coast of Maine to the Sun…oh-oh, no——ah –Well, be that as it may. Back where I come from we have universities, seats of great learning—where men go to become great thinkers. And when they come out, they think deep thoughts—and with no more brains than you have…But! They have one thing you haven’t got! A diploma! Therefore, by virtue of the authority vested in me by the Universitatus Committeeatum e plurbis unum, I hereby confer upon you the honorary degree of Th.D… that’s Dr. of Thinkology!

The Scarecrow recites with shock and joy:

> The sum of the square roots of any two sides of an isosceles triangle is equal to the square root of the remaining side. Oh joy, rapture! I’ve got a brain!

Both of these characters are empowered by such confidence and daring, convinced they’re now intelligent. Now that they are in a set of circumstances, armed with a talisman to alter their character, they spout off whatever they think is intelligent no matter what it is. What it's interesting is not the fact Homer and the Scarecrow are clearly wrong but that neither is willing to admit they’re wrong.

We’ll call this the Scarecrow Equation.

Let’s direct this, that’s not the Pythagorean theorem. It sounds so close but it’s not. I encounter this is so many interesting ways, people default to it when feel threatened or have this perverse sense of bravado. It's a weird affliction to fight against and honestly we’re all exceptionally vulnerable to it. I think the only real way is to be open to being wrong.


The Scarecrow Equation


I've used CSS transitions sparingly. But a few recent posts got me really interested it going to town. During 2013's 24 Ways there was a post about the hover paradigm[^1] and it got me thinking about CSS transitions. Then this post on the Cognition Blog[^2] and that rekindled the thought that CSS transitions are a significant part of a website's design.

These articles suggest going applying transitions to the `:focus` states too because fewer and fewer touch devices support hover.

What I didn't realize is that CSS transitions were easier to use than I thought, especially when you apply them to the `:hover` state.

```css
transition: [transition-property] [transition-duration] [transition-timing-function]
  [transition-delay];
```

So this would end up being something like:

```scss
div {
  height: 3rem;
  transition: height 1s ease;
  &:hover {
    height: 5rem;
  }
}
```

So if we're using the transition on the `:hover` state we'd want set the transition on the element's normal state and on the `:hover` & `:focus` states we'd want to set our result. Here's an example to add a transition on `:hover`.

<p data-height="268" data-theme-id="4981" data-slug-hash="oDqAh" data-default-tab="result" class='codepen'>See the Pen <a href='http://codepen.io/charlespeters/pen/oDqAh/'>CSS Transitions on Border</a> by charles peters (<a href='http://codepen.io/charlespeters'>@charlespeters</a>) on <a href='http://codepen.io'>CodePen</a>.</p>
<script async src="//codepen.io/assets/embed/ei.js"></script>

Few caveats to remember, the property you're transitioning needs to exist on element in it's normal state. When I was working the pen above, I found that out. I wanted the transition to create a border around the images. So I had to set the `.circle` to have a border of `0 solid white` for it to transition properly.

The other big thing is to remember: don't interrupt your user's experience. In Dan Cederholm's book _CSS3 for Web Designers_ he talks about this a little bit (remember this book came out at the end of 2010):

> But the truth is everyone can begin using CSS3 right now. And fortunately you don’t have to think differently or make drastic changes to the way you craft websites in order to do so. How can anyone use CSS3 on any project? Because we’re going to carefully choose the situations where we apply CSS3, focusing squarely on the experience layer.

The idea is simple: go slow with transitions they can be awesome or they can like your undergrad projects done in Flash.

[^1]: [The Responsive Hover Paradigm](http://24ways.org/2013/the-responsive-hover-paradigm/)
[^2]: [Hover-crafting](http://cognition.happycog.com/article/hover-crafting)


Simple CSS Transitions


This side of the earth lazily drifted back toward the sun and then suddenly rushed into the clatter of my alarm on my phone. In the midst of finding the snooze, 5 notifications from a select few news outlets rattled off not-too-dissimilar headlines about the Ukraine and Pakistan.

<figure>
  <img src="/images/posts/oldtoyrobot.jpg" alt="Everything is timed" />
</figure>

My wife rolls over and wakes up. She’s immaculately beautiful without any effort as she forages for my oldest and most worn hoodie to put on as she makes coffee.

She finds her phone and sees a few texts from her mother, an off email from our church, a series of tweets with subjects that don’t relate to me at all. From there I find her immersed in an article that returns an incandescent blue light obscuring her otherwise beautiful face.

My iPad opens to alert me to a few desperate work emails that I will more or less ignore until I can refuel, ideally, with coffee or Coke Zero or something that less resembles flat water. More alerts come in reminding me of the books on the tablet I haven’t looked at since Sunday and the deadlines of impending projects. I open my own Twitter client to find tweets about web design and code that would be of little interest to my wife.

A curious notification comes in about a band releasing a new record from Rdio. I hit play and the wondrous sounds of synths fill the wireless speakers in the corner. The melodies resonate and sound like a delicate cross between a secret war or the furious erotic lovemaking of two (or several) computers. The beats are programmed on repeat; any existence of analog sounds or human touch seem long since diminished. They leave the haunting of electronic sounds in this apartment.

Mechanically, we continue, our morning coffee being offered and the reminder about when she would leave work. Then each of us in turn regaling the other with headlines, link bait and jokes that emerge from Twitter. My eyes finally opening all the way, taking in a slew of articles I’ve just read or committed to read later, I find myself in the shower when the hot water decides to quit trying.

The sounds of those war-strewn or ravenous computers still flies around this apartment.

My phone pipes in a few more messages that for some reason need my attention, asking almost politely for a response. I open Twitter up again and stories of the repercussions of Adobe’s hack, the fake attacks on Dropbox’s servers and Facebook privacy settings are starting to come in, along with those about the NSA. The attacks (or lack thereof) on Adobe & Dropbox feel like a friend just got mugged in a bad neighborhood. They feel a lot closer than the stories about Obama, the budget or even a story my dad told me about a childhood friend’s father dying a few days ago.

I open Dropbox on my phone to look at some files and accept invitations to new folders. Their new redesign feels like a friendly wave to me. I send my sister a quick encouraging message (she just moved to a new city). Then I jump into another app to let someone in Houston know I’ll be ready to talk in 5 minutes and tell another in Colorado the same, with a few taps that feel like nothing. A notification arrives from an RSS reader about something about Backbone.js and leveraging data objects or something in Laravel and it feels like a new trail opened up for me to go running on, a new challenge emerging. It is followed by a notification about Samsung releasing wearables and I’m instantly excited.

I drop a mug on the floor, it completely shatters and I feel exceptionally indifferent. A newsletter comes to my inbox that I have no memory of subscribing to. Unsubscribe. I get another email confirming I’m unsubscribed. I’m pissed.

My face is just as likely a glow in that pale shining blue light as when I noticed it on my wife.

I decide to microwave an egg and a package of breakfast sausages. A minute later it beeps and I realized the music stopped and it recommended similar artists and their most popular albums. I hit play on one; more electronic sounds pivot around the apartment and the sensual/aggressive computer noises melodically cycle again.

I sit down at my computer and open a terminal & text editor. I start typing and fall back into the flurry of messages I was ignoring. My rhythms seem close to automated. The text editor feels like my childhood bedroom did sometimes, where my imagination can run safely rampant. The whirring of the monitor in front of me is steadily keeping time

My wife comes into my office at home 5 minutes before she has to catch the bus to work, to tell me she’s heading out the door. A notification follows on the side of screen 15 minutes later to tell me that she arrived at work and she loves me.

I fall further into work drumming out some of the same responses, “is their browser up to date?”, “clear your cache”, “are they running the latest version of Wordpress?”, “could you be any stupider?” as if running on a loop. Feeling a drag set in I replace the electronica with a comedy album, Rdio has kindly remembered my favorites and greats me with them.

Each movement feels like a gear turning, more notifications trickle in like clockwork with news updates, RSS feeds, emails, instant messages, invitations, replies and payments. This pattern just exists on repeat.

These machines are running synchronously with my day and remind me when I’m out of step, they can be kind, courteous, helpful and even demanding. They’ve commanded my attention, my affections and are integrated into my thinking. I don’t know what day the robots came alive. But they most certainly are.


On the Day Robots Came Alive


It’s a new year and here’s what I’d like to do more and less of.

### Writing &amp; Reading More

If there’s anything I’ve learned about working on the Internet, it’s that you need to be able to communicate well and talk about the things that matter to you. I’ve always been okay at writing and loved the process, but I haven’t done a lot in 2013. So, I hope 2014 can change that.

I’m working on a blog called [ARWHD](http://arwhd.co/), where I’m going to be working on writing about freelance stuff, web design and more stuff, it should be the thing to kick my ass in gear. Plus I’ve really wanted to write some art directed posts on this blog to talk about a few things like SASS and RWD.

We should all read more and I feel like I should not be in front of a screen so much. There’s a real value to analog things like reading a book made out of a dead tree that doesn’t have a backlight. Sabrina and I are gonna try to read a book a month together. She’s like really good consuming a lot of books and she’s amazing, so it should be easy.

### Get More Serious About Javascript &amp; PHP

I can follow instructions on plugins and can write simple jQuery. But I can’t write Javascript well. I need to be more disciplined about learning. Working with CSS & Wordpress is great but I’d like add more interactivity to the work I do and build web applications.

I’ve kinda had a mental block about it. Jon Duckett’s book _HTML &amp; CSS: Design and Build Websites_ was a really great way to be introduced to web design when I wanted to learn in the first place. He has this follow up book called [_JavaScript &amp; jQuery: Interactive Front-End Web Development_](http://www.amazon.com/JavaScript-JQuery-Interactive-Front-End-Development/dp/1118531647) that I really wanted to get and keeps getting pushed back from the publisher. I keep saying, I’ll get started when it comes out and it was supposed to last May and it still hasn’t. A little stupid, I know, but I haven’t found a great place to start other than CodeAcademy, which is great for basic stuff but not much further.

PHP is kinda the same story, I have an idea for a database driven application I’d like to build, but I haven’t moved much further past the basics. Wordpress theming is easy and involves PHP but it’s more like template-making than it does programming.

If you know any good places to start, let me know on Twitter.

### Stop Being Involved in Religious Debates

In 2013, I got really sick of the absurd deluge of just stupid conversations about Christianity. At the end of 2013, between Dave Ramsey’s stupid blog, Mark Driscoll’s plagiarism & Phil Robertson’s comments, I was sick to death of people talking about these things. I unfollowed a lot of people on Facebook and Twitter just to not hear about it.

I’m generally a lot less cynical when that stuff isn’t in my face so much. Honestly, I’ve never walked away from one of these discussions feeling like I changed someone’s mind or that I’ve gained some new perspective.

---

Let’s see if I can keep at some of these things.
