Splat operator

[mixonic]

I've been fielding several requests for a splat operator in Ember templates. Specifically, when using Ember components. For example given:

{{! presuming myHash === { keyA: 'val', keyB: context.someProp } }}
{{my-component *myHash}}

It would de-sugar to:

{{my-component keyA="val" keyB=someProp}}

This proposal is limited in scope.

• It does not propose a way to de-sugar params from an array, only properties from an object into the hash. I find it useful to consider the params case in designing this API though, presuming that it would use the same syntax but simply vary behavior at runtime based on the contents of the splatted variable.
• I propose that only a single splat be allowed.

Grammer proposal

OPEN helperName param* hashSplat? hash? CLOSE

Visually, it makes sense to put the splat before any hash arguments. This would aid in the understanding that hash arguments should take precedence. For example given:

{{! presuming myHash === { keyA: 'val', keyB: context.someProp } }}
{{my-component someParam *myHash keyB="I take the crown!"}}

The hash would be { keyA: 'val', keyB: 'I take the crown!' }. This is actually runtime behavior, and could vary according to implementation, but seems a good justification for the above ordering.

It is also suggested that subexpressions would also accept a splat. For example:

{{my-component someParam=(translate *translateOptions)}}

Alternatives

It has been suggested by @wycats that we consider ...myHash, as it aligns more closely with JavaScript splatting. This seems reasonable, I'd like some more thoughts.

/cc @kpdecker @mmun @krisselden @wycats @chrislopresto

[mmun]

I like this. It would be useful for Ember components. I prefer *. Perhaps ... for params.

[kpdecker]

Being a bum on vacation right now but quick comment:

Allowing this for hash and not array parameters feels weird and I suspect that people are going to ask for array as well. The only thing that I can think of to support that would be having a separate syntax for one vs. the other:

{{foo someParam ...restParams *hashParams myKey=myValue}}

[mmun]

Some more context for the discussion: https://github.com/sebmarkbage/ecmascript-rest-spread

tl;dr: The JS syntax { x, y, ...z } has been proposed and looking like its going to make it in.

[kpdecker]

That doesn't help us since {} vs () is unambiguous but our parameter constructs aren't. We need to have an explicit way for hash rest to be defined vs array params rest since we can't trust runtime type of or similar (I.e. What do we do with an iteratable? Is that a hash rest or an array rest? At what point will this surprise the hell out of users or limit optimization?)

[mmun]

I agree it doesn't help (it hurts). Just mentioning.

[kpdecker]

Some of this is probably bike shedding. If someone were to implement this changing the exact tokens used is pretty trivial. Concept is great, we just need to sort out the "ui" and make sure the performance isn't negative (which i don't expect since this seems like it should be isolated to users of the feature)

[wycats]

This feels like a decent feature but we have relatively little room for new syntax at this point without falling off the complexity cliff, so I agree with @kpdecker. Let's tread carefully.

[mixonic]

Seb's rest spread is an interesting idea, though not quite certain to become reality afaik.

In JS, we have the context of usage to differentiate array from property spread. [ ...someItems ] is presumed to be a spreadable array, { ...someItems } would be presumed to be an object.

Handlebars has no equivalent context. Given {{foo ...someItems}} there is no way to know if params or hash are being spread. I believe this means we require two syntaxes (one for params, one for hash).

My suggestion is to reserve ... for params and introduce * for hash.

Happy to take any next steps that seem appropriate.

[wycats]

@mixonic the more direct precedent from Python and Ruby is * for params and ** for hash 😄

[workmanw]

👍

Functionally speaking, I believe this concept is need to fully replace Ember.ContainerView with {{each}} and {{component}}. @amk221 concisely highlights the concerns here: emberjs/ember.js#11377 (comment).

More details also in this discourse discussion: programmatically-rendering-ember-components

[mmun]

My vote is ** for hash, * for params. They should be allowable anywhere inside the respective hash/params. Basically

param
  : helperName -> $1
  | sexpr -> $1
  | ONE_ASTERISK ID -> ...
  ;

and

hashSegment
  : ID EQUALS param -> new yy.HashPair(yy.id($1), $3, yy.locInfo(@$))
  | TWO_ASTERISKS ID -> ...
  ;

[mixonic]

I have warmed to **. Taking the lead from Ruby feels better than trying to ride the edge of an uncertain wave with ...

[mmun]

The only thing left to figure out is where splats can appear. Since they aren't ambiguous, I think they should be allowable anywhere where they make sense (as described in the grammar in my last comment).

[kpdecker]

I think there are a few questions that need to be answered:

1. If multiple instances are allowed, what are the semantics? For *, would concat occur? For ** extend?
2. Tied to that, what is the expansion pattern for different values passed to it? I.e. what happens with {{foo *object **array}} vs. {{foo *array **object}}
3. Anyone volunteering to implement this? :)