Skip to content
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

Binding declaration order #1164

Closed
bradleypriest opened this issue Jul 13, 2012 · 23 comments
Closed

Binding declaration order #1164

bradleypriest opened this issue Jul 13, 2012 · 23 comments
Assignees
Labels
Bug
Milestone

Comments

@bradleypriest
Copy link
Member

@bradleypriest bradleypriest commented Jul 13, 2012

I'm not even sure where to start trying to work out what's changed, but something in the simplify-properties has made the order of declaration of bindings important.

I had code like this, that broke, the fix was to move the currentStateBinding above the headingBinding.

modalClass: App.ModalPane.extend({
    controller: null,
    headingBinding: "currentState.view.heading",
    currentStateBinding: 'controller.stateManager.currentState'
})

@kselden I'm sorry I couldn't work it out more, anything specific that you can think that would have caused this change?

@krisselden

This comment has been minimized.

Copy link
Member

@krisselden krisselden commented Jul 13, 2012

That's enough, I know what the issue is.

Bindings sync on connect now, but it has dependency on the other binding before it can sync.

It still should cause a sync to be queued when the binding it is watching connects.

@ghost ghost assigned krisselden Jul 13, 2012
@wagenet

This comment has been minimized.

Copy link
Member

@wagenet wagenet commented Jul 21, 2012

@kselden What's the status of this?

@ghempton

This comment has been minimized.

Copy link
Member

@ghempton ghempton commented Aug 4, 2012

I have been bitten by this one as well. I haven't dug very deep, but I am also seeing sync's not being queued correctly.

@wagenet

This comment has been minimized.

Copy link
Member

@wagenet wagenet commented Oct 19, 2012

@kselden What's the status on this?

@szimek

This comment has been minimized.

Copy link

@szimek szimek commented Jan 19, 2013

I'm rewriting an old app that used Ember.js 0.9.3 and just ran into this issue.

@krisselden

This comment has been minimized.

Copy link
Member

@krisselden krisselden commented Jan 30, 2013

The hold up is I don't want to top sort bindings on create, I'd rather reimplement them as ComputedProperties which don't have an ordering issue.

@krisselden krisselden closed this Jan 30, 2013
@krisselden krisselden reopened this Jan 30, 2013
@krisselden

This comment has been minimized.

Copy link
Member

@krisselden krisselden commented Jan 30, 2013

clicked the wrong button

@davvblack

This comment has been minimized.

Copy link

@davvblack davvblack commented Feb 4, 2013

In the mean time, is there a 'right' way to order bindings that IE8 doesn't choke on?

@krisselden

This comment has been minimized.

Copy link
Member

@krisselden krisselden commented Feb 4, 2013

@davvblack use computed properties instead of bindings

@davvblack

This comment has been minimized.

Copy link

@davvblack davvblack commented Feb 4, 2013

What about observers? Are they safe or dangerous?

@krisselden

This comment has been minimized.

Copy link
Member

@krisselden krisselden commented Feb 4, 2013

Can you clarify? This issue is only a binding to a binding, and if that binding is in the prototype, it will be ordered differently on IE8, so if you switch it from binding -> binding to binding -> computed it should work.

@davvblack

This comment has been minimized.

Copy link

@davvblack davvblack commented Feb 4, 2013

Thanks, that answers it.

@lmeijvogel

This comment has been minimized.

Copy link

@lmeijvogel lmeijvogel commented May 30, 2013

Is there any progress on this issue? The readability and maintainability of our app is gradually becoming worse since we're forced to replace more and more bindings with workarounds like observers and computed properties due to problems in IE8.

This is especially a problem with two-way bindings referencing other two-way bindings: I don't know how I should replace those with computed properties.

@lmeijvogel

This comment has been minimized.

Copy link

@lmeijvogel lmeijvogel commented May 31, 2013

@stefanpenner Thanks! That solves it and removes a lot of workarounds. Is this the recommended way to do "bindings" instead of creating 'somePropertyBinding'-attributes on objects?

@stefanpenner

This comment has been minimized.

Copy link
Member

@stefanpenner stefanpenner commented May 31, 2013

@lmeijvogel uses for both exist, in practice I tend to opt for computed.alias. Someone should do guide/doc/blog post about CP's and bindings (cc: @kselden, we could use one of your talks as the foundation)

@wagenet

This comment has been minimized.

Copy link
Member

@wagenet wagenet commented Aug 24, 2013

We're quietly deprecating fooBinding in favor of CPs.

@jayphelps

This comment has been minimized.

Copy link
Contributor

@jayphelps jayphelps commented Aug 31, 2013

@wagenet Is fooBinding also deprecated in Handlebars use? If so, is there an alternative, if not, is there a way to reconcile the usage inconsistency between the two or is it moot?

@ryrych

This comment has been minimized.

Copy link
Contributor

@ryrych ryrych commented Aug 31, 2013

Don't your think guys that binding is a better name than CP in this example? Since I've stared learning Ember, all I read and heard all the time was that Ember is all about bindings and in order to learn it you've got to learn this paradigm and get used to it. It took me a while to understand the concept and now you're changing this convention.

I'm not going to blame anybody but you should do it incrementally and explain to devs why you're doing it this way.

@krisselden

This comment has been minimized.

Copy link
Member

@krisselden krisselden commented Aug 31, 2013

@jayphelps the idea is to follow the convention of handlebars where quoteless values path and quotes mean string and Ember with bind the paths.

@ryrych we are going to make a shorter alias fooBinding: 'bar' will become foo: Em.bound('bar') but we aren't going to have deprecation warning for using 'fooBinding' and it will be supported for a while, he is just talking about documentation.

There are timing issues with bindings during initialization, whereas CPs you can control the timing because they aren't computed until you get or set them.

Originally bindings scheduled sync on the run loop when you connected them which took care of working out ordering, but it was especially problematic in during the render queue, because this would result in multiple render phases if view are created during render that have a binding.

Since CPs act on consumption, they are more ideal for views.

@jayphelps

This comment has been minimized.

Copy link
Contributor

@jayphelps jayphelps commented Aug 31, 2013

@kselden oh the rc8 change. What about when I want to assign the variable without binding it? I'm aware of unbound for regular outputs, but what about inside helpers?

@ryrych

This comment has been minimized.

Copy link
Contributor

@ryrych ryrych commented Aug 31, 2013

@kselden cool. It turns out that this helped me to solve another problem! (please read the Edit section)

@ryrych

This comment has been minimized.

Copy link
Contributor

@ryrych ryrych commented Feb 12, 2015

Hi, I have a property that I'm binding to via Binding suffix is not displayed under 'Deprecations` tab in Ember Inspector. What's the status of this deprecation? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.