Mithril.js: Unexpected behaviour when we use state variable as a object

[dhinesh03]

If component has primitive data type state variables then i'm not facing any issues, but for object type it retains for all of its instances.

Steps to reproduce the issue

• Goto the [fiddle] (https://goo.gl/2Y5dRL)
• Click "increase counters" button
• Now "increase count" button

[pygy]

The state of each component inherits prototypally from the component object. vnode.state.viewState always points to the same object.

You probably want to define it in oninit, rather than on the component.

var Counter = {
    increment() {
        this.viewState.count++;
    },
    oninit:function() {
        this.viewState = {
            count: 0
        }
    },
    view: function(vnode) {
        return m("div",
            m("p", "Count: " + vnode.state.viewState.count ),

            m("button", {
                onclick: this.increment.bind(this)
            }, "Increase count")
        )
    }
};

[barneycarroll]

The documentation needs clarifying on this point. I think @tivac mentioned this before, but the pertinent documentation is misleading:

Any property attached to the component object is copied for every instance of the component.

@dhinesh03's expectations are reasonable given the paragraph above. There is no 'copying' going on in any commonly accepted sense of the word.

Dhinesh, in your scenario I would advise putting any properties you would think of putting on viewState on the component state directly: components are units of view logic, therefore all component state is view state.

[dhinesh03]

@barneycarroll You are right , the document misleads. But, it would be better copying the property for every instance of the component. Hope everyone assumption is " the component" should act as blueprint and m(component) will create a new instance for the blueprint.

[isiahmeadows]

Technically, the instance inherits prototypically from the component
(through Object.create), for speed and memory reasons. It's way faster to
do that than a deep cloning, and you only have one copy of the component in
memory, not N+1 for N instances. Far less wasteful. Also, it opens the door
for the class-based and closure-based components, where internally, it can
just dispatch based on vnode.state.view and friends.

Also, an old alpha version of 1.x previously did this very thing, deep
cloning, but it was pulled after I brought this issue up. It was found to
be itself the main bottleneck in component creation, so it was first made
shallow, then moved to using prototypical inheritance via Object.create.

The documentation needs fixed, but that's it. Just thought I'd clear this
up.

On Mon, Feb 27, 2017, 01:36 Dhinesh Kumar [e-mail] wrote:

@barneycarroll https://github.com/barneycarroll You are right , the
document misleads. But, it would be better copying the property for every
instance of the component. Hope everyone assumption is " the component"
should act as blueprint and m(component) will create a new instance for the
blueprint.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lhorie/mithril.js/issues/1664#issuecomment-282639794,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AERrBCFku3y4hjoxnHS0y1uYD9c5DVAvks5rgm7lgaJpZM4MMZUv
.