3 ms·

We've been having fun building things lately with transparent APIs. e.g. You drop Pace[1] in a page, and it figures out how to create a progress bar from it.

We've been having fun building things lately with transparent APIs. e.g. You drop Pace[1] in a page, and it figures out how to create a progress bar from it. Odometer is nifty in this way because you can still just set the value with innerHTML or .html, and it will animate it, so the overhead of adding it becomes just adding the class to whatever elements you'd like. You can actually also manually instantiate one pretty much exactly as you described: new Odometer({el: el, value: 42}); [1] - http://github.hubspot.com/pace/docs/welcome/ http://github.hubspot.com/pace/docs/welcome/

ianstormtaylor 13y ago
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.

ianstormtaylor 13y ago

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.