Proposal: named and bound deconstructions

Isiah Meadows isiahmeadows at gmail.com
Wed Jan 24 13:59:25 UTC 2018


What can this do that a second variable declaration can't, apart from
the auto-binding syntax (which already feels a little more like a
tack-on feature rather than something that fits)? And beyond a "that's
nice" kind of thing, how would this bring substantial benefit to the
programmer?
-----

Isiah Meadows
me at isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Wed, Jan 24, 2018 at 7:35 AM, Michael Rosefield
<rosyatrandom at gmail.com> wrote:
> 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
> engines.
>
> 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
> https://github.com/tc39/proposal-bind-operator is intended to address.
>
> My 2nd suggestion is that we co-opt its `::` syntax for use in
> deconstructions:
>
> ```
> const { ::foo } = bar;
> // equivalent to
> // const foo = bar.foo.bind(bar)
> ```
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list