Mixin component as attributes

[wclr]

VOTE HERE

Injecting (attaching) components via attributes

<div my-comp="myCompOptions" another-comp another-comp-prop="anotherProp">
  <some-content/>
</div> 

components my-comp and another-comp should be attached to the div element (in specified order), so it would be quite the same as template markup:

<div>   
  <my-comp prop1="myCompOptions.prop1" prop2="myCompOptions.prop2">
      <another-comp prop="anotherProp">
          <some-content/>
      </another-comp>
  </my-comp>
</div>

but resulting DOM won't include wrapping tags: "my-comp" and "another comp" and all the events will be bound to "div" element.

A component can also be attached to custom tags:

<some-comp my-comp="myCompOptions"></some-comp>

To allow this for components to be injected via attributes they could be declared as:

can.Component({
   tag: 'my-component',
   attribute: 'my-component'
   ...
})

Passing attributes

<div my-comp="myCompOptions"></div>

Would take myCompoOptions from parent scope and mix (extend) them into my-comp initial scope (with two-way binding)

Or attributes could be passed individually

<div my-comp my-comp-prop1="myCompProp1" my-comp-prop2="myCompProp2"></div>

Accessing scopes on the element

Well can.scope API could be extended to allow this

can.scope(element, tagName, attr)

if "tagName" fits to one of the "attached" components it will work with corresponding scope if no it will treat "tagName" as "attr" argument and work with default scope.

Extending component with other components

As upper suggestions assume actually ability to have several components on the element and some kind of multiple inheritance we could also extend component while definition:

can.Component({
    tag: 'some-comp',

    attach: [
        {'my-comp': 'myCompOptions'},
        {'another-comp': {
           'prop': 'anotherCompProp'
       }}
    ]

})

"attach" property here is an array because the order of injecting of components is significant

so putting

<some-comp></some-comp>

would be the same as

<some-comp my-comp="myCompOptions" another-comp another-comp-prop="anotherCompProp"></some-comp>

[justinbmeyer]

The arguments passing style isn't great, but overall, I like it.

[justinbmeyer]

@whitecolor Do you still support this issue? Hopefully, can.view.tag gives you enough power to be able to mix in behaviors.

The problem with something like:

<div my-comp="myCompOptions" another-comp another-comp-prop="anotherProp">

Is "who owns" the template?

I think a better solution would be enabling Components that don't have a "template" or "tag" property to be added via can.view.attr like:

var MyComp = can.Component.extend({
  scope: { ... },
  events: { ... }
});

can.view.attr("my-comp", MyComp);

Thoughts?

[justinbmeyer]

Related: #1376

[matthewp]

What is the goal here, why do you want to have components as attributes rather than tags?

[wclr]

first reaso was to have "headless" components (without wrapping tag), another reason multiple components on one element. I'm not sure if it really appropriate.

[matthewp]

Headless components makes sense, I'm not understanding the reason behind multiple though... can.view.attr is great for mixins and #1376 has a way to make a higher-level plugin for those.

[wclr]

yes multiple components ont a big issue can.view.attr can be used, though component propose more robust API (scope, events) for creating comprehansive behaviour model.

Headless components would be intresting to have though.

[matthewp]

I like suggestion here, essentially a component with no tag and no template, allow that to be passed into can.view.attr. What do you think?

[wclr]

I think this would be fine.

[justinbmeyer]

Adding the label can-component. I'm going to try to run through all component related issues and move them as a group to the can-component repo. My hope is that I can consolidate some of them.

[justinbmeyer]

Closing for: canjs/can-stache#15