ComponentJS TodoMVC Example
Running the ComponentJS TodoMVC Example
Either run it directly from Github:
Or perform the following steps to run it locally:
- Install Node into your system
- Install build-time dependencies via NPM:
- Install run-time dependencies via Grunt and Bower:
- Run development environment via Grunt and Connect:
- Test-drive the ComponentJS TodoMVC Example: http://localhost:8080/
This ComponentJS TodoMVC Example uses the following libraries and frameworks (which are all installed through Bower):
- ComponentJS 1.0.1
The MVC framework.
- jQuery 2.0.3
The DOM manipulation and eventing library.
- jQuery-Markup 1.0.25
The view mask template integration library.
- Nunjucks 1.0.0
The view mask template engine library.
- Flatiron Director 1.2.0
The URL routing library.
- UUID.js 0.7.5
The UUID generation library.
- Lo-Dash 2.3.0
The collection utility library.
- todomvc-common 0.1.9
The background image and TodoMVC.com integration code.
Hints about the ComponentJS TodoMVC Example
This ComponentJS TodoMVC Example tries to closely follow the official TodoMVC App Specification as long as there are no conflicting ComponentJS best practices. The known resolved conflicts were:
Component Reusability and CSS Usage
base.csswhich was not directly used within this ComponentJS TodoMVC Example. There are two reasons for this:
Single vs. Multiple Files
base.cssprovides all styles of the TodoMVC application in one single file, while in ComponentJS-based applications the styles are local to the components which create the corresponding DOM elements. In ComponentJS TodoMVC Example we have three such components (
todo) and hence the
base.csswas split into three parts accordingly, too.
Unique Ids vs. Class Selectors
The styling in
base.cssis mainly based on unique identifiers (
#foo) instead of classes (
.foo). This is a big "no-go" for UI approaches like ComponentJS where UI widgets (here the
todoUI component) are fully reusable and are potentially rendered multiple times into the same DOM tree. For the particular TodoMVC use case this does not happen, but the ComponentJS TodoMVC Example should have been strictly the way things are done in ComponentJS applications. As a result, all CSS selectors of
base.csswere converted from unique identifiers to BEM-like classes.
Source File Grouping
The TodoMVC application speciification just requires that an URL based routing exists. In order to avoid extra code, one could have implemented this by using FlatIron Director directly within the
todocomponent and especially just use direct hyperlinks in the view mask. While sufficient and perhaps acceptable for a trivial use case like the TodoMVC, it is not for a larger application. There the URL routing should be done only by a component which has the whole UI as the scope (the
maincomponents but not the
todowidget) and there should be no direct hyperlinks within a single component (as it is not allowd to control the URL of the whole apllication). We use Flatiron Director in the
maincomponent and perform a two-way binding into the
The TodoMVC application speciification just requires that the todo list is persistend in the the HTML5
localStorage. In order to avoid extra code, one could have implemented this by allowing ComponentJS to implicitly persist the Todo list items into
localStoragefrom within the
todowidget with the help of the
component.plugin.localstorage.jsplugin. While sufficient and perhaps acceptable for a trivial use case like the TodoMVC, it is not for a larger application. There the Todo items would come from an underlying service tier and its UI-independent Business Model (while the UI widget uses a so-called Presentation Model). We decided to already use this strict separation between Presentation and Business model for the trivial TodoMVC use case, even if it increases the total amount of required code, of course.
The ComponentJS website is a great resource for getting started. Here are some links you may find helpful:
For more details about the TodoMVC initiative and the idea behind the TodoMVC applications see: