Requiring .startup()/.destroy hurts interop

[RoystonS]

One of the problems I (and other developers) have had with Dijit in the past is the requirement of calling .startup() on programmatically-invoked widgets, and often having to manage the manual chaining of such invocations. (.destroy/.destroyRecursive is equally painful, if not more so, usually.)

I recently had to write some code to plug onto the side of our application to check that all our widgets in our DOM had correctly had .startup called on them, and that dead widgets had been .destroy()ed correctly, as this is so tricky to get right. I found quite a number of widgets which hadn't got this right (mostly by third party groups tbh).

So I'm a little surprised to see delite propagating a manual .startup/.destroy system. (See issue #222 for instance.)

Working with .startup() is extra tricky when mixing widgets with other frameworks, which won't pass on such chained calls or participate in this custom widget lifecycle. Frameworks such as Angular et al, which provide excellent array-based data-binding and repeater controls can happily create and remove widgets, but don't know to call .startup/.destroy, and so interop becomes quite hard.

The Web Components spec - whilst incomplete, obviously - is heading towards a mechanism which works a little differently from .startup/.destroy, namely one that informs the widget of attaches/detaches (without the widget having to chain that information manually). Polymer is implementing these callbacks There's nothing manual involved, although admittedly being told that you're detached from the DOM tree doesn't necessarily mean you're never coming back.

Are there any plans to obviate the need for manual calls to .startup/.destroy? With their presence, I can't quite see how delite widgets will interop well with other Web Component frameworks, especially where delite widgets are constructed by any other framework that doesn't know to call .startup?

[wkeese]

Hi Royston.

It's a valid argument.

In order for attachedCallback() and detachedCallback() to be called automatically, delite would need to set up a https://developer.mozilla.org/en/docs/Web/API/MutationObserver or https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Mutation_events on the document root, and this is scary performance-wise, in particular for (IIRC) Android < 4.4 which only supports the latter.

As we've written in the documentation, one of delite's goals is high performance across all supported platforms, even on pages with thousands of DOM nodes (because of big tables, graphs, etc.) So that's why we didn't implement those listeners.

Some other notes:

• About startup() vs. attachedCallback(), note that startup() is different because it isn't supposed to be called until all other widgets on the page are created. Think of the selectedChildId property of ViewStack for example... it's hard to process that if the specified child doesn't yet exist (see ViewStack regression: selectedChildId initial value is not taken into account deliteful#245)
• As for destroy(), to be honest I'm not sure if we need it anymore. It was mainly used in dijit to avoid memory leaks on old IE. Now it's probably only needed in exceptional cases, to do things like closing database connections.

About Angular, there is https://github.com/tkrugg/angular-delite but I haven't looked into it myself.

[asudoh]

Wrt destroy(), I guess template code would want to stop observing objects at certain point. IIRC Polymer maintains a flag whether a custom element should be cleaned up at part of detach callback, and if so, does similar thing to destroy(). (I wish there was a lifecycle callback involved when a custom element is collected, but I guess if often ends up with chicken vs. egg thing)

[wkeese]

I guess template code would want to stop observing objects at certain point.

I don't think there's a problem if the template code is just observing its own widget's properties, like what happens with delite/template... everything should end up getting garbage collected once the widget is removed from the DOM. I guess you are talking about MVC where the widget is observing some third-party object.

[asudoh]

I don't think there's a problem if the template code is just observing its own widget's properties

Just wondered, did delite template support {{path.to.another.object}}?

[wkeese]

I suppose it does indirectly if this.path points to an external object. I just wasn't expecting people to do that.

[wkeese]

Here's what will do for this, to mitigate the problem:

• Move as much code from startup() to attachedCallback() as possible (see widgets should leverage attachedCallback() and not startup() deliteful#261); hopefully that will eliminate the need for startup() completely but we'll see.
• If you are running on a modern browser or using Polymer, attachedCallback() will be executed automatically. If you are running on an old browser it still needs to be called manually. If there's enough demand perhaps we can add optional code to monitor for node insertion/deletion and call attachedCallback() automatically but it's scary making that the default for performance concerns on Android < 4.4.
• not sure about destroy()

PS:

• placeAt() has been updated to call attachedCallback(), but it should probably also call attachedCallback() for ancestor nodes