search

ded / bonzo

library agnostic, extensible DOM utility
Other
1.32k stars 137 forks source link

Is there any reason why the constructor function doesn't normalize its inputs? #102

Open aawwawa opened 11 years ago

aawwawa commented 11 years ago

If it did, it would save a hell of a lot of bonzo.create()s.

Anyway, it came up in IRC, and I was wondering if anyone else might be able to provide insight. If there's no good reason not to, then I'd like to propose that normalization get added...

Cheers!

ded commented 11 years ago

can you give an example? there's probably a very good reason — if not simply for the sake of speed, and that doing this via Ender would do it anyway.

rvagg commented 11 years ago

@ded I was discussing this with @adlwalrus and I couldn't come with a good reason that bonzo() isn't more clever and wondered if there was something I was overlooking.

bonzo(bonzo.create('<p>')).appendTo('#something') // unnecessarily awkward

The manip methods are clever enough to normalize() & query(), the constructor should probably be too, for Bonzo stand-alone. There's already a typeof elements == 'string' check in there but it doesn't do anything sensible.

That, and the fact that bonzo.create() doesn't return a Bonzo collection.

ded commented 11 years ago

hmmm.... i suppose so... we'd have to bump up the package a minor version tho

ded commented 11 years ago

and update a few tests...

aawwawa commented 11 years ago

Anyone wanna do it? If not, then anyone wanna coach me through doing it?

aawwawa commented 11 years ago

Well that was silly... how does this look? https://github.com/ded/bonzo/pull/103

(I had a look over the tests to see if there were any I could clearly identify as needing to be updated, but it appears not.)

(Also, I'm still not sure what @rvagg was talking about with query() after poking around in the sources. I assume it has to do with being able to pass a selector into the constructor, but I'm not sure.)