Get currently destructured object

# Michał Wadas (9 years ago)

Idea:

function foo({bar, *: baz}) {

}

would be equivalent to:

function foo(baz) { const bar = baz.bar; }

Rationales:

  • little better IDE support (argument name reveals intention)
  • allows to write more concise code when handling case of getting common values and handling whole object optionally
  • improve pattern "use few properties of options object then pass it deeper"
  • allows more expressive module import
  • allows to more concise code when destructuring expression result

import {: rand, generateRandomInt} from 'fancy-random-module'; import {: moment, isMoment} from 'moment';

# Isiah Meadows (9 years ago)

How is it any different than this, to borrow your first example:

function foo(baz) {
    const {bar} = baz
    // do things
}
# Caitlin Potter (9 years ago)

Pedantic nitpick for no reason: NamedSpecifiers of an ImportDeclaration are different from “destructuring”, conflating the two is likely to confuse people =)

# Tab Atkins Jr. (9 years ago)

On Thu, May 19, 2016 at 8:59 AM, Michał Wadas <michalwadas at gmail.com> wrote:

Idea:

function foo({bar, *: baz}) {

}

would be equivalent to:

function foo(baz) { const bar = baz.bar; }

Rationales:

  • little better IDE support (argument name reveals intention)
  • allows to write more concise code when handling case of getting common values and handling whole object optionally
  • improve pattern "use few properties of options object then pass it deeper"
  • allows more expressive module import
  • allows to more concise code when destructuring expression result

import {: rand, generateRandomInt} from 'fancy-random-module'; import {: moment, isMoment} from 'moment';

Other languages with destructing have a more explicit syntax for this (giving a name to the container as well as its pieces), so that it works in all the destructuring forms. In Haskell, for example, it looks like "baz@{bar}". This is usable with list destructuring, too.

# G. Kay Lee (9 years ago)

I suspect OP misunderstood the destructuring syntax, otherwise it made zero sense to me... FYI in the case of ({foo: bar}) => { ... }, bar is the

alias of someObject.foo, not the other way around.

And it's a bad idea because instead of an ad-hoc solution which is gonna waste another potential operator character slot I'd really like to see some general purpose pattern matching mechanism in place.

# Bob Myers (9 years ago)

Although I agree this is somewhere between unnecessary and undesirable, it does raise a semi-valid related point that there's no way to make a destructured parameter const.

function foo({const a, const b}) { ... }

function foo (const {a, b}) { ... }

function foo(o) {
  const {a, b} = o;
}

Bob

# Michał Wadas (9 years ago)

Yes, in such simple case you save only few keystrokes.

Imagine more complicated example:

function initServer(config) { const {env, database, cache, logger} = config; const {isDev} = env; implementLogger(global, logger, isDev); return Promise.all([databaseProvider(database), cacheProvider(cache), envManager(env)]).then(([database, cache, env])=>({database, cache})); }

It can be replaced by simpler:

function initServer({env: {isDev, *: env}, database, cache, logger, *: config}) { implementLogger(global, logger, isDev); globalLogger.log(config); return Promise.all([databaseProvider(database), cacheProvider(cache, isDev), envManager(env)]).then(([database, cache, env])=>({database, cache,

env})); }

When destructuring nested objects you can potentially save one line per nest.