When to use Ember.ContainerView and Ember.CollectionView?

Design
1

Ember.ContainerView

I found the ContainerView does not have much use. Any thing that you can do ContainerView can be expressed and much easily understood by using templates. Dynamically add/remove view? Just template it with {{if}} and {{view}} helpers. Dynamic length of items? You can template that with {{each}}.

{{#if showChild}}
  {{view aView}}
{{/if}}

vs

Ember.ContainerView.extend({
  childViews: [ 'aView' ],
  aView: Ember.View.create({})
});

Ember.CollectionView

The CollectionView also does not have much use in a similar sense. Whatever things it can do can be much better expressed by templates with {{each}} helper. I understand that the {{each}} helper is implemented as CollectionView underneath, but I think it would be a good idea to hide the CollectionView as a private class instead.

With Ember 2.0 coming up and we’re transitioning to a component/service architecture, I’m thinking it may be a good time for these to go away.

2

I use them for this sort of thing:

Can you suggest how I might achieve that if they went away?

3

@amk this maybe of interest to you GitHub - yapplabs/ember-wormhole: Render a child view somewhere else in the DOM. and it has a modal implementation already GitHub - yapplabs/ember-wormhole: Render a child view somewhere else in the DOM.

4

@amk Please review http://jsbin.com/bokecoteka/1/edit

The ContainerView is refactored out and replaced with an {{each}} helper. The ContainerView that was in ModalsService is replaced with just plain array.

I think putting the “loop” logic inside the template is more declarative and more readable than looking up for the MyModals component and bounce around inside the class.

Doing this inside the template also gives you greater flexibility to change what’s around the {{view modal}}.

You could argue though that ContainerView gives more control (and maybe performance) by letting you specify specifically which view to teardown when the array is mutated. But I think that’s no longer an issue with the upcoming Glimmer release where you can hint the {{each}} helper with key.

5

@lightblade: Ok, thanks I see what you’ve done. The thing I liked about the original approach was, it gave me fine-gained control over the process of inserting into the DOM, which allowed me to animate it in and out precisely. I suspect it will still be possible as you’ve done it, but perhaps require a bit more code.