Passing in generic parameter types into functions

[sebinsua]

I'm also doing types-in-js at my current workplace. It's very nice to be able to write types but not increase the build-time and not have to teach TypeScript to people who've not shown an interest in writing types in their code. This also allows us to remain at almost zero transpilation, which is a breath of fresh air.

Unfortunately there is one big issue that I've found, which is that it doesn't seem to be possible to pass in generic parameter types into functions.

I'm wondering if others know of any good way to hack around this? Do we know if the TypeScript team is interested in fixing this?

Right now my general tactic is to ensure that the inner value is forced to be a particular type, since this generally causes the correct overall generic type to be inferred.

e.g.

import { useState } from 'react';

// ...

const [value, setValue] = useState(/** @type {string | undefined} */ (undefined));

import { atom } from 'recoil';

// ...

/**
 * @typedef {{
 *   a?: string,
 *   b?: string,
 * }} BasicState
 */
const basicState = atom({
  key: "basicState",
  /** @type {BasicState} */
  default: {
    a: undefined,
    b: undefined,
  },
});

Etc...

Where it gets difficult, is in Recoil#selector logic with setters, since at this point the T you are trying to affect is quite deep, and you want to only /** @type {Type} */ in one place and don't want to break or recreate any other aspect of the overall type.

[Raynos]

I've found a similar problem with simple types like new Map()

/** @type {Map<string, string[]>} */
const m = new Map()

There's no syntax for passing type parameters , typescript team did make a comment about improving inference.

From reading the source code of selector() it looks like it returns RecoilValue so maybe you can do

/** @type {RecoilValue<??>} */
const x = selector(...)

[Raynos]

The alternative answer is to accept that JSDoc has limits in its expressiveness and to use a dumber library with a less-generic and more verbose API.

This is something very common in the golang eco system because they literally have no generics.

I've also found that when writing JSDoc, sometimes I just refactor code to be more type-stable and monomorphic, less generic basically.