Proposal: named and bound deconstructions

Michael Rosefield rosyatrandom at
Wed Jan 24 12:35:28 UTC 2018

Deconstructions are great, but have some pain points I'd like to address.

*Named deconstructions*

When deconstructing elements of an object/array, you lose any reference to
the object itself. That reference is useful, not only in the trivial way of
being able to simply use it as per normal, but to clarify intent.

const someMiddlewareFn = (original, updated, next) => {
  const [ { name }, { name: newName } ] = [ original, updated ]; // any
useful deconstructions
  if (name !== newName) { // do stuff }
  return next(original, updated);
In that example we can't deconstruct `original` or `updated` in the
parameter definition, because we have to keep references to them to pass to
`next`; we have to do it in the function body, instead.

By keeping the named parameters, though, we glean more information as to
the intent of the function: `original` and `updated` directly imply that
we're comparing state changes.

There might also be occasions when we want to do something like this:

const { bar } = foo,
      { baz, blah } = bar;

Here, we might find it useful to get deconstructed references to both `bar`
and its properties `baz` and `blah`, but we have to do it in two steps.

I propose that we use a symbol to signify that we wish to keep a reference,
in passing. We should also allow for renaming, which is made slightly
awkward because the current renaming syntax prevents further deconstruction.

*Suggestion (using !-prefix)*

const { !bar: { baz, blah } } = foo, // no renaming
      { bar: !myBar : { baz, blah } } = foo, // renaming

     someMiddlewareFn = (!original: { name }, !updated: { name: newName },
next) => {
        if (name !== newName) { // do stuff }
        return next(original, updated);

I think that this should be clear to interpret for both coders and JS

*Bound deconstructions*

Some methods rely on their context being bound to their containers, and
require extra binding faff if you want to extract them; this is the
pain-point area that the binding operator proposal is intended to address.

My 2nd suggestion is that we co-opt its `::` syntax for use in

const { ::foo } = bar;
// equivalent to
// const foo =
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list