1

I'm seeing weird behaviour when using containerless functionality for aurelia components. We're creating custom elements for in SVG container, which required us to use containerless tag to strip the custom element tags before adding it to the DOM, as only SVGElements tags are allowed within a SVG container. We're using Aurelia release version 1.0.0 and build our SPA with webpack.

Here you can find a gistrun example which displays the 2 implementation of containerless usage. https://gist.run/?id=58ba6282ad54c1263eec3a141fe42183

In this example i've created 2 viewmodels and bind this to our custom elements. Using as-element="compose" to tell aurelia that i've created the viewmodel and that Aurelia shouldnt create a VM. The difference between these to custom elements are the containerless tag:

  1. CustomElement doesnt have the @containerless tag in the Viewmodel but have 'containerless' in the HTML view.

  2. withattr component does'nt have 'containerless' in the HTML view, but it does have the @containerless tag in the Viewmodel, as described in the Aurelia HUB.

I expect in both situations that I would see a blue rectangle. customelement tags are stripped by Aurelia because of the containerless tag. however the @containerless tag doesnt seems to work, as in implementation 2.

Question: Any clue why these implementation have different outputs? Which is the correct one? I would expect 2, as stated in the Aurelia Docs that the @containerless tag should be placed on the viewmodel.

Any help would be appreciated :)

kabaehr
  • 1,040
  • 11
  • 18
Henry
  • 21
  • 3

1 Answers1

0

The @containerless decorator works directly on the element you place it on.

What's happening is that the decorator is applied to your withattr element, but as-element="compose" turns it into a compose element under the hood. This compose element then does not have the @containerless tag applied to it.

Likewise, with your customelement you are in fact not applying @containerless to customelement, but to the compose that it is turned into.

Remove the as-element="compose" part and simply declare your <withattr/> element naked in the markup, and containerless will work because the actual element will still be withattr.

Note that it's not recommended to use @containerless with as-element unless there is no other way to accomplish something, as is the case with using custom elements inside table elements.

Why not simply have a compose inside your custom element, and bind the path to the view through a bindable property on the custom element?

EDIT

Sorry, I kind of overlooked the fact that you wanted to specify your own ViewModel instance.

This requirement limits you to using the compose element because that's the only way Aurelia supports providing your own ViewModel instance.

It's also certain that you need @containerless. And you need that @containerless to be on the compose element.

Conclusion, your first solution seems perfectly fine from a technical perspective.

As a matter of personal preference, I would do this:

<compose containerless view.bind="'./customelement.html'" view-model.bind="customElementViewModel"/>

Instead of this:

<customelement containerless as-element="compose" view-model.bind="customElementViewModel"/>

To be a little more flexible with dynamic views, make it clearer that we're using compose, and not having to <require> the view. But that really boils down to preference and other requirements.

Fred Kleuver
  • 7,797
  • 2
  • 27
  • 38
  • Thanks for the clarification. When you removing `as-element="compose"`, aurelia will create the ViewModel automaticly instead of our own created VM, giving us more control about the VM. Correct, not recommended, but we need the `@containerless` tag because we're using SVG elements, without containerless the SVG components won't appear as only SVGElements are allowed. I'll have a look tomorrow about your compose suggestion. Ran out of time today. – Henry Sep 27 '16 at 16:07
  • Oh I did not argue the `@containerless` itself necessarily, just the combination with `as-element` that is particularly sensitive to browser-specific quirks. Is there a specific reason why you want to control instantiation of the VM? Perhaps there's a different way out.. – Fred Kleuver Sep 27 '16 at 16:29