DEV Community: Sam Wight

Today in TypeScript: the keyof operator

Sam Wight — Thu, 02 Dec 2021 17:26:17 +0000

Sometimes when you're trying to index on an object TypeScript will give you an error like this:

interface User {
  name: string;
  email: string;
  password: string;
}

function printUser(user: User) {
  const keys = ["name", "email", "password"];

  for (const key of keys) {
    console.log(user[key]) // Error! Element implicitly has 'any' type
    // because expression of type 'string' can't be used to index type 'User'.
    // No index signature with a parameter of type 'string' was found on type 'User'.
  }
}

Let's figure out what's going on here.

Breaking it down

First, if we break out user[key] into a variable and hover over the variable, we can see that it has the type any:

Why is this happening? TypeScript tells us in the error. Let's look at the error again:

Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'User'.
  No index signature with a parameter of type 'string' was found on type 'User'.(7053)

Starting with the first line, TypeScript tells us that user[key] has the type any. The reason why it's giving us this error is because noImplicitAny is turned on.

Element implicitly has 'any' type

Why is this happening? TypeScript tells us that it's because a string type can't be used to index on type User.

because expression of type 'string' can't be used to index type 'User'.

Where's this string type coming from? Well, we're using the variable key to index on user, so let's look at its inferred type:

Ah, that makes more sense! TypeScript thinks that key is of type string. This comes from the type of keys, which is string[].

The reason why TypeScript doesn't allow us to index on User with type string is because it doesn't have an 'index signature':

No index signature with a parameter of type 'string' was found on type 'User'.

An index signature is a thing you can add to interfaces when you only know the key and value types of an object. It tells TypeScript to allow you to index on an object with much broader types. For example, this:

interface UsersTable {
  [id: string]: User;
}

would tell TypeScript to allow us to index on UsersTable with anything that is of type string.

This is the important part: if we don't have an index signature, TypeScript will have a stricter default. TypeScript will only allow us to index on an object if the variable we're using to index is assignable to the union of the keys of that object. So in the case of User, TypeScript will only allow us to index with a variable assignable to the type "name" | "email" | "password". (You can read on type assignability here).

This means that we need key to have a type of "name" | "email" | "password", or something narrower (a subset of that, for example "name" or "email" | "password"). How do we fix that?

Fixing the problem: Solution One

The first way we can fix this is pretty simple. Let's write out the type that TypeScript wants:

type UserKey = "name" | "email" | "password";

And let's tell it that keys is an array of UserKeys:

  const keys: Array<UserKey> = ["name", "email", "password"];

This works! The error goes away and TypeScript is happy.

To make sure we understand why, let's go back over the inferred types of the variables. keys is of type Array<UserKey> (or UserKey[]), which means key is now of type UserKey. UserKey is shorthand for "name" | "email" | "password". Because "name" | "email" | "password" is assignable to the union of the keys of User, TypeScript lets us index on it. And now user[key] doesn't have an any type and is of type string. Here's a TypeScript playground where you can experiment with this.

Yay, we fixed the error! But there's one small problem: what if we add keys to User? What happens then? Well we'd have to update the UserKey union with the new keys we added. There's also the potential to misspell a key or forget to add one, which TypeScript will scream at us for.

Fortunately, there's a way around this. The keyof operator.

Solution two: The `keyof`operator

Here's the documentation for the keyof operator in the TypeScript handbook. The docs tell us that keyof does this:

The keyof operator takes an object type and produces a string or numeric literal union of its keys.

So this does exactly the same thing as what TypeScript does under the hood for indexing! keyof takes an interface / object and returns the union of all of the keys in it. So for our User interface, it would return "name" | "email" | "password".

We can now use this to shorten our UserKey definition:

type UserKey = keyof User

This works exactly the same as before, but now if we update User, we don't have to touch UserKey. Pretty great!

How to rename your main Git branch to main

Sam Wight — Wed, 17 Jun 2020 02:38:17 +0000

I've been seeing a lot of talk lately about renaming the default GitHub branch to main. I think this is a really good idea! Something simple that promotes inclusion is always something that I will support. Thankfully, Git branches are built to make changes like this extremely easy. In this (very short) post, I'll show you how to rename your main Git branch to main, and how to update the default branch on GitHub. Overall, this should take you about five minutes total. Just five minutes!

The commands

First, here's the commands to change your default branch name to main:

git branch -m old_branch_name main
git push --set-upstream origin main

The first command renames old_branch_name (your default branch name here, whatever that may be) to main. The next branch pushes that new main branch to the remote. Replace origin with whatever remote you use for your main repo host. Once you run these commands, you'll have your brand new main branch. Isn't that cool!

Updating GitHub

If you're using GitHub like I am, then updating your default branch is a little bit more involved. First, navigate to Your Repo → Settings → Branches. There, you should be able to change the default branch to main.

If you don't want to keep the old branch name around, you can easily delete it (after all, it was easy enough to create!). Navigate to the root of your repo and click on the branches icon (the one with the number of branches your repo has). You should then be able to delete your old branch name.

Congrats, you've now renamed your default branch to main!

Centering a div with Flexbox

Sam Wight — Mon, 08 Jun 2020 18:27:15 +0000

I saw the tweet below on my timeline today:

// Detect dark theme var iframe = document.getElementById('tweet-1270049224378507267-467'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1270049224378507267&theme=dark" }

Here's a simple, no bullshit guide to centering content with CSS using Flexbox. Make sure to check the Flexbox CanIUse to make sure your target browsers have good support for it, otherwise this might not work.

Creating the skeleton

To start, let's write some HTML. parent-div is the element that will hold the child div that we want to center.

<html>
  <head>
    <title>Flexbox CSS Centering Example</title>
  </head>
  <body>
    <div id="parent-div">
      <div id="child-div">
        <h1>This is an example</h1>
      </div>
    </div>
  </body>
</html>

If you're wanting a good place to play around with this code in the browser, I recommend using CodePen. Here's the pen with the HTML used for this post. Just type in the CSS as we go along and you'll see everything updated in real time.

Our goal will be to get the child-div post centered within the parent div, both horizontally and vertically. We'll start by adding flexbox to the parent. Before we do this though, let's add some backgrounds to each of these elements so we can see where the browser is rendering them. Ugly, I know.

#parent-div {
  background-color: red;
}

#child-div {
  background-color: black;
}

Adding Flexbox to the parent

Making an item display using flex is simple: just use the display: flex; CSS property.

#parent-div {
  background-color: red;
  display: flex;
}

You shouldn't notice any changes in how the element is rendering yet. Let's add some height and width to parent element, making it the height and width of the browser viewport:

#parent-div {
  background-color: red;
  display: flex;
  width: 100%;
  height: 100vh;
}

Centering the content

Now that we have a parent element the width and height of the screen, let's center the child element horizontally and vertically inside the parent div. We'll use the justify-content and align-items CSS properties to make this happen:

#parent-div {
  background-color: red;
  display: flex;
  width: 100%;
  height: 100vh;
  justify-content: center;
  align-items: center;
}

And now we should see the child element centered inside the parent div!

Thoughts on Glimmer

Sam Wight — Sat, 15 Feb 2020 05:59:29 +0000

This post was originally published on my blog. I have a "Daily Jots" series where I post short, unedited posts every day about random topics. Take a look if you're interested.

I’ve recently gotten into learning Ember.js for a new project I’m wanting to create (my hackathon registration system, Registrar). While doing so, I came across Glimmer, Ember’s new component engine that’s been extracted from the framework. Glimmer’s been around since 2017 (or a bit earlier), but it was kinda revolutionary for its time: it’s a VM written in JavaScript that efficiently parses bytecode that’s compiled from Handlebars templates. There’s a number of large benefits to this:

Parsing and compiling JavaScript takes a significant amount of time. There’s a reason why the Chrome team recommends that if you’re passing down large amounts of JSON content, you use JSON.parse to process it instead of just including it in your JS. Browsers can run JSON.parse() faster than they can process the raw object in JavaScript because JavaScript is a more syntactically complex language. The same goes for things like React apps. It takes a significant amount of time to process and compile the hundreds or thousands of React.createElement() calls that there might be in a typical React app, which results in a longer First Meaningful Paint. Glimmer gets rid of this entirely by just reading in a raw binary, which doesn’t have to be parsed at all. Zero parse.
Glimmer also extracts the strings out of the compiled Handlebars and lets the bytecode reference individual string locations in a root string array. It also deduplicates this array, which means that you’re saving size across your entire app.
Glimmer is actually set up as two different VMs: an append VM and an update VM. Because Glimmer can see what variables are used where in your Handlebars templates, ti can use update bytecode to efficiently update only the DOM attributes that need updating when a dynamic variable has changed, instead of having to re-render the entire application like in React. Again, these were conversations going on in 2017, kinda before the whole “package size” talk became mainstream with Svelte. Glimmer overall just seems pretty amazing.

If you want to learn more about all of this, here’s a few resources I highly recommend checking out:

Let's Write: An Auto-Currying Higher Order Function

Sam Wight — Tue, 25 Jun 2019 13:37:33 +0000

I've been working on a project lately that involves writing a lot of callback functions, and some of them were getting pretty large. I decided to move as many of them as possible to separate modules to keep things small and relatively simple, but noticed that a lot of them depended on the parent function's scope. Functions in Javascript can't inherit the scope of something that they can't see. The easy way to fix a problem like this would just be to write a function that accepts the scope variables needed and then returns the callback function. This works because the returned callback function will inherit the scope of the parent (the passed variables). So something like this:

const helloCallback = (instanceArg1, instanceArg2) =>
  (callbackArg1, callbackArg2) => {
    // Both instance args and callback args are in scope here!
  }

export default helloCallback

would be called like this in a listener in a separate module:

import helloCallback from './helloCallback'

pretendAPI.onMessage(helloCallback(arg1, arg2))

It's a pretty simple and elegant solution! In the functional programming world, we call something like this currying (using this very loosely). True currying is where you split all of your function arguments over consecutive functions like Russian dolls. It looks like this:

const helloCallback = instanceArg1 => instanceArg2 => callbackArg1 => callbackArg2 => {
  // all the variables are in scope!
}

This wasn't really optimal for what I needed though, so I just split my function over two different levels.

For the hell of it, I decided to write my own function that would automatically curry any function. It would be used like this:

const curried = curry((one, two, three, four) => console.log(one, two, three, four))

and could be called in any of these ways:

curried(1)(2)(3)(4)
// Output: 1 2 3 4
curried(1, 2)(3, 4)
// Output: 1 2 3 4
curried(1, 2, 3, 4)
// Output: 1 2 3 4

And did I mention that it's only 8 lines long? Let's see how I wrote it.

There's a few pieces of information we need to know before we're able to write this curry function. First, what the hell is going on here? If we look at how the function is used, we can see that curry accepts in a function and then returns another function. There's an important thing to note here: the function that's returned is not the same as what we passed in. The function that's returned will either return the value of our original function with all of the arguments somehow magically applied, or it will return another function that accepts more arguments in. It might not be immediately obvious at first, but there's some kind of recursion going on in the curry function because we're returning a different number of functions depending on the inputs to each previous function.

With this in mind, we can start writing the skeleton of the curry function:

const curry = functionToCall => {
  const recursiveSomething = () => something => {
    if (someCondition) return functionToCall(someArgs)
    else return recursiveSomething()
  }

  return recursiveSomething()
}

Let's look at this line by line. Our curry function accepts in an argument called functionToCall that we'll eventually call (great naming, amiright?). Then on the next line, we define a recursive function that returns another function. The function name is just used here so that we're able to recursively return functions as needed; as far as I know, it isn't possible to return anonymous functions that can be called recursively in Javascript. The returned function accepts in some arguments, and depending on someCondition we'll either return functionToCall with some arguments passed down to it or we'll return the results of a call to recursiveSomething, which is the function we're currently in. Last, we call recursiveSomething, returning our conditional-return function mess.

This may look pretty complicated, but we've actually got half of the function written. All that's left to do is fill in the blanks. The main problem we're trying to solve here is argument storage: we need some place to put all of the arguments we're going to receive so that we can pass it down to our "callback function" in one go. The easiest way to do this is to just use a rest parameter, an array to store all of the arguments in, and then just spread that array over the functionToCall's arguments when we call it:

const curry = functionToCall => {
  let argumentsArray = []
  const recursiveSomething = () => (...args) => {
    argumentsArray = argumentsArray.concat(args)
    if (someCondition) return functionToCall(...argumentsArray)
    else return recursiveSomething()
  }
  return recursiveSomething()
}

Going through the lines we added, we can see that we added an array argumentsArray that's outside of the recursiveSomething function. This is important because it's in the scope of not only the root recursiveSomething return function, but all future returned functions. In the return function, we added a rest parameter (allows our function to accept in unlimited arguments and puts them in an array), and then concatenated that with the argumentsArray. Last, we used spread syntax to apply the arguments in the array to functionToCall when we call it.

This is great, we're actually really close to finishing our auto-curryer! We just need to fill in when we'll call functionToCall, or the base case for our recursive function. We want to call functionToCall if and only if we have all of the arguments we need to actually call it. Functions in Javascript have a length property, so we can use this to check whether the length of argumentsArray is equal to the number of arguments expected by the function:

const curry = functionToCall => {
  let argumentsArray = []
  const recursiveSomething = () => (...args) => {
    argumentsArray = argumentsArray.concat(args)
    if (argumentsArray.length === functionToCall.length) return functionToCall(...argumentsArray)
    else return recursiveSomething()
  }
  return recursiveSomething()
}

And that's it! We can now pass curry a function and it'll automatically curry all of the arguments for us thanks to the magic of recursion! Not bad for only eight lines. If you want, you can also add a few more checks to support zero argument functions and to make sure you call the function correctly:

const curry = functionToCall => {
  if (functionToCall.length === 0) return functionToCall;
  let argumentsArray = [];
  const recursiveSomething = () => (...args) => {
    if (
      (args.length === 1 && argumentsArray.length + 1 > functionToCall.length) ||
      (argumentsArray.length === 0 && args.length > functionToCall.length) ||
      args.length + argumentsArray.length > functionToCall.length
    )
      throw new Error("Wrong number of arguments received");
    argumentsArray = argumentsArray.concat(args);
    if (argumentsArray.length === functionToCall.length) return toCall(...argumentsArray);
    return recursiveSomething();
  };
  return recursiveSomething();
};