3 ms·
When we started using Backbone it was good for awhile until there was so much code duplication all over the place. We decided to build a small declarative API o
by jb55 14y ago
When we started using Backbone it was good for awhile until there was so much code duplication all over the place. We decided to build a small declarative API on top of backbone that allows us to easily compose views by mixing in common functionality. It looks something like this:
AlbumsView =
bQuery.view()
.set("el", "#albums-view")
.init((opts={})->
@readOnly = opts.readOnly or no
@app = opts.app
)
.use(Mixins.bq.init('albums'))
.use(Mixins.bq.collection
tag: "#album-list"
createView: (m) ->
AlbumView = Views.AlbumView(readOnly: @readOnly)
new AlbumView { model: m, app: @app }
)
.use(Mixins.bq.filterable
pred: (album, ftext) -> album.get('title').indexOf(ftext) is 0
filterTag: "#filter"
collectionTag: "#album-list"
)
.on("click #addNew", ->
@collection.create
title: "New Album"
type: "Album"
)
.make()
For example, the Mixins.bq.collection plugin abstracts away the common task of adding and removing subviews when new things are added the collection. The filterable plugin abstracts away the common task of filtering collections. Our custom init plugin sets up all the events common to all of our views. In the end make() just returns a BackboneView with all the events set up properly. It has saved us so much time we figure people may actually want to use this as well, we just have to write the documentation and some plugins now :)
https://github.com/jb55/bquery https://github.com/jb55/bquery
- jarek-foksa 14y agoWhat's the point of this excessive chaining? I use CoffeeScript a lot, but your code looks unreadable to me.
- jb55 14y agoChained method calls is analogous to function composition from bQueryView to bQueryView. You could write it this way if you don't like the look of it syntactically: bqView = bQuery.view() bqView.set(...) bqView.on(...) MyBackboneView = bqView.make()
- eranation 14y agoI think code verbosity (which anyone can read and understand) is highly underestimated these days. I don't think writing less lines of code is any good if you need to explain to people what you did (yes, even smart people sometimes don't figure it out right away if they didn't use a similar library / concept before, and you don't always have smart people reading your code anyway, we all know that) If you optimize your code to avoid any duplication, you are probably wasting more time writing / extending libraries, doing pull requests than getting working software done. Refactoring, and good design is critical, helpful, almost mandatory, but if your feature is not out there on time because you over refactored / engineered your code, and some other startup get's it out there faster, no user will care. users don't do view source before they pay you.
- whalesalad 14y agoI'm so glad that this is the current top comment. Backbone apps are the most verbose and non-DRY apps in my experience. Tons of code duplication.
- delambo 14y agoIf you have code duplication/DRY problems, then Backbone is not your problem. You need to abstract common functionality and add mixins to Backbone.View.prototype. In every backbone project that I have developed, the set of View mixins that I create are very specific to each project and the custom UI/UX I build. It would be a useless exercise to abstract all of my View mixins into some kind of opinionated framework, because I know my next project is going to look and behave differently. That said, if you are working on a large project with some simple UIs/UXs and need some simple data binding, then you may want to check out an "ambitious" framework like ember.js. Backbone is a library that helps you organize large projects with a lot of complex and custom UI/UX.
- whalesalad 14y agoDo you have any examples of this? I'd love to see it.