Bootstrap DOM templates into the container instead of Ember.TEMPLATES

[lukemelia]

This is almost certainly the direction we want to go.

But I am unsure about backward compatibility and whether we should feature flag this.

For normal usage, this change should be transparent. Not sure if people may be abusing this method in some way that requires leaving in the no container branch as I have here.

Feedback?

[lukemelia]

@machty @wagenet @wycats input on the backwards compatibility question?

[wagenet]

Definitely would like to hear from @wycats. We don't worry about breaking abuses of the system, we just don't want to break stuff that we said would work.

[stefanpenner]

when don't we have a container.

[wycats]

Unfortunately, we really did document Ember.TEMPLATES. Let's leave them in there, with soft deprecation (i.e. excision from the docs). We also probably want to have an API that can be used in precompiled templates that we document instead of Ember.TEMPLATES that we test and works reliably across the various tooling people are using.

@lukemelia thoughts?

[wagenet]

@lukemelia, ping.

[lukemelia]

@wycats regarding your suggestion of an API that would be used for precompiled templates... in the ember-app-kit approach, you precompile to modules, which are then resolved on demand. If we want a solution for the current DefaultResolver approach, it seems like we could just continue to support Ember.TEMPLATES, instead of creating something new.

For both approaches though, I think it is a win to register with the container when bootstrapping templates from HTML. I can update the PR so that templates are also added to Ember.TEMPLATES. Does that seem like a win?

[wagenet]

@wycats, @lukemelia what needs to happen for this to progress?

[rwjblue]

I think we should bootstrap into the container only, but update the resolver to check Ember.TEMPLATES after checking the container.

I believe this approach would be backwards compatible since folks that are manually adding templates to Ember.TEMPLATES (ala plugins/addons) would still work properly (after a container.lookup miss). And we can remove references to Ember.TEMPLATES from our docs/guides.

@lukemelia - Thoughts?

[lukemelia]

@rjackson sounds good to me. If we have agreement, I'd be happy to expand this PR to include those changes.

[machty]

@rjackson that idea sounds good to me.

[rwjblue]

@lukemelia - I think we are all on the same page here (I don't see any disagreement to my proposal). Need any other input to pick this back up again?

[lukemelia]

Sounds good. I will update this PR accordingly.

[lukemelia]

After digging into this, I have discovered a few issues with the planned approach.

1. The idea of checking the container registry first and using the resolver to fallback to Ember.TEMPLATES is contrary to the way the container works. The container checks the resolver first and then falls back to the registry if the resolver comes up empty. This is the reverse of how Ember developers expect things to work (according to my informal surveys), and I would like to see it reversed at some point. For the purposes of this PR, though, we can check Ember.TEMPLATES via the resolver first and then fallback to the registry, and the good news is, that's things already work.

2. The convention for looking up templates is inconsistently implemented. In some cases, /s are normalized into .s before lookup, but not all cases. The DefaultResolver converts all .s back to /s, so registering templates with Ember.TEMPLATES with /s works consistently. jj-abrams-resolver does something similar. [fixes #2723 #2813] opt-out flag for slash being the namespace separator. #3537 discusses the path forward for this.

Long story short, item 1 above is something we can work with for now, but item 2 is a blocker to implementing the change contemplated here.

[wagenet]

Stuff has changed a lot in the last year+. @emberjs/owners thoughts?

[machty]

Pretty sure we can close this; ember-cli does this automatically and we have test cases against Ember.TEMPLATES to make sure we don't break people still in globals mode.