backbone.stickit
backbone.stickit copied to clipboard
Updating select collection dynamically
Is there any way to update the collection for a select dynamically? It appears that the collection is fixed at the time the bindings are evaluated. This is not working for me in two use cases:
- The collection is fetched using an ajax request and the result of the request does not come in by the time the bindings are evaluated. Put another way the bindings are evaluated as soon as the view is loaded in the browser, however the response for collection.fetch() has not yet arrived.
- The collection gets dynamically updated as the application executes.
Here's a jsFiddle which I would like to see work. The dropdown has 2 cities initially. The "Add City" button adds a new city to the collection. However, as it stands, the dropdown is not updated. What's the best way to make this work? Is there a way to reevaluate the bindings?
Any thoughts on this please?
You can call this.stickit()
again to force a rerender. Working jsFiddle
Support for this would be great. In particular, if stickit knows a select is backed by an actual Backbone.Collection - it would be great if the select options could be repopulated when the collection changes.
I agree, that support for a real Backbone Collection would be really good.
Idea suggested by @yousefcisco is very creative but I would still consider it as a workaround.
+1, automating stuff as much as possible would be great. :)
Is it possible to reevaluate and rerender just one bining? If yes, we can listen for changes to the collection and just rerender that drop-down.
Yes - we just added support for re-initialize a binding through the new addBinding
api. I'm open to reviewing ideas or pull requests that work better with backbone collections, as long as it doesn't add a lot of code :).
What about using backbone-relational for this? This plug-in does a good job with relational collections.
I think backbone-relational is kind of a heavy dependency for this.
Hi. I only recently started using Stickit and am a big fan already. I was a little disappointed when I found that updating my collection didn't cause the select to re-render, since I also prefer to lazy load the data for my views.
I agree with nareshbhatia that just listening for changes to the collection and re-rendering the select seems sensible. Also, it will need to set the selected option to the model attribute that it is observing.
I've completely changed my mind about this and I think we need a different way to update selects based on changes to the collection without having to call this.stickit()
I recently had to implement a large form with a huge number of stickit bindings and needed to update the state/county select based on the country selected. At the beginning it seemed like I could do this by calling this.stickit()
after the user changed the country to update the state/county select. This didn't work as expected and I was faced with a race condition that caused the state/county select to stay the same and the country to revert to the default value.
Any ideas for a pull? I haven't needed this in a while, but I remember being bitten by it...
Ok so i've just had a read of the code. I was looking for a way to rebuild the select options and noticed that actually the options are rebuilt every time the property the select is observing changes on the model. So a work around is:
selectOptionsCollection.fetch().done(function() {
model.trigger('change:myattribute', model);
});
However, a few concerns:
- We still want the select options to be updated automagically.
- Stickit seems to have a dependancy on the model being passed as per the 'real' change event. So if I don't pass the model as the second arg Stickit throws an error.
- It seems a bit heavy handed (albeit convenient for us) that when the selected option changes on the model, Stickit will rebuild the options rather than just setting the value.
That still feels like a dirty work around, I would rather manage the select options manually than force it to refresh by messing with the model values.
agreed @yousefcisco
It's a work around. Not that dirty though as you're guaranteed a clean set of options and no other bindings are destroyed and re-stuck. Points 1, 2 and 3 still need to be addressed before we can be happy with dynamic select options.