Components about msx

[lhorie]

That should work

[insin]

Current test output:

ok 15 <Component/> -> Component
ok 16 <Component></Component> -> Component
ok 17 <Component>X</Component> -> m.component(Component, {}, "X")
ok 18 <Component id="test"/> -> m.component(Component, {id:"test"})
ok 19 <Component id="test">X</Component> -> m.component(Component, {id:"test"}, "X")
ok 20 <Component id="test">X{X} X {X}</Component> -> m.component(Component, {id:"test"}, "X", X, " X ", X)

@lhorie what do you think about these, particularly 17 (no attributes, children) and 20 (multiple children) ? I don't have a feel for what will and won't work in terms of passing children to Mithril components.

My assumption is that if you needed to pass both an args/options object and some child contents to a component, your view signature would end up something like this (rather than forcing children into an array - which is another option).

view(ctrl, args, ...children)

On 17, if you wanted to implement a component which optionally took args/options and children, you'd have to start checking arguments passed to view to determine which was which - forcing an empty arguments object in the case of a tag which has no attributes but has children is currently just an opinion based on a hunch.

[lhorie]

I'd say make 17 output m.component(Component, {}, ["X"]) and 20 output m.component(Component, {id:"test"}, ["X", X, " X ", X]).

Unlike m(), m.component does not have a comp, ...children overload (with attrs omitted), and the view always receives attributes as the second parameter. The rationale for this is to avoid creating boilerplate for handling multiple overloads.

Components do allow unlimited number of arguments, but I think sticking to m.component(Component, AttrObject, ChildrenArray) is preferable because it caters to the simplest way to handle children in the component (i.e. no arguments splicing required)

It's a bit unfortunate that the HTML syntax doesn't leave room for us to disambiguate between ["X"] and "X", so I think the best thing to do is assume the most common/flexible case.