Where does that HTML that is NOT being drawn actually exist?
I ask mainly because I notice that the values you type into teh input box seem to be retained when you switch the value of sCustomerFormBeingShown back and forth true and false. That suggests (but does not mean) that perhaps the html does not get destroyed as such but is just hidden or something like that.

I ask also because I have different customers that have slightly different templates or I would like to have the ability to branch a customer off to a different template component but not sure if it is a good to have all possible versions in the same page if that HTML is actually somehow being thrown into the DOM.

First, let’s clear a confusion: HTML does not exist per se in your client environment.

The very first thing the browser does when it downloads the HTML is parse it into a DOM, that is a tree of objects that materialize the structure of the html document. The html document itself is put away (discarded or saved into the cache).

Now, this is a special case, it is a template in Ember. It does not exist as such in HTML form. Rather, it is converted into a script that can directly manipulate the DOM to generate the tree of objects. The advantage is this script can be run again everytime one of the data binding changes, updating the DOM tree to reflect those changes.

Now, where does the input value live? Well, in the DOM while it is on the page of course. But not only.

Ember follows a good practice of JS, which is to never use the DOM as a datastore. That is, DOM is write-only. So when the user changes the input field, the contents are stored in the DOM by the browser, and by the input component by ember. Which actually updates its value binding.

When your conditional is false, the corresponding part of the script will just destroy the relevant DOM nodes and Ember components, including the input. But the value still exists. It is wherever you told the input component to write it.

Thus, when the conditional becomes true again, and Ember recreates and renders the components again, the input will be initialized with the value.

That’s about it. I am no Ember expert, so maybe I left some inaccuracies that someone will, hopefully, correct.

Thanks for clearing up the confusion about HTML being parsed into DOM, I would never ever have worked that out sarcasm drips

No seriously thanks for the rest of your reply anyway. This means that I can “tag” certain users with an identifier and branch off into using different components in case they want to customise the page in someway that suits their website without worrying that every users configuration is inside the DOM tree somewhere but not being shown.

Well, sorry if it sounded patronizing, that was not the intent. But sometimes people really come with this kind of confusions, so better secure than sorry.

Yes, you can do this with no worries. If for some reason you actually wanted to have something in the dom but invisible, you would not use a conditional, you would toggle a class or the hidden property on the element. I like to do this for Tab widgets for instance, because it could make sense to have a css that renders all tabs.