Why is nonObservedAttributes a function?

[acroyear]

just curious. the other attributes are as-is, so i'm not quite sure what could be gained by making nonObservedAttributes a function returning an object (or under what circumstances it would be called more than one on a component).

granted, that's some impressive type-scripting to get the rest of the methods to recognize "this.x" exists from that function.

[acroyear]

I mean, i'm not arguing as such - you coded this for your purposes (and very well). Just curious what the use-case was for this particular case.

[lsegurado]

It is mostly intended for complete objects that cannot be cloned. The function allows it to act as a constructor. In normal cases I take the "attributes" and clone them with a proxy, which allows the instance to not be shared between components. There are objects that cannot be cloned easily or the complexity of observing them is very high. For those cases, I use nonObservedAttributes

[acroyear]

So if there's, say, a large data array being rendered in a table read-only, an optimization would be to put it into nonObservedAttributes and then explicitly call rerender() rather than putting it in attributes state and dealing with it trying to put observers on every tiny thing that will never change?

I get the 'cannot be cloned'. Some state libraries (SproutCore's 'store', which I think Ember still has) add a lot of hidden cruft to the prototypes of the objects they pass around and those can sometimes get into circular loops or worse. e.g, an object's internal attributes pointing back to the store means any clone is cloning the store.

[lsegurado]

You should not use nonObservedAttributes if you are not getting errors on attributes. Calling rerender manually would not change performance unless you do an excessive amount of dom updates and its only intended for internal usage