parser: support data-dojo-mixin? about delite

[ccmitchellusa]

Could we define a d-mixin custom element to do the behavior mixin, rather than custom parsing of data attribute, eg.

<d-treemap data-mixins="">
   <d-mixin>dtreemap/Keyboard</d-mixin>
</d-treemap>

[wkeese]

I'm not sure why we would do that. It seems more complicated.

[cjolif]

The alternative is to ask users to redefine their own tag:

register("my-treemap", [TreeMap, Keyboard]);

and then use it:

<my-treemap></my-treemap>

I think this is very linked to #27. If we don't get auto-loading, then honesty this is probably not dramatic to ask people to do this as they will anyway have to manually import the TreeMap module. But if we keep the idea of being able to simply write markup and not have to deal with JavaScript to import/instantiate modules then having to fallback to JavaScript for the mixins won't fit the strategy.

In other words, if we don't implement #27 and close it I think this makes sense to be "consistent" and close also this one. If we implement #27 then I think we should do something for that one as well so that the pure markup solution is complete.

[cjolif]

register("my-treemap", [TreeMap, Keyboard]);

won't work, apparently it needs to be:

register("my-treemap", [HTMLElement, TreeMap, Keyboard]);

despite TreeMap is already and HTMLElement.

Maybe we should have a helper function?

TreeMap.createSubWidget("my-treemap", [Keyboard]);

It should both include HTMLElement automatically and do the registration?

like we had in Dojo 1.X? Under that conditions it might be easier to accept the lack of data-dojo-mixins?

[wkeese]

register("my-treemap", [TreeMap, Keyboard]);

is supposed to work. I guess there's a bug; I'll look into it.

[cjolif]

Maybe there is something specific to the TreeMap that breaks this. Basically the widget is created but at runtime things like properties expected to be here are not and things like that.

[wkeese]

For the record, I talked privately to @cjolif and he couldn't reproduce the problem with

register("my-treemap", [TreeMap, Keyboard]);

I did add some unit tests (in register.js) to make sure that sort of thing works.

[wkeese]

For browsers that have native custom element support, you associate a prototype with a custom tag. I don't think it's practical or prudent to switch-out that prototype with a custom class we define on the fly.

So, if we did support data-mixin, the "classes" that we mix in would need to be lightweight objects. Perhaps a mixin would just be a function that would setting up advice on the main classes pre-existing methods.

[wkeese]

if we did support data-mixin, the "classes" that we mix in would need to be lightweight objects. Perhaps a mixin would just be a function that would setting up advice on the main classes pre-existing methods.

Realistically I don't see us doing that (although it would be an interesting experiment). Thus I'm closing this ticket and also #27 for now.