-
Notifications
You must be signed in to change notification settings - Fork 303
Building better components
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.
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.
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.
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.