Ok, so having done some research on the Web and seeing the code used by others it seems that the best approach is not to use all-encompassing JS objects for data. Breaking up your non-persistent data in to its own controller properties, computed properties and aliases seems to be the “happy path”. This helps prevent infinite loops caused by calling methods which then cause computed properties to re-calculate causing the same methods to be called again (stack exceeded error).
I looked at my JS object and decided to take all of the static properties and hard code them in to templates/component calls, e.g. I set the header of a modal component as a “header” attribute when calling it rather than using property from the controller as this was unnecessary. I did keep some of the static properties in controller properties where they were part of a small JS object that was passed to a component as an attribute for the component to generate its template from, e.g.
contactMerchantModalTabs: {
call: {name: 'call', text: 'Call', active: false},
email: {name: 'email', text: 'Email', active: false}
},
but otherwise static properties became hard-coded.
I then took all of the dynamic properties and split them up in to their own separate properties with the exception of form field options/values which I grouped under their own JS object. This made it much easier to get and set values and made the code easier to read as there were no long get calls to access deeply nested JS object properties, e.g.
this.get('myObject.firstLevelProperty.secondLevelProperty.thirdLevelProperty');
I’m now happy with my streamlined controller and templates and things are working more predictably now too!
If anyone can spot any issues with my approach I’d be glad to hear about them as I am still getting to grips with Ember and have much to learn!