One of Bitovi's earliest, and most important, development strategies was the introduction of the "modlet" workflow. It's a very simple concept - every module should be developed as its own application. In practice, this means that instead of a folder structure where files are grouped by type like:
project/ js/ moduleA.js moduleB.js templates/ moduleA.handlebars moduleB.handlebars css/ moduleA.css moduleB.less test/ moduleA_test.js moduleB_test.js docs/ moduleA.markdown moduleB.markdown
Bitovi groups files by the module they belong to:
project/ moduleA/ moduleA.js moduleA.handlebars moduleA.css moduleA_test.js moduleA.markdown moduleA.html test.html moduleB/ moduleB.js moduleB.handlebars moduleB.css moduleB_test.js moduleB.markdown moduleB.html test.html
Each module has a folder with all of its supporting files, tests, and documentation. Additionally, we add:
- A demo page (
moduleA.html) that shows off the modules functionality if the module has a visual representation.
- A test page (
test.html) that runs just the module's tests.
In my experience, this workflow / folder structure provides the following benefits:
- It enforces good API design and separation of concerns. By writing a demo page, you might discover that it's difficult to setup your module without a lot of bootstrapping. This might be an indication that something is wrong.
- Developers are more likely to update tests and documentation if they are sitting right next to the module they are editing. The test is not hidden away in some
testsfolder that is more easily ignored.
- It is easy to identify missing tests or documentation. If the test or documentation file is missing altogether, it's very easy to identify when they are in the same folder.
- You can develop the application without having to load the entire application and all of its tests on every change.
An Old Example
We're in the process of updating the Srchr app with the latest CanJS, StealJS, DocumentJS and creating another demo application that highlights the modlet technique.