![AMD
define([
‘some/folder/module1’,
‘some/folder/module2’
], function(mod1, mod2){
//do some stuff with modules 1 and 2
return {
get: function(){ … }
}
});](https://image.slidesharecdn.com/how-to-build-a-js-toolkit-160216112235/85/How-to-build-a-JavaScript-toolkit-11-320.jpg)
![Javadoc-style comments
/**
Determine if a value is an array.
@method isArray
@param val {*} The value to test.
@return {Boolean} Returns true or false.
@example
lang.isArray([]);
// => true
*/](https://image.slidesharecdn.com/how-to-build-a-js-toolkit-160216112235/85/How-to-build-a-JavaScript-toolkit-22-320.jpg)
How to build a JavaScript toolkit
- 1. How to build a JavaScript framework toolkit
- 2. About Me Mike Nelson Head of Rich User Interface Development at HeathWallace Creator of ArmatureJS - an in-house JavaScript Toolkit @accordionpeas
- 3. Library, framework or toolkit? typeof jQuery === ‘library’ typeof Angular === ‘framework’ typeof Dojo === ‘toolkit’
- 4. ArmatureJS A JS Toolkit 40,000+ lines of code Aims to provide everything you need to build a web app: • module loading • language utilities • UI components • lots more Only 3rd party code is a custom build of jQuery - and not for long
- 5. A brief history of ArmatureJS • Mostly widget-based JS requirements - jQuery plugins • Some SPA work - Backbone and Underscore • A client insisted we use Dojo for all their projects • Created an initial in-house framework - rewrite of jQuery plugins and some basic concepts borrowed from Dojo • Toolkit was added to and improved • Documentation site was produced • Toolkit named ArmatureJS
- 6. Why bother? There are LOTS of JavaScript frameworks out there - http://js- drinking.projects.frank.petril.li/ Isn’t re-inventing the wheel a bad thing? Doesn’t it cost the business money?
- 7. Because... Our clients won’t accept a lot of third party code We’ve gained a really deep understanding of JS It’s raised the level of competency within the team It saves money It’s fun
- 8. So, how do I do it? • Be modular • Be consistent • Borrow ideas • Write tests • Create documentation • Manage releases
- 9. Be modular
- 10. Be modular There are many module patterns and loaders available We use our own AMD implementation: • Many modular, terse files during development • One compiled and compressed file for production
- 11. AMD define([ ‘some/folder/module1’, ‘some/folder/module2’ ], function(mod1, mod2){ //do some stuff with modules 1 and 2 return { get: function(){ … } } });
- 12. Be consistent
- 13. Define your API characteristics Providing a useful and intuitive API is not easy. Some things to consider: • Chaining • Implicit iteration • Getters and Setters • Private properties / methods
- 14. Be consistent Reliability & consistency are key to winning over users Doesn’t mean you can’t change/update your API - can be handled with versioning
- 15. Borrow ideas
- 16. Borrow ideas It’s ok to borrow ideas from other libraries: • API characteristics • Names • Functionality But write the code yourself without looking at how they implemented it. Why? • Avoids any potential licensing issues • Great learning experience
- 17. Write tests
- 18. Define your supported platforms Browser / device support Other JS environments - e.g. Node.js Make it “just work” across platforms - abstract platform concerns away from your users
- 19. Unit tests Choose a unit testing framework and use it from the start Achieve as much coverage as you can Don’t commit a module without an accompanying test suite Ensure tests are run regularly - Run tests via a task runner e.g. Grunt / Gulp - Automatically run tests on CI server
- 21. Create a docs site Auto-generate as much content as possible Write tutorials Include plenty of examples
- 22. Javadoc-style comments /** Determine if a value is an array. @method isArray @param val {*} The value to test. @return {Boolean} Returns true or false. @example lang.isArray([]); // => true */
- 24. Manage releases
- 25. Releasing Choose a versioning system e.g. semver - major.minor.patch Use it to appropriately inform your users of what to expect in a given release For every release: Ensure all tests pass Make sure docs are up to date Inform users
- 26. Thank you