Skip to content

Instantly share code, notes, and snippets.

@stefanpenner
Last active December 17, 2015 14:49
Show Gist options
  • Save stefanpenner/5627411 to your computer and use it in GitHub Desktop.
Save stefanpenner/5627411 to your computer and use it in GitHub Desktop.

This document aims to help aggregate issues and solutions around the defaultContainer deprecation.

The Error Message:

Using the defaultContainer is no longer supported. [defaultContainer#lookup]

breaux, where's my defaultContainer?

Well it is still there, and will continue to work for some time. Likely it will be gone by 1.0.0 final

Why is this happening.

We recieved several issues, these issues were non-obvious but it appeared that they where caused by the defaultContainer leaking between tests. This obviously lead to very unexpected test failures. The quick fix was obviously to ensure the defaultContainer was purged between tests. Upon further investigation, almost all the issues turned out to be childViews which were not wired up correctly. For example not using this.createChildView on creation of childViews. Ultimately, the existence of the defaultContainer was masking the reported issues, and likely many more. In addition the obvious issues, we are trying to remove our dependency on globals (but that is another story).

migration paths: (WIP)

if you are creating dynamic views in the context of the parentView, you should be using:

this.createChildView(viewClass, viewAttributes)

if you are creating views outside the context of a parentView (this may not be recommended, but it is happening) you will want to make sure to instantiate your view via the container itself.

this.container.lookup('view:apple')
// will provide a instance of apple view.

how container lookups are resolved

Action items

  • appendTo another ember view, should then grab the container of that view.
  • continue to flush out this gist
  • improve docs/guides
  • improve deprecation warnings
  • explore methods where this works without developer thought (without perf regressions)

fixes in the wild:

But I have a legitmate usecase not expressed here.

Post a comment, describing the issue, and hopefully a jsbin or jsfiddle demonstrating the issue. As time permits, a solution or migration path will finds its way up into this document.

Q/A

Q: can we not have views get a container by default? The App gets a container right?

A: App is the root, and as such it creates the initial container.

Q: So when I do createChildView, which container is that using?

A: typically, it is using the container passed down the view hierarchy, and this typically occurs at creation.

Q: Could we set the container when you append it to a container view's childViews array?

A: likely, but its not just the container, it is a place for the framework to wire-up other things. https://github.com/emberjs/ember.js/blob/master/packages/ember-views/lib/views/view.js#L2072

(ask questions in the comments and I will hoist them here.)

@stefanpenner
Copy link
Author

@hannicolas im unsure what needs to be updated?

@richardkmichael
Copy link

@stefanpenner The example in the guide poses problems for newcomers (me). I can't tell you what it should say (because I'm just learning Ember), but as @tachang also mentions, I expected (something like the guide's example):

<!-- index.html -->
...
<head>
  <!-- Other script tags for Ember itself and dependencies omitted. -->
  <script type="x-handlebars" data-template-name="foo-view-template">
    Hello, World! from foo view
  </script>
  <script src="myapp.js"></script>
</head>
// myapp.js -- only this content, nothing else.

var app = Ember.Application.create();  // Is this even necessary?

var fooView = Ember.View.create({
  templateName: "foo-view-template"
});

fooView.append();

.. to display a page containing:

<body>
  <!-- Possibly other stuff in index.html, followed by... -->
  Hello World! from foo view
</body>

.. but instead the console prints (the git.io link points to this gist):

Uncaught Error: Container was not found when looking up a views template. This is most likely due to manually instantiating an Ember.View. See: http://git.io/EKPpnA

@supairish
Copy link

@richardkmichael I'm having the same problem, did you find a fix?

@jmdfm
Copy link

jmdfm commented Sep 7, 2014

@richardkmichael @supairish @stefanpenner I've found that changing from .create to .extend from making new view for insertion prevents the deprecation warning from being triggered when you set a templateName. YMMV.

@avaz
Copy link

avaz commented Oct 26, 2014

The docs of Route.loading event is showing an example of the old way: [http://emberjs.com/api/classes/Ember.Route.html#event_loading]
How this would be with the this.container.lookup strategy? I mean, what is the best way to pass the 'classNames' is the example in the Route.loading of create and append views?
I'm willing to update the docs but I'm don't know for what put in the example.

@markmilman
Copy link

I'm trying to use Ember component in an existing rails app as part of gradually migrating the view layer created by rails to Ember and form a single page app.
I have used the following code, which works in 1.5.0 but throws the deprecation warning (and therefore breaks in 1.8) . Will appreciate any help to get this working in 1.8.0:

Sbcx.MaterialsListComponent = Ember.Component.extend({
  layoutName: 'components/materials-list'
  materialList: null

  actions: {
    remove: (m)->
      console.log('removed ' + m.get('name'))
      m.destroyRecord()
  }
})


$(document).ready ->

  Sbcx.store.find("material").then (result) ->
    $(".component-placeholder").each ->
      # Build the component & stuff in any pre-existing value
      component = Sbcx.MaterialsListComponent.create(materialList: result)

      # Gut out the container div & replace with the component
      component.replaceIn this

@yanni4night
Copy link

This is really confused,I am going to skip this page guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment