Subcomponent Controller access to latest attributes

[gilbert]

Take the following code:

var ItemManager = {
  controller: function (attrs) {
    this.createItem = function() {
      attrs.items.push( new Item() )
    }
  },
  view: function (ctrl, attrs) {
    return m('.items', [
      m('button', { onclick: ctrl.createItem }, "Create Item"),
      attrs.items.map(...)
    ])
  }
}

I have too often come across the limitation of ItemManager's controller only having access to the first version of attrs. For example:

1. The parent of ItemManager passes in an array of items:
   a. m.component(ItemManager, { items: itemArray })
2. Everything works great. Creating an item in ItemManager adds to itemArray.
3. Later, the parent of ItemManager generates a new value for itemArray, and passes that value to the same ItemManager subcomponent
4. Things break. Due to the controller's closure to attrs, creating a new item will now add to the old itemArray. The new itemArray remains unaffected.

This is a hard issue to explain, and the workarounds are non-obvious. As it stands, trying to modify the attrs parameter in the controller constructor breaks the principle of least surprise.

I think Mithril should have some built-in way to allow the controller to have access to the latest attrs. I have some options in mind, but before I present them I want to make sure the problem is clear. Thoughts?

[tobyzerner]

I think this behaviour is OK. You are essentially making the items array a part of the component's state, and state should not change unless you explicitly tell it to.

My solution would be:

var ItemManager = {
  controller: function (attrs) {
    var ctrl = this;
    ctrl.items = attrs.items;
    ctrl.createItem = function() {
      ctrl.items.push( new Item() )
    }
  },
  view: function (ctrl, attrs) {
    ctrl.items = attrs.items; // explicitly update state each time new attrs are passed in

    return m('.items', [
      m('button', { onclick: ctrl.createItem }, "Create Item"),
      attrs.items.map(...)
    ])
  }
}

OR

var ItemManager = {
  controller: function (attrs) {
    // don't make the items array a part of the state; require that
    // it's passed through from the view
    this.createItem = function(items) {
      items.push( new Item() )
    }
  },
  view: function (ctrl, attrs) {
    return m('.items', [
      m('button', { onclick: ctrl.createItem.bind(ctrl, attrs.items) }, "Create Item"),
      attrs.items.map(...)
    ])
  }
}

[gilbert]

Yes, those are the workarounds I have had to do. I argue that they are non-obvious to someone new to Mithril, and the debugging path to these workarounds takes quite an effort.

[gilbert]

There is also the cognitive overhead of figuring out what you can and cannot do with attrs in a controller.

[tobyzerner]

I'm curious to see the alternatives you have in mind?

[barneycarroll]

A few ideas:

1. Maybe createItem should be defined elsewhere. Item itself is, so is the list of items. It could be argued that this is intrinsically a model method that has nothing to do with the initialisation of this component.
2. If we're happy to have the model extended by components, maybe this should be considered a 'new' component when it receives a new list of items. Assuming we want the controller to be bound to a particular data object, it should be probably be keyed (or otherwise managed) such that it is impossible for a new list of items to come into a previously instantiated ItemManager.
3. On the other hand, the function is so simple that it could quite happily fit in the view: onclick : function(){ items.push( new Item ) }
4. ...But then, none of this really justifies new functions created at different points in the application lifecycle. Couldn't createItem be one singular function that sits in the top level scope (ie outside the component structure itself) and accepts the array to be mutated as an argument?

[mrtracy]

There are several alternate implementations of the ItemManager example that work around this issue; however, there is still an issue to be addressed.

The issue stated differently: during a redraw, if Mithril sees a parameterized component in the same DOM position as the previous redraw, and it has the same base component, it is considered to be the same component and the cached controller is reused: even if the arguments are different. However, even though it is considered to be the same component, the new arguments are passed to the view function. Here is a JsFiddle which demonstrates the issue; the view keeps seeing the new value, but the controller is cached once and never updated.

This behavior is unusually subtle and a bit frustrating, and I think a lot of developers are going to encounter this peculiarity; I certainly ran into it very quickly.

In order to suggest a solution, I investigated the origin of this behavior. In actuality, every invocation of m.component() returns a unique object; however, Mithril uses some internal information to match up parameterized components with the same base, in order to provide the syntactic convenience of calling m.component() directly in the view function while still re-using controllers (rather than keeping persistent references in the parent controller). An illustration:

// Without the convenience, components must be created in parent controller.
var ComponentsInController = {
  controller: function(){
    return {
      subComponent: m.component('myComponent', 'args');
    }
  }

  view: function(ctrl){
    return m("", [
      ctrl.subComponent;
    ]);
  }
}

// With the syntax convenience, components can be created in the view and the controller is still cached.
var ComponentsInView = {
  view: function(ctrl){
    return m("", [
      m.component('myComponent', 'args')
    ]);
  }
}

While that syntax is admittedly useful in cutting controller boilerplate, the logic used to determine that two components are the same is too fuzzy; if the arguments to a component change, it should be considered a different component.

In fact, the "correct" behavior is already available in one case: if the key field is passed as an argument to the component. Here is another fiddle illustrating the behavior with keys; notice how the controller is now re-created with each redraw, because the component has a different key each time.

So what is the solution? I think there are three options:

1. Improve the detection algorithm to consider the m.component to be different if the arguments change, even without the key attribute present.
2. Always consider the m.component() to be different, unless it has a matching key attribute.
3. Do not pass the arguments to the controller; only pass them to the view. This will immediately make the current subtlety of m.component() clear.

I think that any other behavior is going to be difficult to reason about, and only prove frustrating as more developers try to pick up the framework.

[barneycarroll]

@mrtracy I respectfully but strongly disagree with the notion that component controllers don't reinitialize enough. These should be used for initialisation. It is expected and extremely useful behaviour to be able to cheaply pass new data through to the view without having to reinitialize the controller.

I have my disagreements with the use of key (it forces a persistent DOM structure, which isn't always desirable), but I think users need to be specific about when they want a controller to reinitialize.

I'd be happy to offer tailored suggestions for any case in which controller reinitialization is deemed to be expected, but AFAIC this is a definite case of user error.

[mrtracy]

I've just read through some of your discussions with lhorie about key; your example of occlusion culling is compelling. That is a situation where components would receive different arguments on redraw, but have a compelling reason to re-use both the controllers and the underlying DOM structure to display different data.

In light of that, I think there is an education problem. In the API documentation for m.component, the majority of the parameterized component examples consume the passed arguments in controller(), and then use the controller to access arguments in view(); this leads users to think of it as the normal pattern, even for the simplest of arguments. However, this is clearly not the correct way to structure parameterized components in general; if a user follows the examples and passes simple display strings to components, they will quickly run into the subtle behavior of parameterized controller caching as their app becomes non-trivial.

I think in the basic API examples, users should be primarily encouraged to consume the arguments directly in the view() function.

I also think that a non-trivial example should be created of a scenario with the following requirements:

1. A parameterized component that will have different arguments on subsequent redraws.
2. The component's controller is stateful.
3. The controller needs arguments passed to controller() in order to initialize correctly.
4. The component does not need a key argument.

It seems like such a component would have some arguments that change, but other arguments that are static (needed for the expensive initialization). If the arguments needed for the initialization will change, it seems you would need a key argument.

[gilbert]

I think part of the problem is my internal ideals of controller responsibilities. One of those responsibilities is providing actions (methods to call) for the view.

In a parent controller, I want to be able to give ItemManager an array of items and have it do whatever it wants with it. As @barneycarroll suggested, this is possible with a plain function. However, React and Mithril have gotten me thinking in components; to me, Mithril's component features are not just a useful tool for managing the render cycle, but also for code organization.

At the moment, according to my (possible incorrect) ideas of what a controller should do, it's unfortunate that I have to treat the controller differently based on whether I'm working with a top-level component or a child component. Plain functions are useful, sure, but if I want a well-defined, independent section of the page, I prefer not need to choose between a Mithril component or a JS function.

The crux of the issue is hard to put into words. I'm still kind of figuring out how to express it.

[gilbert]

Another point: I had thought I found a simple go-to pattern: Start by putting actions and state in the controller, and refactor out as necessary. It seems that I would have to follow @barneycarroll's suggestion no. 3, or start with an already-factored out state and actions.

For the record, a key wouldn't make sense in this situation.

[lhorie]

To borrow some concepts from other languages, passing attrs into the controller and then modifying it from a closure qualifies attrs as a out parameter (i.e. attrs is passed in as an input, but it is explicitly expected that attrs may be mutated by the subroutine). I reckon that if that was made obvious by the language, it'd also be more obvious that setting itemArray to something else causes you to lose the reference to the out value.

So, to add to the options @tobscure presented, you could also wrap the argument in a m.prop, so that you're able to replace the array inside of the getter-setter function while maintaining a "pointer" to it (similar to how C pointers work)

[gilbert]

@lhorie Actually I have used that technique before. I ran into an issue at that point, too:

1. Parent creates Order view-model order (object filled with with m.props)
2. Parent passes down order.items to ItemManager (m.prop with an array as value)
3. ItemManager does its thing
4. User saves form
5. Parent submits Order data to server via ajax
6. Parent receives back final state of Order from server
7. Parent creates a new view-model with new data from server
8. Things break (ItemManager has stale reference to old order.items)

It took me a long time to debug this issue as well. The proper solution to this problem is to never recreate the view-model, and instead iterate through the original and set all the properties from the server. This requires me to write more code, and disallows me to reuse Item.create.

[cornelius-dol]

I too have been tripped up by this, and my conclusion is that the abstraction is currently broken. I suspect that the arguments should be considered arguments to the view only, and not passed to the controller, but I cannot yet be certain of this. What I am certain of is that the current formulation is badly broken and that the solutions/work-arounds presented in this thread are merely band-aids. That people are suggesting "work-arounds" to Mithril's current behavior is proof that it's broken.

[tropperstyle]

Though this did initially catch me by surprise, I found it does force me to reconsider how I am modeling my data, and so far it has always led to a better separation of concerns. As far as removing args from the controller function, I currently use the following pattern all the time. Basically it allows the nested components to retain the UI state edited values. The edit widget values are restored to the underlying model data every time the controller runs. Using a key with an id + updated timestamp usually will do the trick.

var EditItemWidget = {
    controller(args) {
        this.title = m.prop(args.title);
        this.description = m.prop(args.description);
    },

    view(c, args) {
        return m('.edit-input-widget', [
            m('form', [
                m('input', { type: "text", value: c.title(), onchange: m.withAttr('value', c.title) }),
                m('textarea', { value: c.description(), onchange: m.withAttr('value', c.description) }),
                m('button', { onclick: e => args.onchange(c.value()) }, 'Save')
            ])
        ]);
    }
};

var Application = {
    controller() {
        this.items = m.request('/path/to/items');
    }
    view(c) {
        return m('div.items', [
            c.items().map(function(item) {
                var key = [item.id, item.updated_on].join();
                return m.component(EditItemWidget, Object.assign({ key }, item)
            })
        ]);
    }
}

[cornelius-dol]

@tropperstyle : The problem with this pattern is it breaks encapsulation with respect to the container and component in that the container now needs very specific knowledge of the component implementation in order to know that it needs such as key as is being provided. In principle, the container should not require such specific knowledge. It's brittle and fragile and does not lend itself well to fully encapsulated black-box components which I safely "just use".