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

Small DOM abstraction library #10

Open
akoenig opened this issue Aug 10, 2015 · 1 comment
Open

Small DOM abstraction library #10

akoenig opened this issue Aug 10, 2015 · 1 comment

Comments

@akoenig
Copy link

akoenig commented Aug 10, 2015

We should provide a small, lean DOM abstraction library which avoids dealing with some quirks like NodeList to Array conversion, event handler registration/deregistration and so on.

Traversing

import domy from 'domy';

let elements = domy.query('.foo');

Event handling

import domy from 'domy';

let click = domy.register('click', el, handler);

domy.release(click);

Thoughts @grebaldi @Inkdpixels?

@grebaldi
Copy link
Member

I definitely see this, but I'm not too sure, if we should really provide literal dom abstraction and if we should put it in an extra repository...

A few days ago, I had the idea to introduce a convention for that, which could be made part of the component API. Just a couple of reserved data-* attributes, like data-action="delete", which then would be available in component like:

class MyAwesomeComponent extends Component {
    constructor(el) {
        super(el);
        this.action('delete', 'click').bind(this.deleteAction);
    }

    deleteAction() {
        // delete something
    }
}

Or more awesome like:

class MyAwesomeComponent extends Component {
    constructor(el) {
        super(el);
    }

    @Action('delete', 'click')
    deleteAction() {
        // delete something
    }
}

We could reserve attributes data-action, data-input, data-result (without this being complete) and work with these... But I don't know if this would be too restricted.

So, a DOM abstraction might be the better solution. But it would also be a huge target for the old "reinventing the wheel" discussion. That's the reason why I'd like to go the extra step and remove some glue code, that the user would need to write anyway even with DOM abstraction and instead provide him/her with stable convention - All of which remains optional, because there still is direct access to the dom element.

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