Pass attributes to glimmer components when using (component) helper

[gossi]

This looks like a missing piece to achieve parity between "ember and glimmer" components when using the (component) helper.

With angle brackets and the distinction between arguments and attributes it is no longer possible to pass down attributes to those components. Everything in there will be turned into arguments.

Imagine, I markup my component that way:

<MyComponent @reallyImportantArgument={{this.foo}} disabled={{false}}/>

It will not work with a component helper:

{{component 'my-component' reallyImportantArgument=this.foo disabled=false}}

the latter "param" (disabled=false) will be passed as argument instead of attribute. One workaround is to use the let helper and use angle bracket syntax. However, this does not work when you want to yield a "preconfigured" component, e.g.

{{yield (hash
  MyComponent=(component 'my-component' reallyImportantArgument=this.foo disabled=false)
)}}

I don't know if this is already possible somehow or if this is in a need for a RFC to complete the feature set for octane.

[rwjblue]

It will not work with a component helper:

{{component 'my-component' reallyImportantArgument=this.foo disabled=false}}

... One workaround is to use the let helper and use angle bracket syntax.

Right, you could do something like this:

{{#let (component 'my-component') as |WhateverName|}}
  <WhateverName @reallImportantArgument={{this.foo}} disabled=false />
{{/let}}

But I agree that you are more likely to have issues when passing a "closure component" to someone (not when directly invoking with {{component, like in your example).

[rwjblue]

I do think we'd need an RFC to address this, either new syntax or a custom keyword/helper. Something akin to ember-component-attributes's syntax might work:

{{yield (hash
  MyComponent=(component 'my-component' (html-attributes disabled=false) reallyImportantArgument=this.foo)
)}}

[rwjblue]

@chancancode - Thoughts?

[pzuraq]

Could a second positional parameter alone be enough here? I mean, can it be a hash/object? E.g.

{{yield (hash
  MyComponent=(component 'my-component' (hash disabled=false) reallyImportantArgument=this.foo)
)}}

[rwjblue]

No, I don't think so because it's perfectly valid to have a component with arbitrary positional params. The reason I suggested a special helper was that we could then add the custom behaviors based on the helper being used instead of arbitrarily "taking over" the second (or last) positional params slot in every component.

[tstormk]

I have also been thinking about this, and in my opinion the cleanest solution would be to completely remove the component helper and instead allow standard handlebars to be passed as an argument. Something like this:

{{yield (hash
  MyComponent=(<MyComponent disabled={{false}} @reallyImportantArgument={{this.foo}} />)
)}}

Or:

<MyComponent
  @childComponent={{<OtherComponent />}}
/>

The best part of the new Octane features for me has been the simplification of various Ember features, and I think dynamic component invocation unfortunately is still one of the areas that is lacking in that regard. In fact, introducing angle brackets, named arguments, etc., has made the disparity between regular component invocation and dynamic component invocation worse. Unifying the two would be really nice.

[Exelord]

I agree with @tstormk. This would be awesome, but a little hard to imagine. 😅

About @rwjblue proposed solution:

{{yield (hash
  MyComponent=(component 'my-component' (html-attributes disabled=false) reallyImportantArgument=this.foo)
)}}

I think in this case we still wont be able to pass ...attributes to the component :/

[rwjblue]

I think in this case we still wont be able to pass ...attributes to the component :/

Hmm, why not? We can make html-attributes (or whatever we settle on) accept ...attributes as a positional param just the same as we can do for angle invocations.

[buschtoens]

The (html-attributes) approach would not support passing element modifiers.

[rwjblue]

@buschtoens - You are correct, adding (html-attributes) itself would not be enough to allow modifiers, but when used in conjunction with the (already merged, and currently being implemented) emberjs/rfcs#432 it would work nicely:

{{yield (hash
  MyComponent=(component 'my-component' (html-attributes disabled=false (modifier 'on' 'click' this.onMyComponentClick)) reallyImportantArgument=this.foo)
)}}

[NullVoxPopuli]

could a modifier not have similar usage here? I'm mainly concerned about string representation of invokable things (I know the component helper does exactly this, and I have an idea for that... but I don't want to derail this thread).

{{yield (hash
  MyComponent=(component 'my-component' 
    (html-attributes 
      disabled=false 
      (on 'click' this.onMyComponentClick)
    ) 
    reallyImportantArgument=this.foo
  )
)}}

[rwjblue]

I know the component helper does exactly this, and I have an idea for that

The string part there is unrelated to my point, in strict mode templates (#496) passing a string to the (component, (helper, (modifier will all be disabled.

[rwjblue]

Just wanted to chime in here on my strawman design (in #497 (comment)) and mention that @chancancode had a really good suggestion which wouldn't need to make a "magical" argument to (component:

{{yield (hash
  MyComponent=(with-attributes 
    (component 'my-component' reallyImportantArgument=this.foo)
    disabled=false
  )
)}}

[Exelord]

Awesome solution! I'm just wondering how could we pass this was ...attributes? Do we still need some "custom parsing" or can we implement another way?

[ro0gr]

While I really like an elegance of the with-attributes solution, in terms of dev experience, I believe, introducing smth like this would lead to unnecessary complexity in a day to day work.

It happens, when I have to move some of <AngleBracket invocation(or few, and that's where the pain begins) into a {{#let statement, so I can decide whether to yield or render it later in the template.

For instance, the following <AngleBracket:

<MyComponent 
  @class="{{cssScope}}-a"
  @value={{this.a}}
  @onSomething={{action "myAction"}}
/>
<!-- Do not use class attribute to keep parity with curly form -->

in a let statement would look like:

(component "my-component"
  class=(concat cssScope "-a")
  value=this.a
  @onSomething=(action "myAction")
)

Here is a list of manual changes I have to do each time when I just need to put a component to some var(or yield):

• replace <>|</> with (component ...)
• rename from CamelCase to dash-erized version of component name
• remove @s
• rewrite to (concat
• remove {{ }}s around values passed to arguments, e.g. ={{this.a}} => =this.a
• change helpers invocations from {{ }} to ( )

It's error prone.

Also, if we add something like with-attributes, it would add another manual step to the process.

I think, an operation like var assignment should not require any extra skills in dealing wih editor. It should be simple and reasonably fast.

Does anyone have an idea why mixing <Angles within {{curlies is a bad idea? Is it about some handlebars syntax limitations or extra work needed for tools like syntax highlighters?

In case it's a design decision to avoid deeply nested <Angles within curlies, does it sound better if we restrict with only self-closing <Angles /> when inside curlies?