Observer syntax differences

Ember CLI
1

Hi All,

can someone explain me what’s the difference between

a. observer1: observer(‘prop1,prop2,prop3’, function () { });

b. observer1: observer(‘prop1’,‘prop2’,‘prop3’, function () { });

i have an older application and version 1 is working with an older ember version, but not with a new ember version. it does not fires the observer anymore. Also what if it’s a computed? i have a few of them also, similar setup like this one.

2

I’ve never actually tried brace expansion without a parent specified but it might work. Normal brace expansion looks like this:

observer1: observer(‘parent.{prop1,prop2,prop3}’, function () { });

So perhaps once brace expansion was introduced, or somewhere in there, you’d need to switch your first example above to:

a. observer1: observer(‘{prop1,prop2,prop3}’, function () { });

Anyway, that’s just a guess. I don’t ever recall using syntax like that (dependent keys all in the same string vs separate strings) but it’s very possible the rules around that changed at some point. I’m actually kind of surprised version 1 ever worked.

1 Like
3

The right way to observe different properties, it’s each as one string except if they are properties of the same object where u should use the way that @dknutsen said (brace expansion with the object as the parent).

Anyway, it’s recommended to the use of computed properties to observe changes in other properties:

https://guides.emberjs.com/release/object-model/observers/

4

The Good

Brace expansion works wonders. Use it.

If ever in doubt what it expands to you can run this in your Ember app’s console:

Ember.expandProperties('{a,b,c}', console.log);

Or play with it interactively with this ember-twiddle.

Brace expansion can be use in all kinds of nice ways and in any place where you would use a dependency string or set of strings. For example I do this a lot:

myValue: Ember.computed.or('model.{currentTask,previousTask}.value'),

This way myValue is either the previous value while the current value is still loading and then switches over when ready. I can even use myValue in liquid-fire to allow animations when the current value updates. There is lots more. Mostly if you can express things with brace notation do so it is so much easier to read.

The Bad

Don’t use observers You’re asking for a world of hurt. Every time I’ve used them they brought on weird bugs and hours of lost time trying to understand them. They also introduce race conditions and circular loops.

The only two times an observer is worth it is:

  • When you have reached the end of the line with computed properties. Usually you never need to worry about this because the end of the line happens in glimmer internals and you never have to think about it. But if your wrapping a jQuery plugin which requires you to call a method when something changes then the wrapper is the end of the line and you forced to use an observer.
  • Or you are debugging something and the only thing in the observer is console.log statements.

But that should be the only time. Any other time can be refactored and changed. I would fight tooth and nail against observers.

The Ugly

There is no ugly; Ember is awesome!

2 Likes
5

Great, thanks. wierd that it worked in ember 2.x