I built http://plunker.no.de/edit using Backbone.js and really have enjoyed the process. The addition of the sync event has really helped me out.
That being said, I think the most important abstraction that I introduced in this project and not in others was inspired by moviepilot.com's Chaplin project: https://github.com/moviepilot/chaplin
The revelation was to have a central mediator pub/sub mechanism. I used that central mechanism to allow different parts of the ui to declare intents. Each intent has a target that can handle that intent and (if appropriate) emit a corresponding event. The idea is that there is a single handler of each 'intent' and can be many handlers of 'event's. This is because each UI component doesn't necessarily know of the final receiver of the intent events. Keeps things nicely decoupled (so far at least!).
The Sidebar contains a list of filenames in the current 'plunk'. When the user clicks on a filename, an 'intent:activate' event is fired. When the user double-clicks an 'intent:rename' event is fired. Only once those changes have been handled and refired as 'event:activate' or 'event:rename' are they reflected in the UI.
That's a good question. The Sidebar example should illustrate this pretty well.
Current scenario:
1. The user clicks the remove file button [-] at the bottom of the Sidebar.
2. The Sidebar fires an 'intent:fileRemove' event through the mediator.
3. The handler of this event can then determine which file should be deleted and can also prompt the user to confirm their intentions.
4. If the user confirms that they want to delete, then the model is changed and the 'event:fileRemove' event is fired off.
5. The UI then reacts to this event.
If the Sidebar instead fired of an 'event:fileRemove' directly this would lead to some issues:
* The Sidebar would need to take over the responsibility of prompting the user about file deletion.
* If I add a new UI entry-point to file removal, this user prompting behaviour needs to be duplicated.
TLDR; It buys me extra decoupling between user intentions (UI -> Model) and state changes (Model/Controller -> UI). It lets me add a Menu with a Remove item without needing to change my controller and model to accommodate it.
That being said, I think the most important abstraction that I introduced in this project and not in others was inspired by moviepilot.com's Chaplin project: https://github.com/moviepilot/chaplin
The revelation was to have a central mediator pub/sub mechanism. I used that central mechanism to allow different parts of the ui to declare intents. Each intent has a target that can handle that intent and (if appropriate) emit a corresponding event. The idea is that there is a single handler of each 'intent' and can be many handlers of 'event's. This is because each UI component doesn't necessarily know of the final receiver of the intent events. Keeps things nicely decoupled (so far at least!).
For example: https://github.com/ggoodman/stsh/blob/master/assets/js/views...
The Sidebar contains a list of filenames in the current 'plunk'. When the user clicks on a filename, an 'intent:activate' event is fired. When the user double-clicks an 'intent:rename' event is fired. Only once those changes have been handled and refired as 'event:activate' or 'event:rename' are they reflected in the UI.