DEV Community: Nicholas Kircher

How to code without loops - ever!

Nicholas Kircher — Sun, 19 Feb 2023 00:55:34 +0000

OH YEAH! It's a good day for some knowledge! It's time to talk about loops --- it's time to talk about loops --- it's time to talk about loops --- and how you can throw them out the window and replace them with something better! Prepare for the Defenestration of JavaScript ("Defenestration" means "to throw out the window").

I very often see - in my travels - code that looks like this:

const items = ['first', 'second', 'third', 'fourth', 'fifth', 'sixth'];

let foundItem;

for (item in items) {
  if (item.startsWith('s')) {
    foundItem = item;
  }
}

So if you're familiar with JavaScript/Typescript, which you are, this code should be fairly straight forward to understand. We're looking for an item in a list of strings where the first letter is 's', and if we find it, we assign it to foundItem. This is a "find" operation. We're looking for a specific element which matches our predicate condition. We only need one item, and once we've found it, we don't need to keep looking through the rest of the list. Therefore, our foundItem should be the string "second".
Right?

If you're eagle-eyed, you might notice that we are not stopping at the first matching element. We keep going. "Ok so lets add a break statement". Oh now we're really getting right into command and control here. What if I told you that all the code in that above example can be written in 2 lines, without simply compressing it, and without any mutation or variable reassignment, and stops searching after the first match?

const items = ['first', 'second', 'third', 'fourth', 'fifth', 'sixth'];
const foundItem = items.find((item) => item.startsWith('s'));

Welcome to the wonderful world of iteration methods! There is not a single thing that I can do with loops - EXCEPT IN INFINITE GENERATOR FUNCTIONS, DON'T @ ME - that I can't with simple iteration methods that are built-in.

Ever seen this kind of thing?

let newStruct = {};

for (item in items) {
  newStruct[item] = generateSomeRelevantDataFor(item)
}

Mutations are supremely dangerous. Even if you think you know exactly what is going to happen here, that can very easily change. All someone has to do is pass in an object from somewhere else - like a function argument - as the initial value for newStruct and now you are mutating a reference shared by who knows how many other things, and it changes for all of them. Also, doing things immutably is hip and fashionable, so try this instead:

const newStruct = items.reduce(
  (result, item) => ({ ...result, [item]: generateSomeDataFor(item) }),
  {}
)

This will build up your new object (each version of which is provided as "result") as it iterates over the items list, and we're doing it immutably. Spread operators don't directly copy that section of memory into a duplicate block of memory, either. This is all done by reference, so it's also a very efficient operation, and not memory-wasteful, nor does it require all that much more compute time. In return, we get the safety and assurance of an immutable operation. Pretty good deal!

There are SO MANY MORE powerful iteration methods, all built in, like: filter, map, flatMap, findLast, and reduceRight. It gets even better when you throw in a functional library like Ramda or FP-TS, and add all the category theory stuff to it (maybe that will be the next post? Who wants to learn some category theory? :D )

So I hope this inspires you to never use loop statements again. Why would you need to?

How 2 TypeScript: Get the last item type from a tuple of types

Nicholas Kircher — Sun, 02 Sep 2018 02:58:18 +0000

(Note: The author assumes you're using TypeScript 3.x)

Hey you! Do you want to get the type of the last item from a tuple of types?

Of course you do.

type Stuff = [number, boolean, string]
type OtherStuff = [string, number, object, boolean]

Here I have 2 tuple types, one with 3, and one with 4 items. The last type in Stuff is string, and the last type in OtherStuff is boolean.

How do we get those last item types?

Well, amazingly, one way we can do it - if we know the length of the tuple at time of writing - is to use a numeric literal as an index for looking up the type at a position. I know, amazing. Like so:

type LastStuff = Stuff[2] // => string
type LastOtherStuff = OtherStuff[3] // => boolean

Kinda like a normal array lookup!

But what if you don't know the length of the tuple? Hmm... how do we get TypeScript to tell us the length and then let us use that length to pick out the last item, all at compile time?

Borrowing from this amazing HKTs library I was able to get the length of the tuple as a numeric literal:

type GetLength<original extends any[]> = original extends { length: infer L } ? L : never

type Stuff = [number, boolean, string]
type OtherStuff = [string, number, object, boolean]

type LengthStuff = GetLength<Stuff> // => 3

Notice the infer keyword in this part: original extends { length: infer L } - I talk more about what the infer keyword is in the previous How 2 TypeScript post, so if you're confused, I hope that sheds a bit of light :)

But remember, lists are zero-indexed, so if we want the last item, we will need a way to do L - 1. We can't just do straight arithmetic at the type level in TS (yet), so this does not work: type LastItem = Stuff[GetLength<Stuff> - 1] (thats a syntax error for TS). So we're gonna need a map of some kind.

The approach I felt would be best was a type mapping from a numeric literal to the previous numeric literal. I found just such a type from this SimplyTyped library, which is essentially giving us n - 1 for anything between 0 and 63. Using this, I can input the length we inferred as L and get back the last index of that list, and use that to look up the last type. Like so:

// Borrowed from SimplyTyped:
type Prev<T extends number> = [-1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62][T];

// Actual, legit sorcery
// Borrowed from pelotom/hkts:
type GetLength<original extends any[]> = original extends { length: infer L } ? L : nevertype GetLast<original extends any[]> = original[Prev<GetLength<original>>]

// Here are our test-subject tuples:
type Stuff = [number, boolean, string]
type OtherStuff = [string, number, object, boolean]

// How long is the `Stuff` tuple?
type LengthStuff = GetLength<Stuff> // => 3

// What is the last element of each tuple?
type LastStuff = GetLast<Stuff> // => string
type LastOtherStuff = GetLast<OtherStuff> // => boolean

Boom! It's not perfect, but this is about as good as I could make it with the latest TypeScript version.

After thoughts:

I actually tried many, many different things to make this work. The first version that I got working used the "TupleTable" from the HKTs library to return to me the inferred type of the last item, using a lookup based on the length of the tuple. That felt a bit overkill for this task, and was limited to only 10 items. If I wanted to increase the limit, that tuple table would have to get much, much bigger.

Instead, I looked around for a way to do a bit of type-level arithmetic. If we say that any given tuple's length is n, then the last item of any given tuple is at n - 1. We know this from the countless times we've had to lookup the last item in an array in JS. In TypeScript, we can't (yet) do any arithmetic operations on numeric literal types natively, so if we go down this road, we will need a kind of mapping between numeric literals (so that given 5, we get back 4). It will also be of a finite length, but hopefully the complexity of the code won't increase significantly if we increase the max length by 1 (for example).

After searching GitHub, I found exactly what I needed. The Prev type from SimplyTyped will let us pass in a number (anywhere from 0 to 63) and it will give us the number before it. So, given 5, you get back 4. Until we get a built-in "successor/predecessor" type in TypeScript, I think this is about as good as it gets.

I'm actually quite surprised at the power of TypeScript's type system, compared to what I'm used to in Haskell and PureScript. There are still many limitations in comparison, and perhaps there always will be, but one thing is certain: TypeScript can hold its own in this cut-throat world of typed languages.

Until next time!

How 2 TypeScript: Serious business with TypeScript's infer keyword.

Nicholas Kircher — Fri, 31 Aug 2018 11:53:04 +0000

Hey you! Do you want to get the return type of a function and use it, without knowing what it really is, or asking the user of your thing to supply it outright?

Of course you do.

type GetReturnType<original extends Function> = 
  original extends (...x: any[]) => infer returnType ? returnType : never

Conditional types in typescript allow you to introduce type variables into the expression in a rather dynamic way. Notice the infer keyword. That says to TypeScript: "I want to take whatever TypeScript infers to be at this position and assign it to the name returnType". It just so happens that the thing at that position is the return type of a given function, that we have called original.

What happens when you put it into action? I AM SO GLAD YOU ASKED! Take this extremely powerful, useful, and all-round fantasmical Higher Order Function

const someRandomStuff = <fn extends Function>(originalFn: fn) => {
  const result: GetReturnType<fn> = originalFn(12345);

  return result;
}

The type of result is going to be whatever the return type of originalFn(12345) is. We don't actually know, until...

const innerFn = (item: number) => item.toString();

FYI, TS will infer the output of innerFn to be a string. Then...

const output = someRandomStuff(innerFn); // ALL SYSTEMS GO

Would you like to play a game? What is the type of output? The answer is: What is the type of innerFn?

It's a string!

If it weren't for this trick, the type of output would be any. I know, I was surprised too. But it's true.

You can do the same sort of thing with anything that TypeScript can infer. Wanna get the type of arguments?

type NYET = never // preparation for unfunny joke
type GetArgumentType<original extends Function> =
  original extends (...x: infer argumentsType) => any ? argumentsType : NYET

That's all, see you next time.

Overcoming the mental blockade

Nicholas Kircher — Tue, 07 Aug 2018 05:18:11 +0000

We all know the feeling. You've got a new task to do, and you can't think of how to implement it. Or; you've got an idea for something, and you can't decide where to start. No matter what it is, you have a problem to solve, but no ideas yet on how to solve it. No, you're not alone, and no you are NOT a bad developer.

I had this problem for a very long time, long through my development career, and it wasn't until recently that I found a trick to overcoming it. Please note, your mileage may vary. What works for me may not work for you, and it's no silver bullet, but I would recommend giving this a good try :)

First, lets use our imagination. Think about a situation where you are asked to build some sort of API layer on top of something. When I say an API, I just mean a series of functions or methods that perform certain related tasks. Let’s say, for example, that we needed to build a helper library in JS that generates media query strings. I built just such a tool for my Shades library (shameless plug, sorry).

The way I approached that task was to work backwards. Hang on, what? Let me show you. We know the end result, since it’s described for us already: we want to generate media query strings. This wrapper library needs to be able to generate any valid media query. So, first step, take a look at a few medium-sized media query examples, ones that combine a broad set of media query features, and at the same time lets work out what all the different individual types of value that can go into a media query.

Some examples taken from the MDN docs are as follows:

@media print
@media screen, print
@media (max-width: 1245px)
@media screen and (min-width: 30em) and (orientation: landscape)
@media screen, print and (min-width: 30em) and (max-width: 100em) and (orientation: landscape) and (color)

After looking at these and looking through the rest of the MDN docs on the subject, we find that media queries support the following things:

Media “Types”, of which there are only 4 possible values: all, print, screen, and speech, and one can have anywhere from 0 to all of these in a single query.
Media “Features”, most of which can accept a value of their own (such as width and height which accept pixel numbers), some which allow only one of a set of possible values (such as orientation, which can only be either portrait or landscape), and others which are implicitly set to true if you include then without specifying a value (such as color, or monochrome)
Logical Operators (such as not, and, etc)

Now we understand all the different possible values that can go in a query (or at least we know the different kinds!) and we have varying examples of what media queries can look like. They can be as small as just one value, of either a media “type”, or media “feature”. Alternatively, they can be as large as you want to go, including literally every possible “feature” and every valid “type”, including various logical operators and combinators. So, that’s quite daunting, but we don’t need to start by implementing each of these one by one! Not at all!

Let’s just start by imagining we had the perfect library already built, that we could use right now. If we needed to write a media query using this library, what would that look like? Imagine it as being the best JS library in the world for this task, without worrying about the implementation or complexity or anything yet. Pretend it’s all done for you. Let’s have a go at writing a media query with our amazing, magical pretend library. What I ended up writing at the very beginning as my “ideal api” looked something like this:

media.screen.portrait.width(950).hover

Which would translate into something like this:

@media screen and (orientation:portrait) and (width:950px) and (hover:hover)

Now we have an idea of what we really want to build! The end result may vary a little bit, but the general goal is very clear. We can now start writing our first test cases too! In the end, the actual API I built looks more like:

media().screen().portrait().width(950).hover()

Only slight changes, but changes are still ok. Just because we designed our API first doesn't mean it's set in stone. At least we now have a target to aim for.

I hope this method helps you just as much as it has helped me. Until next time!