Extended dot notation (pick notation) proposal

Kris Siegel krissiegel at gmail.com
Mon Sep 5 23:45:13 UTC 2016


Hmm I gotta say I must have re-read that minimally extended dot notation
proposal a few times and I just find the syntax confusing. I do like the
idea of building a way of taking a portion of an object out of one object
and into another but I don't think we need to provide additional syntax
rules to handle this. Why couldn't this be an Object.pick() addition where
it works similar to the underscore implementation? It could even be
expanded to handle deep nesting (I'm actually adding this to my msngr.js
library in the next release as grabbing a subset of an object is crazy
useful and I need to do it far too frequently).

Isiah's workaround works but has the unfortunate side affect of copying
values / increasing reference counts to objects. I'd love to see a built in
solution.

On Mon, Sep 5, 2016 at 2:38 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> TypeScript has a fair number of proposals aiming to address this (things
> like difference types, partial types, etc.), but in general, I find it just
> as easy to do it this way (which is easily checked):
>
> ```js
> const {toDate, fromDate, location, flavor} = this.state;
> const goodKeys = {toDate, fromDate, location, flavor};
> ```
>
> On Fri, Sep 2, 2016, 16:08 Bob Myers <rtm at gol.com> wrote:
>
>> Here's another StackOverflow question
>> <http://stackoverflow.com/questions/39299046/destructuring-a-subset-of-an-object-directly-into-a-new-object>
>> essentially asking for pick notation. This same question pops up regularly.
>> It's the real world talking to us telling us what they need. In this
>> particular case, the solution with extended dot notation would just be
>>
>> ```
>> var goodKeys = this.state.{toDate, fromDate, location, flavor};
>> ```
>>
>> Perhaps I have not posted the minimal version of my proposal for this
>> pick notation
>> <https://github.com/rtm/js-pick-notation/blob/master/minimal/spec.md>,
>> also known as extended dot notation.
>> This version sacrifices some features in favor of complete compatibility
>> with existing destructuring syntax following the dot.
>>
>> There is another good reason these days for thinking about something
>> about this: *the advent of typed dialects of JS*.
>> We already know that a simple lodash-type version of pick, such as
>>
>> ```
>> function pick(o, keys) {
>>   return Object.assign({}, ...keys.map(key => ({[key]: o[key]})));
>> }
>>
>> const o = {a:1, b: 2};
>> const o2 = pick(o, ['a']);
>> ```
>>
>> cannot handle renaming or defaults or deep picking, but in addition *it
>> cannot also not be typed properly*.
>> For instance, `lodash.d.ts` defines `pick` as:
>>
>> ```
>> pick<TResult extends {}, T extends {}>(
>>   object: T,
>>   ...predicate: (StringRepresentable|StringRepresentable[])[]
>> ): TResult;
>> ```
>>
>> with no type safety whatsoever.
>>
>> In contrast, with pick notation
>>
>> ```
>> const o2 = o.{a};
>> ```
>>
>> `o2` can be precisely typed by the compiler as an object containing the
>> property `a`, or a type compatible or assignable to that type.
>>
>> --
>> Bob
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> 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/20160905/c8c03116/attachment-0001.html>


More information about the es-discuss mailing list