4 ms·

Wow, Pace just blew my mind. You guys are releasing some really awesome stuff :) random other thing is would be sweet if these were component[1] friendly. (Dunn

Wow, Pace just blew my mind. You guys are releasing some really awesome stuff :) random other thing is would be sweet if these were component[1] friendly. (Dunno if you've already checked out component, but it is insanely good for front-end work.) One pattern I picked up from reading TJ's code is the transparent constructor... odometer(el).value(42); ...which I like using to make things that share a bit of state, but are still one-offs, a bit terser. (Coupled with avoiding options objects in general.) Achieved with the following: function Odometer (el) { if (!(this instanceof Odometer)) return new Odometer(el); ... } [1] https://github.com/component/component https://github.com/component/component

zackbloom 13y ago
We try to include component.json files, but we don't use component, so it's usually left to a benevolent pull-requester. We've been using bower more and more, and liking that a lot, but it's essentially arbitrary. It's a bit annoying that npm, bower and component all require their own files to say essentially the same thing. I agree with wrapping the constructor function. Requiring the consumer to remember new adds one more tripping point for users. In this case, I suppose my thought was that the manual-creation path was such a small percentage of users that it wasn't a huge deal.