ember-power-select
ember-power-select copied to clipboard
cibernox
[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)
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.
Yeah that was something I was thinking about last night after I wrote this. I wasn't too sure if I wanted to make a new component, but I agree that adding basic-power-select is the direction this should go. It would be relatively easy to rebuild power-select and power-select-multiple on top of this, keeping backwards compat as we go.
This would be extremelly helpful for ember-paper and probably other people making some advanced customisations on top of eps.
It would be. Unfortunately I'm not working with ember so much at the moment, so my motivation to work on this is limited. @miguelcobain I would welcome you taking over the work on this. #923 probably can't be rebased at this point (way too many conflicts), but the actual implementation of it wasn't too involved, thanks to @cibernox's excellent test suite.
If you want to discuss, feel free to dm me on the ember slack (I'm nlincoln).
FWIW, the reason why I'm not pursuing this myself is because this being an aggresive refactor and with angle bracket components around the corner I'd like to do both at once.
@cibernox would this work for addons? https://github.com/rwjblue/ember-angle-bracket-invocation-polyfill
I don't see why it shouldn't.
With angle bracket components around the corner I'd like to do both at once.
Poke @cibernox. It's time ! 🎉
https://www.emberjs.com/blog/2018/10/07/ember-3-4-released.html#toc_new-features-2
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
@cibernox Are there any active plans for this still, or an open PR that we can contribute to?
