For anyone who's looking for the changelog, it's at the bottom of the page so it's easy to miss.
* Made the return values of Collection's set, add, remove, and reset more useful. Instead of returning this, they now return the changed (added, removed or updated) model or list of models.
* Backbone Views no longer automatically attach options passed to the constructor as this.options, but you can do it yourself if you prefer.
* All "invalid" events now pass consistent arguments. First the model in question, then the error object, then options.
* You are no longer permitted to change the id of your model during parse. Use idAttribute instead.
* On the other hand, parse is now an excellent place to extract and vivify incoming nested JSON into associated submodels.
* Many tweaks, optimizations and bugfixes relating to Backbone 1.0, including URL overrides, mutation of options, bulk ordering, trailing slashes, edge-case listener leaks, nested model parsing...
* Made the return values of Collection's set, add, remove, and reset more useful. Instead of returning this, they now return the changed (added, removed or updated) model or list of models.
Given that calling `collection.add(foo)` returned `collection`, when were you ever using the return value for anything? Going forward you might, but I would be very surprised if much if any code was broken by this.
* Backbone Views no longer automatically attach options passed to the constructor as this.options, but you can do it yourself if you prefer.
This might require going through your code base, but it's just adding one line in the `initialize` function:
The return values change matters if you are chaining actions anywhere, which isn't that uncommon.
And yes, some people do have lots of views. In my current codebase we use Backbone.View as the base of all our frontend web components. This won't take us a day to update, but it's far from trivial, and we will have to regression test every component.
This should actually only take you 2 minutes if you'd like to keep the old behavior ... regardless of how many View classes you happen to have in your app. For example:
var originalView = Backbone.View;
Backbone.View = function(options) {
var instance = new originalView(options);
instance.options = options;
return instance;
};
Well, I can't give you stats about the codebase anymore, but to give you an idea, the app was stated with Backbone 0.3, and contain between 2 and 3 hundred views, collections and models.
For the `.add` etc, it can seems straightforward, but when greping you will have a lot of noise from similar methods in other libs like jQuery.
The option is the real deal. Sure I can implement the behavior back. But I don't call that upgrading. If I upgrade I want my code to look like is was coded for the new version, not maintaining 3 years of hacks for backward compatibility.
So it mean that I have to grep hundreds and hundreds of `this.soptions.something` replace them by `this.something`and add `this.something = options.something`in the constructor.
It's a PITA.
And in fine I don't see the rationale for this removal, I failed to find the commit.
You're missing a lot, but you would have had to peruse the commits that have been happening over the past year to know how much has changed.
I'm not sure how to proceed with my own LayoutManager plugin. Hoping someone will PR a fix making it compatible, because my initial attempt told me it wasn't going to be trivial.
Looking into it, it seems like most of your issues stem from the fact that you depended on View._configure being called during initialization. You overwrite it here:
I can't speak to the Backbone.js changes, but isn't one of the odd things about Rails versioning the fact that 3.x -> 4.0 is essentially a dot release upgrade, but 4.0 to 4.1 a full version upgrade (many things are deprecated from 3.x to 4.0, and 4.1 will remove them entirely?)
That was the plan, but now we are planning to make 4.1 an easy upgrade as well, and not remove deprecations that were originally planned on being removed.
That is precisely why our apps are currently "stuck" on 0.9.10. The upgrade process for backbone is rather painful, as you end up hunting for "undefined" issues all over the place.
Any change that renders my entire application broken should be a major version bump.
Where can I read more about changes related to nested model parsing and submodels? This is something I had to implement just a week ago, and I resorted to overriding `set`. I wonder if they made it easier, or if there is a builtin support for nested models of some kind.
Jeremy, thanks! I tried overriding Model's `parse` in 1.0 but wasn't satisfied because it seems to be called in some cases but not the others. (I can't recall a specific example right now; maybe it was parsing the collection from server, or creating a collection using constructor).
Do you think there are drawbacks to overriding `set`? It seems to work well for me but I'd love to hear your opinion:
Comments
For anyone who's looking for the changelog, it's at the bottom of the page so it's easy to miss.
* Made the return values of Collection's set, add, remove, and reset more useful. Instead of returning this, they now return the changed (added, removed or updated) model or list of models.
* Backbone Views no longer automatically attach options passed to the constructor as this.options, but you can do it yourself if you prefer.
* All "invalid" events now pass consistent arguments. First the model in question, then the error object, then options.
* You are no longer permitted to change the id of your model during parse. Use idAttribute instead.
* On the other hand, parse is now an excellent place to extract and vivify incoming nested JSON into associated submodels.
* Many tweaks, optimizations and bugfixes relating to Backbone 1.0, including URL overrides, mutation of options, bulk ordering, trailing slashes, edge-case listener leaks, nested model parsing...
I don't think I'm very picky about versions meanings. But still the first two items are huge breaking changes for a dot release...
If I hadn't left my previous job, It would take me a day or two to upgrade. Even Rails 3.2 => 4 is more straightforward.
How?
* Made the return values of Collection's set, add, remove, and reset more useful. Instead of returning this, they now return the changed (added, removed or updated) model or list of models.
Given that calling `collection.add(foo)` returned `collection`, when were you ever using the return value for anything? Going forward you might, but I would be very surprised if much if any code was broken by this.
* Backbone Views no longer automatically attach options passed to the constructor as this.options, but you can do it yourself if you prefer.
This might require going through your code base, but it's just adding one line in the `initialize` function:
Annoying if you have hundreds of views that directly extend Backbone.View, but not something that should take a day to fix?Am I missing something?
The return values change matters if you are chaining actions anywhere, which isn't that uncommon.
And yes, some people do have lots of views. In my current codebase we use Backbone.View as the base of all our frontend web components. This won't take us a day to update, but it's far from trivial, and we will have to regression test every component.
This should actually only take you 2 minutes if you'd like to keep the old behavior ... regardless of how many View classes you happen to have in your app. For example:
Ahh..., isn't JavaScript just a lovely thing ;)Sure you can hack things up like that. But when you use and update a library, you don't want to rely on deprecated behaviors.
Doh, completely whiffed on chaining. I can see that breaking in weird ways. Thanks for the insight.
Well, I can't give you stats about the codebase anymore, but to give you an idea, the app was stated with Backbone 0.3, and contain between 2 and 3 hundred views, collections and models.
For the `.add` etc, it can seems straightforward, but when greping you will have a lot of noise from similar methods in other libs like jQuery.
The option is the real deal. Sure I can implement the behavior back. But I don't call that upgrading. If I upgrade I want my code to look like is was coded for the new version, not maintaining 3 years of hacks for backward compatibility.
So it mean that I have to grep hundreds and hundreds of `this.soptions.something` replace them by `this.something`and add `this.something = options.something`in the constructor.
It's a PITA.
And in fine I don't see the rationale for this removal, I failed to find the commit.
The commit you want is here:
https://github.com/jashkenas/backbone/commit/51eed189bf4d258...
and the pull request:
https://github.com/jashkenas/backbone/pull/2461
You're missing a lot, but you would have had to peruse the commits that have been happening over the past year to know how much has changed.
I'm not sure how to proceed with my own LayoutManager plugin. Hoping someone will PR a fix making it compatible, because my initial attempt told me it wasn't going to be trivial.
Looking into it, it seems like most of your issues stem from the fact that you depended on View._configure being called during initialization. You overwrite it here:
https://github.com/tbranyen/backbone.layoutmanager/blob/mast...
but this was completely removed with the update:
https://github.com/jashkenas/backbone/compare/1.0.0...1.1.0#...
In backbone's defense, that wasn't part of its public API, but it does make updating challenging. I'll give it a try and see if I can be of some help.
What are the issues you're seeing with LayoutManager? Are they reflected in the changelog or hidden in commit messages?
Yes, for that i prefer my own Namespace and extend not directly from Backbone (e.g. same when you use Backbone-Marionette).
Before you change your views, you should think about an own class on top of backbone and extend from that class.
So you can handle default behaviours easier and centralized.
I can't speak to the Backbone.js changes, but isn't one of the odd things about Rails versioning the fact that 3.x -> 4.0 is essentially a dot release upgrade, but 4.0 to 4.1 a full version upgrade (many things are deprecated from 3.x to 4.0, and 4.1 will remove them entirely?)
That was the plan, but now we are planning to make 4.1 an easy upgrade as well, and not remove deprecations that were originally planned on being removed.
Oh that's awesome. Thanks for the info.
That is precisely why our apps are currently "stuck" on 0.9.10. The upgrade process for backbone is rather painful, as you end up hunting for "undefined" issues all over the place.
Any change that renders my entire application broken should be a major version bump.
Here's a direct link to the actual net changes: https://github.com/jashkenas/backbone/compare/1.0.0...1.1.0#...
Where can I read more about changes related to nested model parsing and submodels? This is something I had to implement just a week ago, and I resorted to overriding `set`. I wonder if they made it easier, or if there is a builtin support for nested models of some kind.
Happy to oblige. There's no built-in convention for it, but you can do something like this:
... assuming that friends is an array of JSON objects suitable to be transformed into Person models.Jeremy, thanks! I tried overriding Model's `parse` in 1.0 but wasn't satisfied because it seems to be called in some cases but not the others. (I can't recall a specific example right now; maybe it was parsing the collection from server, or creating a collection using constructor).
Do you think there are drawbacks to overriding `set`? It seems to work well for me but I'd love to hear your opinion:
https://gist.github.com/gaearon/6689379
If you want something lightweight I'd go with the approach @jashkenas mentioned. But also might want to checkout:
https://github.com/PaulUithol/Backbone-relational
Direct link to the changelog you quote: http://backbonejs.org/#changelog