Use the event delegation approach for adding DOM event listeners for better performance and improved usability about marko-widgets HOT 12 CLOSED

You can also find related discussion on the Gitter chat room for marko-widgets: https://gitter.im/raptorjs/marko-widgets

from marko-widgets.

👍 in general. Syntax-wise, I like how Backbone does this: http://backbonejs.org/#View-extend

1. Much shorter "events" key (not that important)
2. css-style selector syntax is intuitive and more flexible than proposed format

from marko-widgets.

Thanks for the feedback, @devth .

Much shorter "events" key (not that important)

Good point. All widget instances are EventEmitter instances that support custom events and to avoid confusion between "DOM events" and "custom events" we were leaning towards "domListeners" (or "domEvents"?)

css-style selector syntax is intuitive and more flexible than proposed format

We definitely considered the Backbone syntax in earlier discussions, but in general, we want to avoid using CSS selectors for performance reasons and instead we want to assign unique IDs to widget elements. With that said, I suppose we could leave the door open using a format similar to the following:

{
    '#button1:click': function(event) {
        // click listener on a nested widget element
    },
    '.my-button:click': function(event) {
        // click listener on a nested widget element
    }
}

With that said, supporting CSS selectors for delegate events would complicate the implementation so I am not sure we want to support that out-of-the-box or give the appearance that it might be supported. Worth discussing some more.

Thanks again!

from marko-widgets.

Understandable regarding not supporting full-blown css selectors, but I do think even using #button1:click is more intuitive as the # indicates ID: the docs just need to be clear that is not full css selector support.

I like domEvents.

from marko-widgets.

👍 for domEvents and using Backbone syntax. Great feedback! Supporting CSS selectors should also be relatively easy (even if it doesn't perform as well)

from marko-widgets.

After giving it some more thought I agree. Updated proposal:

function Widget() {
    // ...
}

Widget.prototype = {
    doSomething: function() {

    },

    // *** DOM event listeners: ***
    domEvents: {
        'click': function(event) {
            // click listener on the root element
            this.doSomething();
        },

        'click #button1': function(event) {
            // click listener on a nested widget element
        },

        'click .foo': function(event) {
            // Delegate event with a CSS selector. Equivalent to $(this.el).on('click', '.foo', handler)
        },

        'resize window': function(event) {

        }
    }
}

from marko-widgets.

How do you want to handle #someId that might appear in the CSS selector? This is kind of an edge case but you cannot pass the selector as-is to JQuery because #someId gets prefixed with the widget element ID. I think you might need to optimize for most common case (e.g. click #someId) but also handle edge cases like click #someId input.some-class. You might also encounter something like click input.some-class #someId. I don't if we should be less flexible and document this limitation or simply try to handle the edge cases as gracefully as possible.

I do worry a little about the extra overhead of parsing the property names so I would recommend caching a parsed version of the domEvents object in the object itself. That way, when setting up listeners for a widget, you could see if you've already parsed the domEvents object and avoid a lot of the string manipulation and testing to understand the property names. This is based on the assumption, that events won't be added to domEvents after it is first encountered (which I think is fine). If a lot of widgets are being instantiated this caching might prove useful. Considering the case where Marko widgets is used to render something like search results, there could be a lot of widget construction and parsing of domEvents object.

from marko-widgets.

Valid concerns, @philidem

+1 on caching the parsed domEvents.

We are already using a RegExp to parse query selectors and I think (but have not confirmed) that the overhead is minimal:
https://github.com/raptorjs/marko-widgets/blob/413c27a434049397eab488a3b23052e73d873a83/lib/Widget.js#L26

We should treat the following format as a special case and handle it similar to how it is being handled now: <event> #<target>

from marko-widgets.

Looks great to me.

Thumbs up.

from marko-widgets.

Random question thou, can the widget handle the behaviour from a another JS file.. which can be used in the Widget ? The benefit is writing the JS behaviours could be completely independant of the Widget and jQuery / vanilla JS or any pattern could be used

from marko-widgets.

I am not sure I fully understand, @RameshRM. Are you asking if a widget constructor can call out to third-party/external code to add behavior? If that is your question, then, yes, the marko-widgets module makes no restrictions on what your widget does. All marko-widgets does now is instantiate a new widget instance given the widget ID, the root DOM element and some arbitrary widget config data. As a widget developer you can do whatever you want inside a widget constructor (such as calling out to a jQuery plugin).

With this proposal, we are hoping to solve the problem of efficiently attaching DOM event listeners because that is something that marko-widgets can do more optimally and more easily than if it were done outside of marko-widgets. Ideally, all widgets would take advantage of this functionality (when it is available), but it is still optional value-add.

from marko-widgets.

Change in plans. After starting the implementation for this proposal we realized there was a simpler solution (both in implementation and usability) that avoids various caveats associated with this proposal.

The new plan is to go forward with the following proposal:
#11

I think you all will agree that the new proposal is an improvement over this proposal, but if there are any concerns or thoughts please let me know.

from marko-widgets.