Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Element Events list #392

Open
hassanzohdy opened this issue Nov 24, 2018 · 2 comments
Open

Element Events list #392

hassanzohdy opened this issue Nov 24, 2018 · 2 comments

Comments

@hassanzohdy
Copy link
Contributor

hassanzohdy commented Nov 24, 2018

Hello,

I was wondering if there such a thing that i could pass an object that contains events list instead of passing it as an attribute

For example

let h1= elementOpen('h1', null, null, 'onmouseover', function () {
   // do something
}, 'onmouseleave', function () {
   // do something
});
elementClose('h1');

Instead of that, what about the following:

let h1= elementOpen('h1', null, null);
 bindEvents({
   onclick: function () {},
   onmouseover: function () {},
   onmouseleave: function () {},
});
elementClose('h1');

Or pass an array of callbacks for each/certain events

let h1= elementOpen('h1', null, null);
 bindEvents({
   onclick: [
   function () {},
   function () {},
],
   onmouseover: function () {},
   onmouseleave: function () {},
});
elementClose('h1');
@sparhami
Copy link
Contributor

sparhami commented Nov 27, 2018

I think there are a few options here, so I'm not sure it makes sense in the core library. The shape of the API might differ depending on how you want to handle EventListenerOptions or if you want to do event delegation. I think this is likely something for a higher level library to tackle. One thing to watch out for is making sure event listeners are correctly cleaned up. For example, if you had:

elementOpen('div');
  bindEvents({
    onclick: () => {...}
  });
elementClose('div');

and your next call is:

elementOpen('div');
elementClose('div');

You would want to make sure to remove the event listeners. For a higher level library, this probably is not too big of a deal since it likely does not use elementOpen directly and has another function call wrapping it instead.

Another option is something like:

import {attributes} from 'incremental-dom';

export const eventListeners = Symbol();

attributes[eventListeners] = function(el, unused, newValue  = {}) {
  const oldValue = el[eventListeners];
  // remove any missing listeners, add any new ones
  el[eventListeners] = newValue; 
};

which could then used as (directly or through a higher level API):

import {eventListeners} from '...';

elementOpen('div', null, null, eventListeners, {
  click: () => {},
  mousedown: {} => {},
});

@hassanzohdy
Copy link
Contributor Author

hassanzohdy commented Nov 27, 2018

Thanks @sparhami, that was quite useful actually.

I ended up with the following code to achieve what i was looking for:

import {attributes} from 'incremental-dom';

export const eventListeners = Symbol();
attributes[eventListeners] = function (el, attribute, events) {
    for (let event in events) {
        let eventCallback = events[event];
        el[event] = function () {
            if (Array.isArray(eventCallback)) {
                for (let callback of eventCallback) {
                    callback.apply(this);
                }
            } else {
                eventCallback.apply(this);
            }      
        };
    }
};

Now from anywhere else it could be as any of the following:

import {eventListeners} from '...';

elementVoid('input', null, null, eventListeners, {
    onchange: function () {
        console.log(this.value);
    },
});

Or passing an array of callbacks for each event

import {eventListeners} from '...';

elementVoid('input', null, null, eventListeners, {
    onchange: [function () {
        console.log(this.value);
    }, function () {
        // do something else
    }],
});

But i want to ask why wouldn't that be in the core library?
I mean it will make it much easier for developer to handle events much easier.

I think same applies to boolean attributes which also could be easily done throughout the same concept of handling events, what do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants