Simplify component constructor to function that returns either a view function or a vnode tree

[dead-claudia]

Mithril version:

Platform and OS:

Project:

Is this something you're interested in implementing yourself?

Description

Depends on #2688 and #2689 - you can see the first because of the two-argument view. It's easier to explain relative to this.

Replace these idioms:

const Comp = {
    view(vnode, old) {
        return tree
    }
}

function Comp(initial) {
    return {
        view(vnode, old) {
            return tree
        }
    }
}

With these:

function Comp(attrs, old) {
    return tree
}

function Comp(initial) {
    return (attrs, old) => {
        return tree
    }
}

As the rest of vnode.* properties are subsumed with other vnodes, I'd just provide the attrs themselves instead of full vnodes. (Vnode children would be moved to attrs.children to align with virtually every other framework out there - I don't see the benefit in us remaining special here.)

Why

1. It's simpler to write.
2. It's simpler to implement.
3. It's lower overhead to invoke.
4. Not much of a reason, but TS compatibility would be increased with this. If TS isn't, it'd be a much easier ask to get them to correct the incompatibility.

Possible Implementation

1. In createNode, change state initialization to just this:

var instance = (0, vnode.tag)(vnode.attrs)
if (typeof instance === "function") {
    vnode.state = instance
    vnode.instance = instance(vnode.attrs)
} else {
    vnode.state = vnode.tag
    vnode.instance = instance
}
// render vnode.instance as usual

2. In updateNode, invoke (0, vnode.state)(vnode.attrs, old.attrs) instead of vnode.state.view(vnode, old).

Open Questions

• Should we also kill onInit from m.access(...) in Separate lifecycle methods from attributes and components #2689? I say no, because that would make it so users could still have that functionality outside components.

[gilbert]

As the author of mithril-cc, naturally I'm excited about this 😄

Regarding initial in the closure component form, I'm concerned the age-old stale attrs problem will rear its ugly head again.

For comparison, react hooks don't have this problem since the component function gets invoked every redraw. Not that it's a better solution by any means, as hooks create many more subtle problems when it comes to closures, but the point is react users never have to think about the current state of their props.

With mithril-cc I solved this problem by providing initial as a update stream rather than a plain object. That may not be the right solution for this proposal since mithril prefers to be unopinionated. But with that in mind, a getter function would equally solve the problem in a less opinionated way.

[dead-claudia]

@gilbert Might not be a bad idea, but that does come with some performance cost (V8 doesn't inline closure accesses properly for one, and you'd have to memoize it for non-closure components), and it's also a bit awkward IMHO.

We can use documentation to warn people of this gotcha, though, and it only applies for stateful components.

[gilbert]

Ah right, since both versions are functions, mithril doesn't know what version your component constructor is until after it runs once, which poses a problem.

[dead-claudia]

And also I'm not a fan of presenting two different ways of getting attributes for two different component types. Sounds ripe for confusion IMHO.

[gilbert]

The stale attrs problem is more confusing IMO, as it's much harder to document (not to mention its inelegant workarounds). But it seems there's not much mithril can do here, other than assuming function components will always return closures, which... isn't terrible, but it is more opinionated. I'll probably have to just stick with using mithril-cc.

Speaking of opinionated, would this change mean mithril is dropping support for class components?

[dead-claudia]

The stale attrs problem is more confusing IMO, as it's much harder to document (not to mention its inelegant workarounds). But it seems there's not much mithril can do here, other than assuming function components will always return closures, which... isn't terrible, but it is more opinionated. I'll probably have to just stick with using mithril-cc.

The problem is really that there's no nice alternative that doesn't have major pitfalls.

Option 1: my proposal

// Oops, shadowed
function Foo(attrs) {
  return () => m("div", {class: attrs.class})
}

Option 2: use a function reference (your suggestion in Gitter)

// Works, but isn't very optimizable by engines
function Foo(attrs) {
  return () => m("div", {class: attrs().class})
}

Option 3: use an instance property (what React did)

// Variant 1: class
// Property updated by the renderer before each update
m.Component = function (attrs) { this.attrs = attrs }

// Oops: `this` isn't the class instance
class Foo extends m.Component {
  view() { return m("button", {onclick() { Model.incrementItem(this.attrs.id) }}) }
}

// Variant 2: `this`-driven
// Oops: `this` isn't the class instance
function Foo() {
  return () => m("button", {onclick() { Model.incrementItem(this.attrs.id) }})
}

Option 4: use an object reference

// Property updated by the renderer before each update
// Gets awkward in a hurry, but if we shorten it to `i.attrs.class`, it might be
// workable.
function Foo(context) {
  return () => m("div", {class: context.attrs.class})
}

Option 5: use hooks

// Either it ends up rigid on diffing or bloats the bundle significantly, and it's
// not concise at all in practice. It's also prone to leaving you with stale
// closures.
function Counter() {
  const [count, setCount] = slot(0)
  return [
    m(".display", count),
    m("button", {onclick() { setCount(count + 1) }}, count)
  ]
}

Option 6: use streams

// This is actually very involved to wire up correctly and involves a lot of edge
// cases, just FYI. I've looked into this model already, and we'd have to rewrite
// our renderer for it.
function Foo(attrs$) {
  return attrs$.map(attrs => m("div", {class: attrs.class}))
}

Here's my analysis of each:

1. Brought up already, but there's a risk of forgetting to shadow attributes, especially if you don't use the initialAttrs idiom.
2. As noted, engines struggle to optimize that pattern. Unless something's changed in the past year or so, V8 can't inline that (I've verified it myself), and engines have to inline the closure call before they can even optimize property access. Additionally, we'd have to not only keep a getter closure for components (and store it accordingly), but allocate either a single-property object or a setter closure just to update it later. And that is a lot of memory to waste for a component.
3. Anything with this is a non-starter for me. Unless you're using TypeScript, it's a recipe for disaster, and even TypeScript users have little to gain by using classes.
4. I like this one, particularly if you shorten the idiomatic parameter name as I suggested there (to like i.attrs). You could also add other properties (I've looked into this space already):
   • i.isInitial for reasons you can probably infer.
   • i.request (for m.request), and i.meta = {window, document, type: "dom" | "static"} (the first two can be retrieved from doc.defaultView and elem.ownerDocument respectively), to enable consumers to not rely on globals to do XHRs and the like (useful with JSDOM) and to allow them to tell apart different renderer types (making the framework considerably more portable).
   • i.state and i.link(init) (I'm not sold on this without it), where i.link = init => i.isInitial ? (i.state = init()) : i.state, for setting up mutable state, instead of using a closure. (You could use if (i.isInitial) i.state = {...}, but a dedicated method is cleaner IMHO and offers better flexibility.)
   • We could put the previous attributes in an optional second parameter, retaining that convenience without needing to pollute the state object with another property.
5. This is a non-starter for me. I've explored it already, and have used React Hooks extensively enough to know both where it excels (modular state requires less setup boilerplate) and where it doesn't (anything involving conditionals and mutable state that doesn't fit in its pretty architecture). And of course, it comes with other pitfalls as I've noted in the example.
6. This is once again a non-starter for me. I've tried figuring out how to wire view streams already, and while it make for concise components, it's an utter beast to set up properly, and it's riddled with edge cases. I could see a modified model being at least somewhat useful for statically compiled frameworks down the vein of Svelte, but if we're talking a fully managed pure runtime component, this belongs in userland.

Of all these, I'm leaning towards option 4. @gilbert @barneycarroll What do you think?

Speaking of opinionated, would this change mean mithril is dropping support for class components?

Yes.

[StephanHoyer]

I would (again) suggest another version, which I now use for quite a while with a small helper (withState).

function withState(getView) {
  const comp = {
    oninit: ({ state, attrs }) => (state.viewFn = getView(...attrs.args)),
    view: ({ state, attrs }) => state.viewFn(...attrs.args),
  }
  return (...args) => m(comp, { args })
}

Than, I only use "functional" components (aka view-functions), that return trees. If I need state I create a closure that returns a view function just like your second example. I pack this up with my helper to mark is a component. The result is again a view function. This way it's transparent for the consumer, if the component is just a function or a component. This way you can easy switch from one to the other without changing the call-site.

const compView = withState((...initialArgs) => (...args) => tree)

// usage
compView(...args) // returns tree

I think this would also go great in conjunction with m.access and alike.

[gilbert]

Another con of Option 2 is the dilemma between only providing the attrs getter, or providing a plain object attrs in the returned view function but risking a similar shadowing problem like Option 1.

Sleeping a bit on Option 4, I'm starting to like it. Aside from the benefits you list, i could also inherit from an extendable prototype, allowing users and libraries to extend component behavior in interesting ways.

On the other hand, @StephanHoyer's example makes me wonder, does mithril need to handle state at all? Could it only worry about component identity and handoff state approaches to the user? Perhaps with a few "canonical" helpers.

[orbitbot]

On the other hand, @StephanHoyer's example makes me wonder, does mithril need to handle state at all? Could it only worry about component identity and handoff state approaches to the user? Perhaps with a few "canonical" helpers.

@gilbert

I'm a bit unsure of how to parse this, could you elaborate?

[orbitbot]

// Property updated by the renderer before each update
// Gets awkward in a hurry, but if we shorten it to i.attrs.class, it might be
// workable.

Code examples can use destructuring syntax by now, and context has a common abbreviation in ctx which is better than one character shorthands.