rtm at gol.com (2016-09-06T17:08:17.934Z)
> 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. You'd have to do that anyways, even if it's entirely internal. How do you think you would do it outside of copying the values?
> 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. You'd have to do that anyways, even if it's entirely internal. How do you think you would do it outside of copying the values? On Mon, Sep 5, 2016, 19:45 Kris Siegel <krissiegel at gmail.com> wrote: > 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/20160906/08782906/attachment.html>