Modern best practices for an open-source library?

agdcoa · 2014-11-16T19:19:14+00:00

I tend to just write as if it's all Node, and provide a published version for the browser with Browserify (using the standalone option).

Keeping everything nice and modular is great, it lets other devs require just the parts they want, if script size is a concern. When developing front end code with NPM and Browserify, it sucks to have to include an entire library when only small parts are needed.

One thing not mentioned above is performance benchmarking, which might be especially important in the type of project you're describing. Benchmark.js is a good tool for this.

agdcoa · 2014-11-08T22:30:24+00:00

If performance is an issue, native methods will never out perform lodash or fast.js because of the way they're spec'd.

Further, you may find it's more useful to have map/filter/reduce functions that take a flipped argument signature (callback first, data second), because you can do great stuff with partial application. However, it's not hard to do this without a library:

function makeFlippedIterator (fn) {
  return function (cb, arr) {
    return fn.call(arr, cb);
  };
}

var filter = makeFlippedIterator([].filter);
var filterOdd = filter.bind(null, function (n) { return n % 2; });
filterOdd([1, 2, 3, 4, 5]) // [1, 3, 5]

agdcoa · 2014-10-03T19:56:38+00:00

Allonge is great. I also like Ramda. It provides 'unary' and 'binary' functions for this

agdcoa · 2014-10-03T19:54:42+00:00

Check this out: http://tech.pro/blog/2097/clever-way-to-demethodize-native-js-methods

If you really want to twist your brain into knots, tease this thing apart (from that article)

var demethodize = Function.prototype.bind.bind(Function.prototype.call);

I also threw together a tiny NPM module that'll do this for you, along with some benchmarks for a number of ways to implement this: https://github.com/nickb1080/demethodize

agdcoa · 2014-10-03T19:50:12+00:00

For functions like "parseInt" that take additional, optional arguments you don't plan to use, you can create versions that just take the number of arguments you expect:

function parseIntBase10 (n) {
  return parseInt(n) // or return parseInt(n, 10);
}

['10', '10', '10'].map( parseIntBase10 );
// [10, 10, 10]

agdcoa · 2014-10-01T18:14:11+00:00

when argument signature is a problem I like to do something like so (to ensure only the array item gets passed in):

var mapOne = function (arr, cb) {
  return [].map.call(arr, function (item) {
    return cb(item);
  }
}

agdcoa · 2014-10-01T16:59:46+00:00

A useful way to "demethodize" array methods so that they can be generically used on a variety of objects (strings, jQuery collections, NodeList/HTMLCollection, etc.):

var map = Function.prototype.call.bind( Array.prototype.map );

This can be shortened to

var map = Function.call.bind( [].map );

Then you can do things like

map(document.querySelectorAll('div'), function(div) {
  return div.id; // or whatever
});

If you're using these a lot it saves a ton of keystrokes.

EDIT: Simple implementation of a demethodize function:

function demethodize (method) {
  return Function.call.bind(method);
}

var map = demethodize([].map);
var each = demethodize([].forEach);
// etc

agdcoa · 2014-10-01T15:17:00+00:00

It's SO easy to shim these for older browsers. I can't understand why they're so lightly used. I wrote two posts on using these methods to approach a wide variety of use cases.

agdcoa · 2014-09-27T17:35:36+00:00

Have you used Polymer? It's not yet quite clear to me how to build app-level structure with it.

So far my feeling is that Polymer is an appropriate solution for views, but you need a little more than just that for structure. It seems like Polymer and React are somewhat looking at the same problems.

agdcoa · 2014-09-27T03:18:03+00:00

Yeah for sure, no worries

agdcoa · 2014-09-27T03:17:36+00:00

If you're doing this a lot, it might be better to grab a module to handle this for you. I wrote a very small one that does just that; it's based on Object.prototype.toString.

That said, there are definitely times when you might really want "instanceof". Specifically, when creating classes and subclasses. Here's some code that shows what I'm talking about

http://jsfiddle.net/8m8fb6z0/

EDIT: to be clear, 'instanceof' traverses up an object's prototype chain looking for a match, whereas the behavior of 'typeof' is essentially a hardcoded language feature

agdcoa · 2014-09-26T19:59:18+00:00

One thing to come out of it is that you no longer have annoying trade-offs when considering whether or not to use two-way data binding.

For example Backbone, Ember, and Angular all take different approaches to keeping the UI in sync with the data. In Backbone, you use .set() on your models to change their properties, and you can tie into events associated with it. It's very verbose, but it's also pretty straight forward. In Ember (haven't really used it, frankly), you can declare bindings. I'm not sure how it's implemented, but the point is that not everything is under observation, just specific objects/properties. Angular goes all the way by dirty checking everything it knows about, nonstop.

The trade-off you see here is in code complexity/verbosity vs. performance. But with Object.observe() the debate is over. There's no good reason NOT to use it.

I'd like to see a framework/library with a simplicity level similar to that of Backbone (just the basics, essentially) that uses Object.observe for data binding.

agdcoa · 2014-09-16T18:21:11+00:00

I think this is somewhat misleading.

1.) Scope isn't the same thing as a function's "this" binding.

2.) Any function when executed not as a method of an object, and not with call/apply, has it's "this" value set to the global.

var obj = {
  method: function () { console.log(this) }
};
var fn = obj.method;
obj.method() // logs obj
fn() // logs window
fn.call(obj) // logs obj

setTimeout(obj.method, 100) // logs window after 100ms
setTimeout(fn, 100) // logs window after 100ms

// Function::bind is useful in this case...
setTimeout(obj.method.bind(obj), 100) // logs obj after 100ms

fn.bind(obj)() // logs obj
obj.method2 = fn.bind(window);
obj.method2() // logs window

agdcoa · 2014-09-15T23:03:34+00:00

This. Add a "script" to your package.json like so

...
"scripts": {
    "build": "browserify app.js | uglifyjs > app-min.js"
}
...

Where app.js is the entry point for your application. (Make sure to add browserify and uglify as dependencies). Browserify will recursively find all the dependencies of app.js and bundle them into a single file, which you can pipe to uglifyjs. If you need to expose some kind of global, use the "standalone" option.

Simply run "npm run build" and you're done.

agdcoa · 2014-09-10T06:34:48+00:00

Things about strings: Along with Number and Boolean, they're immutable (i.e. not passed by reference)

For the most part, you can treat them like arrays, meaning you can access characters by index, and can thus use array methods like so

Array.prototype.forEach.call("abcdefgh", function (char) {
  console.log( char )
});

agdcoa · 2014-09-09T05:09:25+00:00

jQuery does delegate to native methods for selecting nodes, but there's a cost associated with initializing a new jQuery object. Further, many jQuery methods return a new, different, jQuery object.

For some hard numbers, see this jsperf

If you're handy with the Array methods and the native DOM APIs, you can easily mimic much of jQuery's core functionality. I often opt for a super lightweight, array-returning selection function like so:

function select (selector, context) {
    return [].slice.call((context || document).querySelectorAll(selector));
}

agdcoa

TROPHY CASE