Adding positional parameter support to components

[ef4]

A longstanding pattern is to use helpers to simulate components with
positional parameters. But under Glimmer, helpers are pure functions, so
this doesn't work anymore.

Thankfully, we can do something even better, which is to stop wrapping
components in helpers just to get positional params, and instead make
components that can natively accept positional params. That's what this
PR does.

To use, you define your component like:

Ember.Component.extend({
  positionalParams: ['name', 'city']
});

Then you can invoke it like:

{{my-component "Ed" "Somerville"}}

Which is (nearly*) equivalent to:

{{my-component name="Ed" city="Somerville"}}

This depends on a corresponding change in htmlbars.

* The one caveat is that as a new feature, this does not get the legacy auto-mut support that normal attributes get.

[ef4]

@rwjblue pointed out that there's another legacy behavior that's not supported for these new positional params: they are not available in the component init method.

[ef4]

I think Travis is failing because it's using a cached version of htmlbars and not my updated one.

[rwjblue]

Yes, we would have to clear the cache for it to pass. I'd rather merge and release upstream, then update package.json with the new value here.

[rwjblue]

Please update to 0.13.14, just released upstream PR.

[Samsinite]

Would like to see something that allows arbitrary number of params instead... what about supporting an interface that allows the use of arbitrary parameters?

Maybe:

Ember.Component.extend({
  mapPositionalParams: function(foo, bar, ...args) {
    return {
      one: foo,
      two: bar,
      rest: args
    };
  }
});

[Samsinite]

@rwjblue @ef4 thoughts?

[ef4]

It would be fairly easy to make varags work like:

Ember.Component.extend({
  positionalParams: ['name', 'city', '...rest']
});

[Samsinite]

The map function just allows the programmer more flexibility define assignment to the component while still being just as easy to understand with slightly less "magic". The important thing to me though is supporting variadic components.

[rwjblue]

I would be in favor of using a string to indicate that all params go to a specific prop to handle the varargs scenario. Something like:

export default Ember.Component.extend({
  positionalParams: 'params'
});

Having this.params (when needing var-args) does seem nicely congruous with this.attrs....

[Samsinite]

Sounds good, would you guys like a PR for this? I wouldn't mind adding that support.

[azizpunjani]

@ef4 Could you please give an example of the long standing pattern you mention in the statement "A longstanding pattern is to use helpers to simulate components with
positional parameters. "?

I've looked around to find examples of this pattern you mention but have not found any relevant code.

[stefanpenner]

I've looked around to find examples of this pattern you mention but have not found any relevant code.

{{each positionalArg}}

{{link-to positionalArg1 positionArg2 etc..}}

[rwjblue]

{{input}}

[mmun]

{{link-to}}