DEV Community

Advanced TypeScript: reinventing lodash.get

Aleksei Tsikov on September 05, 2021

As a part of a backoffice team in a financial organisation, I have to deal with a lot of complex data structures: customer personal data, transacti...

Read full post

Alexey Grinko • Sep 6 '21

Why use lodash get when the path is static (i.e. you know it in advance)? For the first example just use user?.address?.street, and your code is perfectly readable and type-safe.

If still wanna use get for some reason, add an explicit type cast:

(get(user, 'address.street') as UserInfo['address']['street'])
  .filter(...)

This helps to understand the type from the first glance, especially when you look at the code not in your IDE but somewhere where types can't be inferred easily, e.g. on GitHub. And if type of 'street' property changes, you'll be alerted.

On the other hand, lodash's get is really useful when your path is determined dynamically in runtime, e.g. generated by some algorithm or provided by backend. And that's where inferring type is just impossible without an explicit runtime check.

So why complicate things to solve unrealistic problems?

P.S. Would be cool to see a real-life scenario for using this feature.

Aleksei Tsikov • Sep 7 '21

Yes, I absolutely agree with you. For static paths, it's definitely better to prefer regular field access with an optional chaining. However, _.get is still widely used, and some might find it easier to replace a function call or augment lodash typings.

Speaking of type-casting, in the first place, you want to avoid it as much as possible. This thing makes type checking looser, and after all, that's not why we are enabling strict flag, right? In this particular case, you are giving TS a hint that this any is a more specific type. But get anyway returns any, and if for some reason type of address.street changes, TS will not complain. In the end, any could be cast to literally any type.

Regarding dynamic paths, of course, not every case is covered (and GetFieldType should probably return unknown when the field is not found). But this approach still works when you have a union of possible values

type Letter = 'alpha' | 'beta' | 'gamma'

const symbols = {
  alpha: { symbol: 'α' },
  beta: { symbol: 'β' },
}

function getSymbol(letter: Letter) {
  return symbols[letter]?.symbol // TS error: Property 'gamma' does not exist on type
}

function getSymbolWithPath(letter: Letter)/* : string | undefined */ {
  return getValue(symbols, `${letter}.symbol`)
}

And anyway, you could think of this article as an exercise to better understand template literal and conditional types 🙂

As for a real-life scenario, we use it in a slightly different, a bit less dynamic way, to create strongly-typed APIs similar to react-table columns config. But that's a topic for another article 😉

Austin Lee • Nov 1 '22

Hello, I have used your code with little change to adapter _.get() method and create a pull request github.com/DefinitelyTyped/Definit.... All lodash user can enjoy the feature now, thanks for your working! XDDD

Braden Napier • Jan 18 '23 • Edited

How about adding in support for properly typing the return type so that default value is known uinstead of undefined | default? (Should be Typescript 4.8+ to support {} as "any non null | undefined value")

export function getValue<
  TData,
  TPath extends string,
  TDefault = GetFieldType<TData, TPath>,
>(
  data: TData,
  path: TPath,
  defaultValue?: TDefault,
): GetFieldType<TData, TPath> extends {}
  ? GetFieldType<TData, TPath>
  : TDefault;

Roger Padilla • Sep 16 '21

Thanks a lot for sharing this @tipsy_dev !

I'm building a library and this could be really useful there. Do you know if/how to add type-safety in the path of the properties via template literals? I mean, not to return undefined but to make the compiler ensure the path is a valid path.

E.g.

interface User {
  email?: string;
}

interface Group {
  name?: string;
  creator?: User;
}

So if we do:

// compiles
GetFieldType<Group, 'creator.email'>;

// produces compilation error
GetFieldType<Group, 'creator.invalidPath'>;

Is there a way to do this?

Ran Lottem • Sep 14 '21

Great read!
To tell arrays apart from tuples - arrays have a length property of type 'number' whereas for a tuple the length property is a specific number. After checking that T is either an array or a tuple (using T extends unknown[], maybe?), it should be possible to tell them apart using number extends T['length']?

Sahan • Sep 7 '21

This post makes me fall in love with Typescript (again!) Very well done 🎉

Aleksei Tsikov • Sep 7 '21

I'm in love with TypeScript for the last four years, and it feels like it's one of the best things that happen to JS community 🤩

Kirill Glazunov • Mar 31 '22 • Edited

Thanks a lot @tipsy_dev. It is a great approach. But you missed some cases: string[number][number], [number].string etc.

I did add it here: tsplay.dev/mAjB8W . Check it out please. You can find result types at d.ts tab at the right panel.

QuickMick • Apr 17

this is f*cking insane. why would you do that. imagine somebody new comes to the project - there is no way to understand this type stuff in a reasonable amount of time.
this is a prime example of why not to use typescript. just create a function that does what you need instead of messing around with these weird types. how would you debug that?

Scott Busche • Sep 10 '21

Wouldn't it be possible to add this type inference to _.get's typings, why do you have to make a new method?

Austin Lee • Nov 1 '22

yeah, I'm agree with you. so I create a pull request to @types/lodash with the code, now you can update to latest version if youo use _.get()

Aleksei Tsikov • Sep 6 '21

Thank you! I'm glad you liked it 🙂

Tim • Sep 6 '21

Is there a way to avoid 3 levels of ternary operators? Even 2 levels is hard to read.

Aleksei Tsikov • Sep 7 '21

Unfortunately, TS doesn't support conditional operators, so it's not possible to concatenate a few expressions with &&. The only way I know is to extract each ternary operator into a dedicated type, similar to how it is done with FieldWithPossiblyUndefined and IndexedFieldWithPossiblyUndefined. But to my mind, it adds even more boilerplate.

Matan Yadaev • Sep 6 '21

Wow, mind blowing! I don't use typescript on my day job, but this just makes me feel bad about using regular js.

Aleksei Tsikov • Sep 7 '21 • Edited

You definitely should give it a try! In the end, regular js is a perfectly valid ts code, so the transition might be not that hard as you imagine it 🙂