[RFC] Yielding components

Summary

Move to v2.0, allowing ember-power-select to shed it’s ember 1.13 baggage and expose a nicer API

Motivation

Your emberconf keynote got me thinking. ember-power-select was created back in ember 1.13.8, and despite dropping support for ember < 2.3.1 and gaining embers powerful component API’s, ember-power-select has not been able to migrate to this new API, since it hit 1.0.0 while ember 1.13 support was still required.

However, as the addon has matured, it may be time to consider deprecating power-select 1.0 and moving towards a better API. This issue is to (hopefully) start that discussion and see if the community and users can come to a consensus.

I think we all agree that while the power select API is very powerful, the popularity of this addon necessitates something far more flexible.

Detailed Design

Most common usage:

{{power-select
  options=options
  selected=selected
  onChange=(action (mut selected))
}}

This is roughly equivalent to the current invocation for ember-power-select-blockless, with the notable change of onchange becoming onChange, which makes it more in line with the other ember power components (inspiration from #899).

A labelPath can also be provided:

{{power-select
  options=options
  selected=selected
  onChange=(action (mut selected))
  labelPath="foo"
}}

Again, nothing new. Where things get interesting is when we start passing blocks:

{{#power-select ...args... as |select|}}
  {{#select.selected as |country|}} {{! names are subject to change }}
    {{country.name}}
  {{/select.selected}} 
  {{#select.option as |country|}}
    <img src={{country.flag}}>
  {{/select.option}}
{{/power-select

If you want to pass a block, but render the same thing in both the select and options:

{{#power-select ...args... as |select|}}
  {{#select.item as |country|}}
    {{country.name}}
  {{/select.item}} 
{{/power-select

Which behaves very closely to the way the component works today

Other components could be yielded in a similar fashion, such as a placeholder.

Open question: how are groups handled?

The path forward:

First, the onchange to onChange deprecation can be handled almost immediately.

After the community has reached consensus on the user facing API of the new power-select, we begin a beta series where we incrementally implement the new API.

How we teach this

Obviously large amounts of changes to the docs will be required. Possibly provide v1 docs concurrently so users who have yet to migrate can switch over?

Alternatives

• Wait for a way to incrementally deprecate current behavior to move into upstream ember, then wait for enough of the community to use it to warrant making it the minimum supported version.
• Of course, we could do nothing. (not desirable)

[cibernox]

This is on the roadmap, indeed. I even bikeshedded a tentative API.

{{#basic-power-select as |select|}}
  {{#select.trigger as |selected|}}
    {{! or use a blockless "select.trigger" if you are ok with the default }}
  {{/select.trigger}}
  {{#select.content}}
    {{select.before-options}}
    {{#select.options as |opt|}}
      foobar {{opt}}
    {{/select.options}}
    {{my-custom-component-not-select-related selected=select.selected count=select.options.length}}
  {{/select.content}}
{{/basic-power-select}}

The reason to suggest a new component is that I’d like to maintain the current API as a layer on top, for backward-compatibility reasons and because this extended API is rather unconvenient for 95% of the cases.

[cibernox]

I’m actually working on it! There’s an open PR in ember basic dropdown for that. After that is merged I’ll update EPS next