Extended dot notation (pick notation) proposal

Bob Myers rtm at gol.com
Fri Sep 2 20:07:55 UTC 2016

Here's another StackOverflow question
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
<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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160903/cab55278/attachment.html>

More information about the es-discuss mailing list