Component.js Package

[techjacker]

Awesome project.

I've been struggling to get this to work with component though. I thought I'd fixed it when I edited src/component.js to from require('../dist/HTML.all.js') to require('../dist/HTML.js'). But then I started getting errors about HTML not being defined when the second IIFE tries to execute with HTML as an arg.

[nbubna]

Yeah, sorry. This was one of the things i wanted to test before publicizing the project, but someone else found it and spilled the beans before i was ready. I have the fix for this locally already, it just got intermixed with some other changes, so i haven't pushed it yet. I'll branch it and repeat though.

I'm not a big component user, so help me out here. Is component pulling it straight from github? or from NPM?

[nbubna]

Ok, i also fixed the path in component.js

I've got other things to work on today or i'd go test it myself. If you would, close this case if it's all working for you now.

[techjacker]

Thanks for fixing this so quickly, it's working fine now.

The only problem I'm still having is with the HTML.ify() method. I'm trying to use it to parse an html string before I've inserted it into the dom and then use .find etc methods to manipulate nodes within it. It's throwing this error: Cannot use 'in' operator to search for 'length' in <h1>heading 1..... I'm guessing this is just something .ify() wasn't designed to do but thought I'd check in case it was in any way related.

Btw component pulls straight from github and only the files listed in the component.json. That's how it's so fast.

[techjacker]

One other thing, I keep getting warnings about find() being deprecated and that I should use query() instead. I wasn't sure whether to heed the advice though as the docs always refer to find().

[nbubna]

I just updated the docs. see issue #7 for why the switch to query()

HTML.ify() is for nodes not strings. HTML.js doesn't currently accept actual html input. :) The idea is that you would use the native DOM for that: https://developer.mozilla.org/en-US/docs/Web/API/element.insertAdjacentHTML

I've toyed with having add() accept raw html (instead of just tag names and/or emmet abbreviations). But it's hard to see what that would provide except a shorthand version of nodes.each('insertAdjacentHTML', 'beforeend', myhtmlstring) with fewer position options. Considering that i'm trying to keep this library lightweight and encourage use of native DOM, i'm inclined to leave it out. If you want to save a few characters create an alias for each() to use:

HTML._.resolve.insert = 'insertAdjacentHTML';
nodes.each('insert', 'beforeend', myhtmlstring);

[nbubna]

I suppose it might prove more useful for ify() to accept html strings instead of add(). Then it can return disconnected and HTML'ified nodes from dynamically loaded markup. It would have to be pretty lightweight code though.

[techjacker]

Okay thanks for clarifying all that.

I think you're right to keep the library focused, there are other solutions for parsing strings into HTML like domify.

On that note, I was going to suggest that you add an extra section to the docs/wiki listing complimentary libraries. Stuff like adding CSS class names to elements is going to be needed by most people I expect so it might be useful to point them in the right direction. There's a bunch of candidates on the component wiki you might want to look at and probably lots more besides. It might also help you decide which areas to focus future development on.

Thanks again for creating this, I'm really enjoying using it.

[nbubna]

Yeah, a doc section on complimentary components is a great idea! Wanna submit a pull request? ;) Perhaps we can just start by opening an issue to discuss candidates. For manipulating class names, however, the native classList API is pretty sweet: https://developer.mozilla.org/en-US/docs/Web/API/element.classList

It has add, remove, toggle and contains functions that all work with nodes.each('classList.{functionhere}', '{classhere}');

And of course, you can use http://nbubna.github.io/HTML/#_.resolve aliases to shorten that.

[techjacker]

Those aliases are sweet.

I didn't know classList had all that functionality. That's the great thing about this library, it educates you about the real dom API instead of hiding it like jQuery does.

It would be cool to get ie9 support as well so still some scope for a polyfill class in the list of complimentary libraries I reckon.

I'll make a list of a few and will submit a new issue for it to get some other suggestions.

[nbubna]

Thanks @techjacker! Having even the start of a list of complimentary components (com-coms?) will help. And yeah, we should definitely include a section of polyfills that allow HTML to work better with IE9 (and maybe even an IE8 section?).

And yes, one of my main goals with this is to educate people about the DOM API. It's no longer the mess it was. While it can still be verbose or unwieldy in places, it only takes a little sugar like HTML.js and suddenly piping everything through jQuery's completely alternate API feels pretty unnecessary.