DEV Community: David Sanwald

How to Design Better Types in Typescript by Following One Simple Principle

David Sanwald — Fri, 03 Jul 2020 18:26:16 +0000

All maintainable, long-lived React codebases that are a joy to work with, even after years, share one thing:
They consist of components that are built around data, that has the right structure.
One of my favorite text about React of all time explains this perfectly:
Defining Component APIs in React

But even the official React docs emphasize the importance of choosing the right structure for your application data and building your components around that data:

Since you’re often displaying a JSON data model to a user, >you’ll find that if your model was built correctly, your UI >(and therefore your component structure) will map nicely.
Thinking in React

Fortunately, there are simple principles that make modeling your application data very easy.

This article starts with the most important one:
The space our models cover should only include cases that are valid in our domain

A Simple Example: Building Cars

While the following example might not be very realistic for the average Typescript codebase, it's types are examples of two basic structures that are part of every codebase.

First Try Modeling Car Configurations

To build cars we might come up with the following types:

type PowerSource = "gas tank" | "battery"
type Engine = "electric motor" | "petrol engine" | "diesel engine"
type Fuel = "petrol" | "diesel" | "electrons"

type Car = {
  engine: Engine
  fuel: Fuel
  powerSource: PowerSource
}

Let's look at the Car type. There are three kinds of engines, three kinds of fuel and two different types of power sources.
Taking the product
2 x 3 x 3
we get 18 the number of all possible car configurations. At first, everything looks all nice and dandy. We are happy that Typescript prevents us from assigning random strings to our car parts, and we successfully prevent typos.

The following example shows a valid car.

const buggyCar: Car = {
  engine: "petrol engine",
  fuel: "diesel",
  powerSource: "gas tank",
}

but filling the tank and starting the engine leads to a nasty surprise:
Powering the petrol engine with diesel would be its certain death. Yet the combination is a valid type.
How could we design our types to prevent failures like this right away?

Designing Better Types for Our Car

We start by analyzing the domain, and right away, we see that there are only three configurations that would result in functional cars.

type ElectricCar = {
  engine: "electric motor"
  fuel: "electrons"
  powerSource: "battery"
}
type DieselCar = {
  engine: "diesel motor"
  fuel: "diesel"
  powerSource: "gas tank"
}

type PetrolCar = {
  engine: "petrol motor"
  fuel: "petrol"
  powerSource: "gas tank"
}

Now we can model the car type as one union of those interfaces:

type Car = PetrolCar | ElectricCar | DieselCar

The new type only includes our three functional cars because we get the number of cases by building the sum 1+1+1=3 instead of the product 2x3x3=18 of our previous types.
If we used the old types, we would need to use a combination of testing and documentation to prevent dysfunctional car configurations.

Why bother?

Typescript is helpful. Even the first types would have prevented bugs by catching small mistakes like typos. But typing our code can also communicate intent or knowledge to other developers. Maybe it could bring us closer to communities of other languages like Elm, Clojure or Haskell. We could benefit a lot.

What's next?

The following links are a good start for digging deeper:

-WHAT DO PRODUCT AND SUM TYPES HAVE TO DO WITH DATA MODELING?

-"Making Impossible States Impossible" by Richard Feldman

What do you think?

Tell me if Typescript changed the way you think about code? When we remove the types, does your Typescript code still look different from your JavaScript code?
Do you think Typescript brings us closer to learn from other communities?

Touch Typing- The Most Important Skill For Developers Nobody Talks About

David Sanwald — Thu, 02 Jul 2020 16:02:01 +0000

As a developer, the code I commit during a typical workday varies greatly, but about 8000 characters of code might be an okay estimate.
Before I learned how to touch-type, my typing speed was about 30 WPM.
That means I could type all of that in about 50 minutes. My current typing-speed is about 70 WPM, so I would only save 30 minutes per day.

As a developer, I'm not limited by the typing speed and thinking about code, reading code, looking for the right place to change that single line of code to fix a bug matter way more than my raw output of code.

All in all, it seems like touch-typing is only a minor optimization, so why was touch-typing the single most important skill I picked up as a developer?

Why Touch-Typing Matters

Many of the things that matter most to me might also be personal and subjective. But I still believe the following things are true not only for myself.

Syncing Code and Thoughts

The flow of thoughts is not consistent. Often we think in bursts. Further, our mind does not emit ideas in a linear self-consistent manner. Often we only can associate and combine ideas that did not directly succeed each other.
Touch-typing, to me, means less buff between thinking about code and writing code. I'm able to quickly type ideas I had to keep in my head before. Not being able to follow my thought process in the editor forced me to do more steps in my head.
Typing made the way I code more iterative. It's no problem at all writing code that will not be in the final commit. I often worried about writing clean code, which limited me and slowed me down. Now I'm able to write code without worrying about how it looks because immediately refactoring a line of code after typing it is so easy.

It's also about navigating and editing code

Before knowing how to type, I failed to get into using VIM (or its keybindings) countless times. I tried but never managed to build up muscle memory navigating and editing code the vim-way. Nobody told me that typing skills are almost a hard requirement for benefitting from VIM.
After I was able to touch-type (even though I was still very slow), it only took me a week to pick up enough VIM to feel productive.
Only a fraction of "writing code" is actually about writing code. It's easy to overlook how much working with code is about editing and navigating it.

It's not only code we type

Often we are focussed about writing actual code, that there are many more things that depend on being typed so that we can contribute them to a product/team/discussion:

code reviews
slack messages
documentation
user stories
stack overflow postings
...

Being Able To Type Without Looking is not the same as Touch Typing.

Here I can only speak for myself:
I could type without having to look at the keyboard. It's hard to explain but always using the same finger for the same keys when touch-typing still feels very different from before. The actual typing requires not nearly as much attention as before, and I can focus almost entirely on the code instead.

Why Nobody Talks About Touch-Typing

Among developers, there are two main groups.
Many developers learned how to touch-type at an early age at school. Therefore they take touch-typing as given and are not aware of how much it impacts their work.
The group of developers that did not pick up touch-typing during childhood would need to invest a lot of time and energy, learning how to type before actually experiencing the benefits.
Learning how to type takes time. After typing without a system for years, most people are still able to type quite fast. As developers, we depend on our efficiency. Learning how to type means becoming much slower at first, and this can be quite scary.
Therefore there are not too many people that learn how to type as adults.
For myself picking up touch-typing was more than worth it. Because I benefit so much from this decision every day, I want to share my experience, maybe even encouraging somebody picking it up, it's never too late.

My Touch-Typing Journey

Because I built up some muscle-memory by typing without a system for all my life, I struggled to relearn my finger movements.
For that reason, I chose the most radical way possible:

COLEMAK for the win

I took all the vacation days I had accumulated and switched my keyboard layout from one day to the other from QWERTY to COLEMAK.
To be honest, this was hell. Suddenly I couldn't type at all. Looking at the keyboard was not helpful anymore at all, because the letters on the keycaps did not match their actual letters.
I struggled to type even short URLs into the address bar of the browser.

To slowly relearn everything, I used the site https://www.keybr.com/ by starting with the smallest keyset possible.
To keep me from looking at my hands, I printed out a COLEMAK schema and put it on the wall behind my monitor.
As I finally progressed to the full keyset on keybr, I switched to https://www.keyhero.com/ for my daily training.
After two weeks, I was still slower than before but at least fast enough to start working again without being afraid of not being able to keep up.
From there on, I went from 6 hours typing practice a day to only 2 hours after work. After another month, I stopped practicing everyday and only practiced occasionally.
It took me about four months until typing felt like something natural to me. Today I'm still not too fast (about 70 WPM), but I think speed is only a minor factor for the positive impact that touch-typing had on my work.

Let me Hear Your Thoughts

What are your thoughts on this? Do you agree or disagree? Why?
I'm interested in all kinds of thoughts, opinions, and experiences. But I'd love to hear from people that picked up touch-typing at a later stage of their life and whether you had similar experiences.