Ember.Array as you stated adds non-native implementations as well as polyfils, like you wrote, this could be “confusing”. I’m writing my first large Ember Application right now and I sort of feel bad for not realizing this sooner. @Myrdhin I guess I read your question from a strange angle.
So, if Ember config is left to defaults, the
EXTEND_PROTOTYPES configuration is set to be
true and that means that the developer doesn’t have to explicitly use
Ember.A to create an
Array.prototype is extended already. However, regardless of the configuration it doesn’t hurt to use
Ember.A and is actually encouraged when writing anything which could be used outside of the current Ember environment (such as add-ons, helpers or even components). @jasonmit So do I have that pretty much correct?
After having first read the following from the Ember.Array documentation:
When you are designing code that needs to accept any kind of Array-like object, you
should use these methods instead of Array primitives because these will
properly notify observers of changes to the array.
// By default if (EXTEND_PROTOTYPES === true) then:
const ingredients = ['laughter', 'sunshine', 'puppy dogs'];
// Would be the same as using
const ingredients = Ember.A( ['laughter', 'sunshine', 'puppy dogs'] );
@Myrdhin For my understanding now, the answer to the original question thanks to @jasonmit and the docs would be that either A. the developer has
EXTEND_PROTOTYPES set to false so they must explicity call
Ember.A when they need an
Ember.NativeArray or B. The developer is writing an add-on or thinks their code might be dropped into a different project and is ensuring that it will run correctly in either configuration. I suppose that is the benefit of using
Ember.A. Also, if
EXTEND_PROTOTYPES is set to true there is still no big downside to using
Ember.Mixin.detect to first determine if the Array is already an Ember Mixin, so it won’t cause problems or do more work than needed (other than calling detect).
So, I am a week+ into an Ember project, I am going to keep
EXTEND_PROTOTYPES set to default for now. I think since this is my first real Ember Application it would be good to learn within the suggested defaults before deciding that I already know what I want. I’m not a huge fan of convienance methods on the
Array.prototype, but that could be a bias inherited from working in a volatile environment such as the web. Since Ember handles so many aspects of development, for the time being I am going to assume that in the confines of my Ember app, Ember knows best (in my case anyways).
Thank you both for the question and the responses and in advance for any advice you might leave. I want to learn the correct way and I hope that I now seem to have the right understanding?