Refactors Backbone to support multiple design patterns and a more consistent code-base for any project.

[benqus]

Implements Backbone.Base class to provide a base class for being consistent with any project codebase,
Implements Backbone.State, REST-less super class for Backbone.Model,
Implements Backbone.BaseView to provide a base View class for any other pattern - super class for Backbone.View,
Refactors Backbone.Collection and backbone.Router to inherit from Backbone.Base super class

[jashkenas]

Why isn't the diff visible on this PR?

[benqus]

I have no clue... Maybe too many changes? Is that possible?

[jashkenas]

Mind attaching a diff as a gist, here?

[benqus]

Sure, let me grab some dinner. =)
I reckon it will be the indentation.

[benqus]

Diff gist: https://gist.github.com/benqus/6206388/revisions

[akre54]

Git doesn't like the whitespace difference. Try with ?w=1.

Unfortunately no line-commenting this way though.

[akre54]

Many of the ideas in this pull have been brought up in different forms in the past. BaseView / Base Class (#276, #1816, #2413), stateful attributes (#1442, #2526, #2557), and hasOwnProperty checks (#796, #1495, #1783) tend to be better handled in the implementing application than by the library and are simple to add or fix if needed. You might look into going the route of Marionette, Thorax, Chaplin, and Aurora (offering additional functionality on top of a base Backbone) with these changes.

[benqus]

Yes, I thought maybe I shouldn't do this but the end I was kinda "forced". Reasons for that:

1: I like Backbone as it is, provides the features I need in a simple way. =)

2: I needed a code-base which is consistent (company requirement) so I don't end up maintaining classes written in 2 types of coding-styles (Backbone and "native" JavaScript style)

3: I also found myself segregating the logic from the View into a Controller (sometimes the Model too) to separate business logic and View specific logic because I might want to notify other components about Model changes, View events/changes, or notify a service about something.

4: I don't always use the REST features on the Models, even if I very much like the way Backbone does that. Model emits events for changes so I need those features separate. I know that I should override the default methods with my persistence or async layer on my models but that doesn't feel natural.

I understand that Backbone is not meant to be a "class library for JavaScript" and "the way that you desire to structure the rest of your app is up to you". I want to keep Backbone but sometimes I also need to deviate from the original MV pattern.
So basically what I need is to keep Backbone because it provides the features I need to build an app, but I also often find myself in a situation where I needed Backbone to be a tiny bit more flexible so no matter what path I choose regarding my application's architecture.

[akre54]

Its pretty easy to "borrow" the bits you need from the library where you need them:

var MyClass = function(attrs, options) {
  ...
}
MyClass.extend = Backbone.Model.extend;

Check out the plugin I wrote for #2557 if, for example, you need stateful attributes in your collections or views. Or if you want a model devoid of RESTful features, you could create a base Model where sync is a no-op.

Backbone is about as non-magic / non-opinionated as frameworks come, and should play nicely with all of the rest of your code. How you structure your application and use its utilities are up to you.

[benqus]

With respect, that is exactly what I wanted to avoid. I cannot provide a code-base which starts like that for any client.

How about exposing the extend method properly?

[akre54]

It is exposed — as Model.extend, Collection.extend, etc. If you want to make it generic you can add the line Benqus.extend = Model.extend; in your project's utils file.

For better or worse, Backbone encourages extension of its core components for maximum usefulness. Fortunately, the API has been fairly static since the early versions, so your extensions and plugins should work version-to-version. Attempting to keep up with the library after modifying it directly, on the other hand, is a sure-fire path to frustration.

[braddunbar]

Hi @benqus, thanks for the patch!

It is exposed — as Model.extend, Collection.extend, etc. If you want to make it generic you can add the line Benqus.extend = Model.extend; in your project's utils file.

Yep yep, extend is exposed as provided above and won't be exposed alone because it exists only as a means to reach Backbone's stated goals, not to be a generic class library (check out the issues for more background here). You can use extend as @akre54 suggests or you can grab the 30ish lines for your own use.

[benqus]

I am sorry to read that. I won't be able to pass Backbone this way to the architecture.

MyClass.extend = Backbone.Model.extend is kept a very ugly way of resolving this issue, even among my fellow Backboners (lol)...

Seems we have to find our own ways of doing stuff. MIT license is cool for many things. =)

Anyway, worth a try.

Cheers guys!

[mateusmaso]

+1 @benqus that's something I really wish for and I found myself pretty lame after rolling out my own extension of backbone. There are behaviors already implemented but you can't easily reuse them without workarounds to avoid code duplication..

Granularity only comes for good. It's like say: "okay, if you want to roll out your own version just grab those modules and build your own 'backbone like' thing, instead we have some builtin solutions like Backbone.Model, Backbone.Collection and Backbone.View, good luck."

Well, I thought of forking to do my own thing but, in the mean time it only creates more issues and you will have to give up all the great backbone community behind to be responsible by maintaining it.. for that case I rather switch libraries than hack things out.

[benqus]

Thanks @mateusmaso

Having a second thought about "How structure your application and use its utilities are up to you" would be true, if Backbone would not depend on jQuery and underscore massively. Fine, you don't get basic templating (underscore), neat Model/Collection API (70% underscore), async stuff (jQuery), etc... But still. Being so much dependent means that backbone defines what utilities I want to use.
I might be wrong on this but having massive dependency on these libraries I see no reasons why Backbone should not be extended. It isn't even extension, it is more like "rebasing" already existing functionality without adding new features.

Creating a Model class, which overrides the sync method and does nothing is not a good idea...

I personally prefer MVC or MVP but in Backbone style. It makes more sense for me and I have my Model specific, View specific and business (holaaa) logic segregated which improves code transparency, shortens my classes resulting in better structured apps. Of course, this (just like everything else too) can be overdone.
However, I feel that the MV pattern backbone follows more-less defines and restricts the way how I should design and implement my features. I clearly don't want to end up with multiple patterns flying all around the place...

Again, I might be wrong on this and I probably don't consider every aspect the decision-makers have to. =)

I considered Angular, Maria, Ember etc., but they are so much want to be the application and define everything I want... That is exactly the reason why I wanted to stick with Backbone. I think Backbone is an awesome idea, with very nice implementation (even if it highly depends on 2 other libs), all I need is a bit more flexibility. =)

[dirkbonhomme]

Mostly agree with @benqus. The main reason to use Backbone instead of Angular etc is the freedom to extend and use the components as we see fit. That could be improved further by exposing some internals like Backbone.extend and Events.

I just forked Backbone because I also wanted to add a Backbone.Base object that implements Events and extend. Guess that any PR I was about to make won't be accepted then :(