Deprecate views in 1.13, Addonize and remove from core in 2.0

[mixonic]

This is a quest issue tracking the process of removing views from Ember 2.0.

• In Ember 1.13 the following APIs will be deprecated:
  • {{view 'some-view'}}
  • {{view.someProp}}
  • Using Ember.Select (which is a view) and {{view "select"}}
  • Using Ember.View (except for internals)
• In Ember 1.13, using Ember.Checkbox will warn (once) that it will become a component in 2.0
• In Ember 2.0, the following APIs will be removed from Ember:
  • {{view 'some-view'}}
  • {{view.someProp}}
  • Using Ember.Select (which is a view) and {{view "select"}}
• In Ember 2.0, Ember.Checkbox will become a component instead of a view
• An addon will be released called ember-legacy-views with 2.0 (at the latest)
  • provides Ember.View
  • toggles a private flag that enables {{view.someProp}}
  • provides (or toggles a private flag for) {{view "some-view"}}
  • provides {{view "select"}}

Documentation updates will need to happen:

• Deprecation guide for views
• Deprecation guide for select. Since select will be removed in 2.0, alternative existing addons should be suggested
• Review guides to remove view documentation, select documentation

[krisselden]

viewName?

[jackmatt2]

Why is Ember.Select not being converted into a component also like Ember.Checkbox? Why will it be packaged as a separate addon? It seems to me that an HTML select element is something pretty much all projects will use.

[Eptis]

not all of them, so I would prefer an addon for these things. But I also wonder, why not make Ember.Select a component as well (in the addon)?

[mixonic]

I would like to keep this ticket fairly tactical, but would happily discuss this in detail on discuss.emberjs.com if we can take the discussion there. I know some of the items here may be controversial.

The select view has terrible performance. Robert was showing me one of his versions the other day that was easily an order of magnitude faster. It has been pathological and we were not able to improve it within semver constraints. These constraints also limit us from just making it a component.

The select view also relies heavily on two way binding. This will not be an idiomatic development style in Ember 2.x, and the select view would quickly become an exception to the entire programming model of data-down actions-up we are excited about. Even if it we could just make it a component, it would be unlike what we expect components to be.

For these two reasons, it needs to go in 2.0. We do not have a viable component version that uses modern idiomatic style, so we will instead be pushing the select implementation back to addon-land where it can be iterated upon. There are already a few decent options, and I'm sure we will have a few more arise using the new 1.13 APIs and angle components when they land. In time, perhaps one of these could become official.

The select view will be part of the ember-legacy-views add-on, which will be supported until Ember 2.4. This should provide plenty of time for a well performing and modern option to mature.

[amk221]

There is no upgrade path for this scenario now that view is going away:

{{#each myComponents key='elementId' as |componentInstance|}}
  {{view componentInstance}}
{{/each}}

What is useful about the above pattern is:

• Granular control over when a component is rendered
  
  (Specific example: a component which loads async content and then renders a separate, but related component in a different part of the DOM)
• The components can be initialised with an arbitrary attrs hash. It's not possible to do {{component componentInstance attrs=attrs}} Because that would result in attrs: { attrs: {} }
  
  (Specific example: modal dialogs which don't all accept the same attrs signature)`

Edit: Reference to other people with the same issue

[rwjblue]

2.0.0 has shipped. Closing...