Proposal: named and bound deconstructions

Michael Rosefield rosyatrandom at gmail.com
Wed Jan 24 15:25:24 UTC 2018


Well, deconstruction is already mostly just syntactic sugar to accomplish
related things in a single, concise, declarative step; this seems like a
natural extension of that philosophy.

Why add extra steps like below when you don't have to? I want JS to be as
expressive as possible.
```
const { foo, bar, baz } = obj;
[ foo, bar, baz ].forEach(fn => fn.bind(obj);
// VS
const { ::foo, ::bar, ::baz } = obj;
```

On Wed, 24 Jan 2018 at 13:59 Isiah Meadows <isiahmeadows at gmail.com> wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180124/439b61f9/attachment-0001.html>


More information about the es-discuss mailing list