Component helper in JS

[mehulkar]

It's possible to use the {{component}} helper in templates to specify a dynamic component name. This allows all kinds of polymorphic approaches to rendering data, which is awesome. However, as of now, it is not easily possible to bind a different set of arguments to dynamic components, which means that your components need to have the exact same API.

It's debatable whether or not this is a good idea, but if there was an equivalent to the component helper in JS, we would be able to construct a component with a different set of arguments.

The goal is to be able to do something like this:

{{#each this.items as |item|}}
  {{component item.component}}
{{/each}}

// app/controllers/index.js
export default Controller.extend({
  items: computed('model', () => {
    return this.model.map(item => {
      let component;
      if (item.type === 'foo') {
        component = createComponent('special-component', { arg1: item.name, arg2: item.type });
      } else {
        component = createComponent('default-component', { otherArg: item.name });
      }
      return Object.assign(item, { component });
    });
  });
});

This lets us use separate components based on item.type, but allows for flexibility in their API.

[sdhull]

I have also wanted the ability to do fooComponent = component('foo-display', {foo, bar}); in .js files. Usually I've figured out tricksy ways to work around the fact that this is impossible (typically by using the {{component}} helper in a parent .hbs context and passing it down) but I'm sure there are places where it would be clearer to simply instantiate the component renderer where it's needed.

I'd like to add that it would be awesome if instances of CurriedComponentDefinition were callable like a normal function (so that it might be renderable by 3rd party libraries). This is probably impossible but a guy can dream.

[sdhull]

Maybe

import { componentRenderer } from '@ember/component';

I'm not really sure where it would be appropriate to export such a thing. I also think it needs some sort of rendering context to work...?

[chancancode]

As I mentioned in the other thread, the difficulty here is passing bound arguments. Something like component(“foo-display”, { foo, bar }) is only going to work if you expect foo and bar to be const/unbound, which isn’t always going to be appropriate.

[Herriau]

@chancancode I wouldn't expect foo or bar to be bound. Talking from experience of the various use cases where we have leveraged our homemade createCurriedComponentDefinition() (see emberjs/ember.js#17509), we have rarely felt the need for any of the curried properties to be bound.

Most of the time these curried component definitions are created within computed property bodies or custom template helpers, so a change in any of the upstream values causes a new curried component definition to be emitted. This hopefully is handled efficiently by glimmer (e.g. if a new definition object is emitted but it has the same shape as the previous definition object then the old component shouldn't be completely torn down).

[mehulkar]

I wouldn't expect foo or bar to be bound.

ehh.. i'd expect it to work the same way as the component helper in the template, and since that's bound, I think this would be too. That would be a pretty huge ergonomics issue if they didn't behave the same.

[chancancode]

Most of the time these curried component definitions are created within computed property bodies or custom template helpers, so a change in any of the upstream values causes a new curried component definition to be emitted.

I think you are describing bound arguments 😉

This hopefully is handled efficiently by glimmer (e.g. if a new definition object is emitted but it has the same shape as the previous definition object then the old component shouldn't be completely torn down).

Nope.

ehh.. i'd expect it to work the same way as the component helper in the template, and since that's bound, I think this would be too. That would be a pretty huge ergonomics issue if they didn't behave the same.

I agree, but it would need some kind of different api/syntax, otherwise there is no way to track the property/changes.

[Herriau]

ehh.. i'd expect it to work the same way as the component helper in the template, and since that's bound, I think this would be too. That would be a pretty huge ergonomics issue if they didn't behave the same.

@mehulkar That just doesn't seem possible with the syntax you are proposing. But again I really don't see this as limiting at all. I would simply rewrite your example as:

// app/controllers/index.js
export default Controller.extend({
  mappedModels: computed('model.@each.{name,type}', function() {
    return this.model.map(item => {
      let component;

      switch (item.type) {
        case 'foo':
          component = createComponent('special-component', { arg1: item.name, arg2: item.type });
          break;

        default:
          component = createComponent('default-component', { otherArg: item.name });
      }

      return Object.assign({}, item, { component });
    });
  });
});

Nope.

@chancancode That's unfortunate. How is this handled today with the (component ...) helper? Wouldn't a change in upstream curried value cause a new curried definition object to be emitted there as well?

[chancancode]

@Herriau so long as the first argument to the helper doesn't change, the definition object is stable https://github.com/glimmerjs/glimmer-vm/blob/master/packages/@glimmer/runtime/lib/references/curry-component.ts#L40-L42

This works because the args are curried as references https://github.com/glimmerjs/glimmer-vm/blob/master/guides/04-references.md

[Herriau]

@chancancode Thank you for the exhaustive list of links. In that case, and if glimmer is to remain as such, it does indeed look like we would want a way for developers to pass values that are bound to some context.

In the few cases where we've needed this, we have resorted to alias() and reads() (which was possible in our case since our homemade createComponent() is based on EmberObject.extend()):

const component = createComponent('special-component', {
    item,
    arg1: reads('item.name'),
    arg2: reads('item.type'),
});

This isn't to say that computed properties should be supported at all, but syntactically-speaking I feel like this makes sense.

[knownasilya]

@Herriau I'd recommend creating it as an addon that people can use and find caveats and API limitations through that and then feeding it back into the RFC.

[mehulkar]

@chancancode @pzuraq does @tracked change the landscape here? If passed arguments are tracked, I'd imagine that a JS component helper would be able to update?

[ef4]

I do think tracked properties make it possible to revisit this.

As we move toward components as really first class values (meaning you can import a component into JS, pass it around, and eventually invoke it), I think the gap of not being able to curry in JS becomes more glaring.

[boris-petrov]

I believe this here is very much the same as #563, am I right?