Attempted to handle event `willCommit` on while in state root.loaded.updated.inFlight
ember.js, javascript
Solution
After reading up on model lifecycle in Ember - http://emberjs.com/guides/models/model-lifecycle/#toc_in-flight - I still don't get why this bug appears.
This is not a bug, the in-flight section say's it all:
A record that is in-flight is a dirty record that has been given to the adapter to save the changes made locally. Once the server has acknowledged that the changes have been saved successfully, the record will become clean.
This means that you are trying to change the record while a previously change made it dirty and a possibly call to `this.get('store').save()` is still in the doings e.g. waiting for the server to respond. During this time frame you can't make changes to that same record without getting the error.
So a solution could be to not trigger `this.get('store').save()` after a character of the textbox has changed but rather on focus out for example, or even with a explicit button to save the record which you could disable until your server acknowledges it's change, this would not make a request for every character to the server resulting in sluggish performance due to some latency. Hope this makes sense.
Hope it helps.
Problem
I'm learning how to use EmberJS by doing the introductory tutorial form the "Getting started" page. However, when I get to the "Accepting edits" part, I have a bug: ``` Uncaught Error: Attempted to handle event `willCommit` on <Todos.Todo:ember304:3> while in state root.loaded.updated.inFlight. ``` The call to `Todos.TodoController.acceptChanges()` seems to be triggering that error. The part I'm referring about is this one: http://emberjs.com/guides/getting-started/accepting-edits/ After reading up on model lifecycle in Ember - http://emberjs.com/guides/models/model-lifecycle/#toc_in-flight - I still don't get why this bug appears. One work-around is to save the model each time it changes (so every time the value of the `<input>` changes. Which works fine but would probably perform poorly with a HTTP API (as opposed to fixtures). Could this be due to BC breaking changes in the `ember-data` lib? What else could cause this? Versions of libraries I've used: jQuery: 2.0.3 Handlebars 1.0.0 EmberJS: 1.0.0 RC7 Ember Data: v0.13-102-g6bdebe7