Is there an equivelent of splattributes for the {{component}} helper?

Hey Folks,

So I’d like to be able to take an object that I have, eg test = { foo: 'bar', hobbit: 'narnia' } and pass it, splattribute style, to the component helper: {{component ...test}}. This being the equivalent of {{component foo='bar' hobbit='narnia'}}. I can’t quite figure out the best approach though.

I came across this stackoverflow post from a couple years ago, but I’m curious about what is the best way to do that in the Octane world of octane, angle brackets and splattributes.


There is an RFC around splarguments and there’s an addon called ember-spread which I’ve used in the past but I’m guessing it’s not fully octane compatible.

1 Like

Have you tried the ember-component-attributes addon? It was for adding attributes in curly-brace syntax.

Thanks @melsumner. That’s not quite what I’m looking for. Sorry for the lack of clarity.

I guess the technical description of what I’m trying to achieve is splat-arguments, not attributes. I’m building an object of data that will eventually represent all the arguments that an arbitrary component should receive.

An ideal scenario would be something along the lines of:

{{component @componentName ...@componentArgs}}

You’re not alone in wanting it! There’s an (in-progress) RFC aiming for “splarguments”. Two notes:

  1. In the future, with a template “strict mode” (see the WIP RFC here), dynamic invocation will be a bit different: it will not be string-based, but will require you to actually pass a reference to a specific component. There will be a good design to support this, though: template imports at a minimum will be helpful for enabling it.

  2. Given (1), I think you’ll just be able to use ABC to pass components around; if and insofar as we still have something like {{component}} I think the need for it would be limited to doing partial-application-of-arguments (the way {{fn}} does for functions).

I’d like to see “splarguments” land, as I think they make a lot of “decorator”-style component patterns dramatically nicer, and as such they’ll be a substantial quality-of-life improvement. Definitely still some serious design work to be done there, though.

In the meantime, one could definitely write an addon which supplies an AST transform that makes ...@args work. Doing so might in fact be really helpful input for the design of that RFC! What works? What doesn’t? What are the weird edge cases? etc.