Something is wrong with best practice rules

1 
lines: Ember.computed('linesReady', 'selectedID', function () {
		let selectedID= this.get('selectedID')
		let lines= this.get('linesReady')

		return lines.map(line => {
			if (line.options.entityID === selectedID) {
				Ember.set(line, 'isSelected', true)
			} else {
				Ember.set(line, 'isSelected', false)
			}
			if (!line.special) {
				line.options.weight = lienWeight
			}
			return line
		})
	})

As you can see, I have to use Ember.set in order to avoid ‘You must use Ember.set blah blah’

If I use Ember.set I get 'Do not send events or actions in Computed Properties. This will cause data flow issues in the application, where the accessing… ’

So? What is wrong?

2

Computed properties should not have side effects. They should be pure functions. That is indeed a best practice.

How do I explain this? When someone calls .get(‘xxx’) they would not expect another property ‘yyy’ to change. Furthermore, the function inside the computed property does not get called every time someone calls get, but only if one of the dependent properties has changed since it was last called. This makes it really hard to know in practice whether ‘yyy’ will be changed when you call .get(‘xxx’) and that makes for really hard to find bugs.

1 Like
3

Hi, Thanks for the fast reply. You are right of course, but what to do if I want to set something when a property changes? with mut for example?

Let’s say that my computed property depend on three keys, how I manage this if I want to set something when my computed is triggered?

Or I should avoid this at all and complicate my code?

4

Hi again, I cloned all and return completely new array. Seems to work.

5

Thats the correct behaviour, instead of mutating a property create a new object with the updated attributes.

6

Very often when someone asks so how do I do x when we say x is a bad practice, they are really trying to implement y and think x is the best way. So what are you trying to do?