Hacker News Reader

Comment by shadowofneptune | Hacker News Reader

I would have liked to see examples. My own instinct here would be to use simpler types, but examples could show why that isn't desirable.

View on HN

Agreed. I updated the blog to add an example. Copy/pasting here:

I spend a decent amount of time in the redux world so `redux-toolkit` is a great library to see how types are done *correctly* in a real codebase. To be clear, they do a fantastic job with types, but the level of complexity is pretty startling.

https://github.com/reduxjs/redux-toolkit/blob/master/package...

That is just one example but the codebase is riddled with complex types. Also, when you look around, note the amount of types vs actual code.

It's pretty common in style guides to never nest ternaries. In typescript, that's the only way to narrow types based on other types. It's a mess!

Thank you.

Along the lines of "just use a dynamic language", we use unknown and any type for a lot of our internal stuff like this.

Strongly typed shell, whatever works core.

They probably just keep running into issues that seem really trivial but are unable to find info on fixing. It's the reason I put off writing things in typescript until relatively recently.

In that vein, if anyone here can tell me how the hell you functionally map over a typed object by key in typescript I'll be eternally grateful.

I always wanna do something like Object.keys(typedObjName).map(...) but that doesn't work.

It's so stupid and small and minor and it's never really prevented me from getting something done but it drives me out of my mind that I still can't find any clear documentation on how to do it.

Do you have an example for what you want to do, with an object before and after mapping? I don't understand what you mean by "functionally map over a typed object by key"

I think I have run into a similar issue. I wrote a lexer in Typescript. It is table-based, as is the parser that runs after it. The type for the table looks something like this:

    type TokenTable<T> = {
        plus: T,
        minus: T,
        bang: T,
        parenOpen: T,
        //etc.
    };

I also have a type defined as 'type TokenID = keyof TokenTable<unknown>;' this makes it possible to check if a string is a valid key at compile-time. The innermost loop of the lexer is a for..in loop. This gives you the keys of the object. One problem: if you try to apply the TokenID type to the loop variable, you get this message: "The left-hand side of a 'for...in' statement cannot use a type annotation." Because of the design of JavaScript, TS cannot give object keys any other type but 'string', even though this type seems like a clear match.

To get the typechecking back on the keys, you either need to declare the loop variable outside of the loop itself, or use type casting like this:

    let token = "";
    let id: TokenID | undefined;
    for (let key in patterns) {
        const match = patterns[key as TokenID].exec(substring);
        if (match && (match[0].length > token.length || key == "EOF")) {
            token = match[0];
            id = key as TokenID;
        }
    }

Neither is particularly clean.

Can you define a const array with type Array<TokenId> and use it every time you want to loop through these keys?

That's a possibility, yes. This is the only time in the program that a token table is iterated through, however. Most of the time a table is consulted to pursue an action in the parser. For example, there's a function table for when a statement is encountered, another for when an expression operand is encountered, etc. Each entry in the table is either an error message or code which completes the parsing of that statement. The awkwardness above is excusable when it is encountered so little. When writing expression-heavy stuff like 'Object.keys(typedObjName).map(...)' it's more of a problem.

You can approximate something by defining the valid TokenTable keys as an enum, and using a mapped type for the actual TokenTable type.

There's some boilerplate in the definition, but it's fairly clean and non-repetitive. And easy to use in the "client code".

https://www.typescriptlang.org/play?#code/KYOwrgtgBAKg9ga1AS...

You put some real effort into the example. It's the opposite approach of how I did it, yet works just as well. Thanks!

You can also write the array first, without using enum:

const tokens = ['parenOpen', 'bang', 'plus', 'minus'] as const;

type Token = typeof tokens[number];

type TokenTable<T> = Record<Token, T> // alias for { [key in Token]: T }

const isToken = (t: string): t is Token => tokens.includes(t);

const patterns: TokenTable<RegExp> = { bang: /\+/, // rest }

I can't really think of like, a practical use case but here's a jsFiddle of what I mean.

https://jsfiddle.net/knvztxq7/ ^ that code will work, it outputs the key names to the console

https://jsfiddle.net/knvztxq7/1/ ^ that code... is also working even though I swear it hasn't worked for me before so now I think I'm actually just losing my mind.

Yeah wow I can't reproduce my error now... I'll come back here if I figure out what I did.

Object.entries(typedObjName).map(([key, value]) => `${key}${value}`)

> I always wanna do something like Object.keys(typedObjName).map(...) but that doesn't work.

Is this a type space/value space thing? Like Object.keys(...) is always a string[] instead of Array<keyof TypedObj> like you might expect?

possibly but the error (that I can't seem to get anymore) was always saying something about TypedObj missing an iterator, making Object.keys() unable to parse it. But I'm not getting that anymore so I have no idea what's going on. Like I said it's just a minor thing that's popped up a few times so I guess I'll just have to wait until it pops up again to know for sure what's up.

I suspect it’s a case of bolting on types to soupy JS but would also love to see some examples. I agree with the other commentators that part of the point of a library is to suck in complexity but if you’re regularly doing high level type kungfu there are probably bigger structural issues.

Reply on news.ycombinator.com