Skip to content
This repository was archived by the owner on Mar 27, 2019. It is now read-only.

Building better components

visionmedia edited this page Oct 27, 2012 · 18 revisions

This page is dedicated to small tips and tricks for building better components.

Retina support

Any component that uses Canvas should utilize autoscale-canvas for retina support without the user doing this manually. However if the user is in charge of the canvas, and you are simply drawing to it, delegate this task to the user. An example of this is the canvas progress indicator component.

Modularity

When an aspect of a component may be useful to others, consider writing that as a component as well. If it requires reasonable effort to write the code in the first place, changes are someone else could use it too. For example both the popular "piecon" and "tinycon" favicon manipulation libraries have their own code for changing the favicon dynamically via canvas (and more specifically a data uri). I've re-written these libraries as piecon and noticon, both sharing favicon to perform the change.

Use only what's necessary

Using bloated libraries and frameworks for your application may be fine, that is completely up to you, if it improves your development process then by all means continue. This includes libraries such as "underscore", which is certainly not large, however forcing it upon someone who wants to use your component may be unnecessary unless you actually use a reasonable portion of underscore in that component. For example if you used underscore simply to produce a sum, then consider using (or writing) smaller components such as sum. In your application this may be incredibly redundant and frustrating to many several dozen dependencies, in which case, use underscore.

The point is that this fragmentation does not have to exist, we do not have to write "jquery plugins", "ember plugins" and so on, we can write "javascript components" that everyone can share. If you wish to use jquery in your application, that is completely acceptable, but if we build a strong foundation of cross-browser components our eco-system will flourish like never before, with drastically reduced duplicate effort.

Better abstractions

Components should have very specific goals in mind, and attempt to provide the most flexible solution they can, after which higher-level and potentially more user-friendly abstractions may be built upon. This helps form a solid foundation, as higher-level abstractions may prove leaky, you'll always have a lower-level component to fall back on.

Avoid large options objects

If you component truly only takes a few options, and are unlikely to change after the fact, then an options object may be suitable. I strongly suggest considering a fluent API, even if you provide an options object. This makes code considerably cleaner, as the fluent API can back each key in the options object, which otherwise would promote extremely large plugins. Remember build up to a user-friendly api, do not start there.

Clone this wiki locally