-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ember.Select and belongsTo with async:true dosen't work #1405
Comments
I believe this is a longstanding, known issue. See ember.js issue 1333 for discussion. They discuss some workarounds in the thread... I've switched to using non-async options for select boxes when possible, to avoid the issue altogether. |
I'm having the same issue as you, they describe it as "not a bug" in emberjs/ember.js#1333 but it's actually a pain. It will also switch your select to an empty mode if you call model.save() since Ember Data will set your fields to a promise. Tested with Ember 1.1.2 and ember data 1.0.0-beta3 |
@rickard2 your problem is that Here is your updated jsbin http://emberjs.jsbin.com/uzUNaQA/6/edit |
@marcioj that seems to solve the problem, still getting used to ember-data 1.0 thanks! |
There is a subtle issue with @marcioj solution to this one that I've tried to highlight: http://emberjs.jsbin.com/uzUNaQA/20/edit?html,js,output If you do this with a fresh object that doesn't have the belongs to explicitly set to null, accessing the content property isn't going to do you much good. If you do set the author to null when you instantiate the class, it goes through the correct setters and gives you an object with the content property of null. The real issue comes in when you load an existing model with a null belongsTo because you can't reasonably force it though the setters and are therefore unable to manipulate the relationship. This isn't really a problem with the select or Ember Data (at least not a simple one), but it is a bit of an unintuitive incompatibility. You can get around this by binding the properties to the controller and then manually setting them on the object, but it's not my favorite approach and I'd love to hear some alternatives. |
I believe I have a similar issue here - http://stackoverflow.com/questions/22799094/setting-a-belongsto-attribute-via-an-action-on-controller-not-working/22799776?noredirect=1#comment34785844_22799776 Looking at the answer of this post, just having a selectionBinding attached to a belongsTo (async) of a model doesn't render the selection correctly. I might be wrong in this so wanted to have a second opinion on it. |
My solution for the time being is to do something like this on my controller: # I have an ArrayController dedicated to the list
needs: ["selections"]
selections: Ember.computed.alias "controllers.selections"
selectedObject: null # so it doesn't get proxied to the model
objectSelected: (->
@set "myModelProperty", @get "selectedObject"
).observes "selectedObject" I have setupController: (controller, model) ->
@_super controller, model
@store.findAll("selections").then (selections) =>
@controllerFor("selections").set "model", selections
# There needs to be a selection made even if the user doesn't touch the element
controller.set "selectedModel", investmentModels.get "firstObject" |
Alright, I've made some progress on the workarounds to get this situation to work. I'm sure there are better ways to do this, but this is (so far) the only one I've found to cover all the problems without excessive manual intervention. For existing recordsFor existing records, you need to do something like the following in your route: // your-route
beforeModel: function() {
var self = this;
return Em.RSVP.hash({
firstBelongsTo: this.store.find('first-belongs-to'),
secondBelongsTo: this.store.find('second-belongs-to')
}).then(function (models) {
self.controllerFor('this-route').setProperties(models);
}); And in your controller, be sure to declare the properties before setting them as Ember tries to throw then into content when they don't exist: // your-controller
App.MyController = Ember.Controller.extend({
firstBelongsTo: null,
secondBelongsTo: null
}); By returning a promise in the beforeModel hook, you are telling the route to resolve the promise BEFORE loading the model, which also mean before any rendering occurs. This gives your application time to load the data up front before binding it to the select boxes. For NEW records.New records present an unexpected quirk in this situation because the To solve this, I'm currently manually setting all of the relationships to null in the model hook: // your-route
model: function() {
this.store.createRecord('your-record', {
firstbelongsTo: null,
secondBelongsTo: null
}); Not ideal, but by their powers combined, you can use async There is undoubtably more to this issue, but this seems to have drastically improved the situation for me. |
Thanks for this @WMeldon. I ran into this problem recently and your comments helped me figure out what I was doing wrong. |
Has this been fixed? |
I'm also curious to know if this is something that will be fixed soon. Thanks. |
Any news? :) 👍 |
use This is not an ember-data issue. |
I don't know if this is the right place, so I posted my question at Stackoverflow also: http://stackoverflow.com/questions/26543093/how-to-preselect-a-value-on-an-ember-select-view Thanks for your help. My select works now, but I don't know how to preselect a value dynamically - or isn't it possible at the moment? This is my select:
It works fine when I try to get the current active value:
These are my models:
|
Thanks @stefanpenner ! I found using
Be aware the As a result when using |
When you have a asynchronous belongsTo relationship and bind that to a
Ember.Select
it seems that the correct value is not selected in the view.Example here: http://emberjs.jsbin.com/uzUNaQA/1/
Tested with Ember Data Canary as of today and Ember 1.0.0
The text was updated successfully, but these errors were encountered: