Components don't work with ES6 classes.

[Naddiseo]

Since ES6 classes need to be called with new and this needs to be an instance of the class, components will not work with a class. The issue stems from here: https://github.com/lhorie/mithril.js/blob/next/mithril.js#L554

Example (using babel-compiled class): https://jsfiddle.net/1prjtv78/

A work around is to wrap the component controller like:

var Component = {
   controller: function () { return new ComponentController(...arguments); }.
   view: View
};

Which transpiles to something equally ugly:

var _bind = Function.prototype.bind;
var Component = {
   controller: function () { return new (_bind.apply(ComponentController, [null].concat(arguments)))(); }.
   view: View
};

Example of working: https://jsfiddle.net/1prjtv78/1/

Perhaps the parametize.controller function can do something similar to the transpiled code.

[tobyzerner]

You might be interested in how I've integrated ES6 classes with Mithril components in my project: https://github.com/flarum/core/blob/master/js/lib/component.js

Usage:

class FooComponent extends Component {
  constructor(props) {
    super(props);

    this.showing = m.prop(true);
  }

  view() {
    return m('div', this.showing ? this.props.content : '');
  }
}

m.mount(document.body, FooComponent.component({content: 'bar'}));

Note that the component class itself is the controller, and the view is its method. It's a bit more like React.

[Naddiseo]

That's some tricky/non-obvious code going on in component(), at first I couldn't remember what this refers to inside a static method, then I wondered "where does this.props come from?". But, interesting idea none-the-less.

An aside: I notice you don't allow parameters to the view function. I was arguing this with a co-worker today. I think a component's view should allow for arguments so that you can pass in a child vdom. For example, say you have a component that is logically a container, wouldn't you want to be able to pass in the child virtual dom to the component's view?
An overly simplistic example:

class MyContainer {
   view(ctrl, children) {
      return m('div.cool-class', {}, children);
   }
}

function View(ctrl) {
   return m('div', [
      m.component(MyContainer, [m('div', "I am a child")])
   ]);
}

m.mount(document.body, {view: View});

As for using view as a method: I'm still undecided on this in my code for two reasons:

• Extra level of indent
• Separation of concerns (template vs logic) in the same file and same object.

I do like being able to use this inside of the view though

[barneycarroll]

TL;DR: this isn't how Mithril works. Why would you want it to work this way?

The purpose of the components structure is to provide 2 objects — a
controller constructor and a view function — such that Mithril internals
can generate and store instances of the controller according to internal
logic and pass those specific instances to the view function during redraw.
The Mithril internals that depend upon this association take care of
controller initialisation under the hood, so on the face of it whether or
not a component is a constructor or not isn't a user-land issue, except for
the fact that if the user were to generate new instances of a component
whenever they invoked it in the view, you would expect the controller
instance to be lost, what with a new object being consumed by the view —
except it isn't, because Mithril manages association internally and the old
controller instance would persist depending upon circumstances. Meanwhile,
this consistently refers to the controller instance within the controller
itself, meaning that any attempted access to this or super would be
inconsistent.

On Wednesday, 13 May 2015, Richard Eames notifications@github.com wrote:

That's some tricky/non-obvious code going on in component(), at first I
couldn't remember what this refers to inside a static method, then I
wondered "where does this.props come from?". But, interesting idea
none-the-less.

An aside: I notice you don't allow parameters to the view function. I was
arguing this with a co-worker today. I think a component's view should
allow for arguments so that you can pass in a child vdom. For example, say
you have a component that is logically a container, wouldn't you want to be
able to pass in the child virtual dom to the component's view?
An overly simplistic example:

class MyContainer {
view(ctrl, children) {
return m('div.cool-class', {}, children);
}
}
function View(ctrl) {
return m('div', [
m.component(MyContainer, [m('div', "I am a child")])
]);
}

m.mount(document.body, {view: View});

As for using view as a method: I'm still undecided on this in my code for
two reasons:

• Extra level of indent
• Separation of concerns (template vs logic) in the same file and same
  object.

I do like being able to use this inside of the view though

—
Reply to this email directly or view it on GitHub
#618 (comment).

Regards,
Barney Carroll

barney.carroll@gmail.com
+44 7429 177278

barneycarroll.com

[Naddiseo]

@barneycarroll, to whom are you directing that comment? If it's me: mithril should be agnostic whether or not my "controller constructor" is a plain function, ES5 class/object, or ES6 class, but it shouldn't break in the case it is an ES6 class. My problem is that mithril changes this inside the component constructor with definitely is an issue as it breaks the assumption of any constructor no matter where it's a constructor for. Nothing about using an ES6 classes (or object in general) stops mithril from functioning the way you describe.

Meanwhile, this consistently refers to the controller instance within the controller itself, meaning that any attempted access to this or super would be inconsistent.

Without using this, how do you store state? And using closures isn't really an option since they're not as performant as using objects.

Edit:* changing this is also an implementation detail of mithril that should not leak through to user-land code. If I pass in a class constructor, it should work since it obeys the component signature: it looks like a duck, quacks like a duck, and walks like a duck, so why doesn't mithril treat it as a duck?

[barneycarroll]

@Naddiseo sorry, I just worked out what you're going on about. Bad reading on my part. The bug is that controllers don't inherit prototypes (classes are just a sugar expression that defines constructor + prototype in one).

Without using this, how do you store state?

Personally, I've never been a fan of this. The limitations, gotchas and convoluted code patterns surrounding scope application and prototypal inheritance have always been horrific. In many ways I'm disappointed ES6 gave us class because it makes things look simpler while preserving the flaky runtime. My controllers are factories. I use object literals and scope-agnostic functions wherever possible, and it makes like a lot easier (incidentally, everything is terser and you get private state):

function controller( x, y ){
  var privateX = x
  var privateY = y

  return {
    publicZ : function(){
      return privateX + privateY
    }
  }
}

And using closures isn't really an option since they're not as performant as using objects

I'd dread to think what kind of application you have that's facing measurable performance issues because of closures. You realise Mithril core doesn't use prototypes at all and the internal functions execute 1000s of times in any given view?

But I digress. For better or worse, this is expected to work with controllers. Prototypes are a core part of JS. We should fix this.

[barneycarroll]

Thought this would do it, but tests are breaking. :/

[barneycarroll]

@Naddiseo hey, I think this might be a false alarm caused by typos in the original fiddle (the controller's controller prototype method is never invoked) – could you check this out and see if it works for you?

Code, for reference:

let component = {
  controller : class{
    constructor(){
      this.x = 1
    }
    increment(){
      this.x ++
    }
  }, 
  view       : ctrl =>
    m('h1', 
      "Hello ", 
      ctrl.x,
      m( 'br' ),
      m( 'button', {
        onclick : e => ctrl.increment()
      },
        'Increment!' 
      )
    )
}

m.mount( document.body, {
  view: ctrl =>
    m('div', 
      component, 
      " World" 
    )
} )

[ow--]

@barneycarroll But now you've changed the premise by not using m.component() for the parameterization. The assessment that prototypes are a core part and this should be fixed ought still to stand. This also breaks using a TypeScript class as a controller.

Anyway, if you leave args as a parameter to parameterize() rather than slicing arguments in your changeset the tests go through and it works as expected.

[StephanHoyer]

plz, plz make the use of classes optional. I don't want to be forced to use them. I find them cumbersome and ugly. The code is IMHO much easier to read without them.

[barneycarroll]

plz, plz make the use of classes optional

+100

The argument for seems to be "I can't experience terrible flaws in the language because the library doesn't give me the opportunity". It's not a credible user story if you ask me.

[diogob]

+1 to @barneycarroll and @StephanHoyer.
this is a terrible feature, we're better of with lexical scoping. Simpler and more readable.

I would say that adding support for classes even as an optional feature is adding unnecessary cruft to the codebase.

But I'm also interested in hearing more from @Naddiseo and @tobscure why they want Components as classes.