Apologies for being ungrateful: this doesn’t reflect how I use this pattern – I don’t see the parameters as a whole, I see each parameter individually. As a work-around, I inline the type and don’t define it externally.

Let me try to convince you, one last time (then I’ll stop pestering you), of the usefulness of a better notation for destructuring (nested destructuring will profit, too!). The following is an extreme example, but there are many similar functions in my code (“Showoff” is the name of my slide framework):

function slidesToNodeTree(
  {conf, configShowoff, inputDir, slideDeckDir, slideFileName, parentPartNode, visitedSlideFiles}
  : {conf: ConfigSlideLink, configShowoff: ConfigShowoff, inputDir: string,
    slideDeckDir: ServePath, slideFileName: string, parentPartNode: PartNode,
    visitedSlideFiles: SlideFileDesc[]}) {
  ···
}

With a better notation:

function slidesToNodeTree(
  { conf as ConfigSlideLink, configShowoff as ConfigShowoff, inputDir as string,
    slideDeckDir as ServePath, slideFileName as string, parentPartNode as PartNode,
    visitedSlideFiles as SlideFileDesc[]}) {
  ···
}

Alternatively:

function slidesToNodeTree(
  { (conf: ConfigSlideLink), (configShowoff: ConfigShowoff), (inputDir: string),
    (slideDeckDir: ServePath), (slideFileName: string), (parentPartNode: PartNode),
    (visitedSlideFiles: SlideFileDesc[])}) {
  ···
}

Note how, in the last two examples, you actually see parameters with names (vs. a single type for all parameters). The first example looks messy, the last two examples don’t.

If you have ever used a programming language with named parameters and liked them there – isn’t this a compelling use case? Given the thumbs-up at a recent comment of mine, there are quite a few people who agree.

This is the only aspect of my plain JavaScript code that became less usable after I moved to TypeScript.

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions