sl-ember-components
sl-ember-components copied to clipboard
softlayer
Define capabilities and API for sl-alert
This issue is where discussion about all of the things we want to change about the sl-alert component should occur and the final definition of its capabilities and API are defined. As these items are discussed and vetted, issues will be created to work any individual tasks, with this issue serving as the overall source of progress.
To indicate that a capability of the component needs to be verified, add a comment with **VERIFY** as the first line.
To propose a change to the component, add a comment with **PROPOSAL** as the first line.
To indicate that something needs to be researched, add a comment with **RESEARCH** as the first line.
As you are leaving comments regarding any of these VERIFY, PROPOSAL, or RESEARCH comments, link back to the comments link in your own so that the conversation can be more easily followed (in absence of threaded conversation support in Github). This should be done on the first line of the comment via **RE: <url>**
Capabilities and API
- [x] Support all Twitter Bootstrap capabilities (ARIA is addressed separately)
- [x] Supporting binding an action to the dismissal of the alert
- [ ] ARIA support
Tasks Adding them here until issues are created
- Update documentation for each change
- Complete review of documentation against capabilities
- Add demo of
.alert-linkusage - Demo every supported Bootstrap capability
Issues tracking these efforts
https://github.com/softlayer/sl-ember-components/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22v0.13.0+%28Final+push+for+a+1.0.0+release%29%22+label%3Asl-alert
VERIFY
http://getbootstrap.com/components/#alerts-links
Links in alerts Use the
.alert-linkutility class to quickly provide matching colored links within any alert.
Verify that this aligns with Bootstrap's capabilities. Don't know why it wouldn't but better to be certain.
PROPOSAL
Support the setting of the message via a property passed to/on the component.
Pros
- Most flexible
Cons
- Potential for mis-use by consumer, passing in a built HTML string to hold links, lots of content, etc.
If not going to support, how should the component react when someone attempts to use it in this manner? Does it currently fail gracefully? Is the way that it currently fails desirable? Do we want/are we able to restrict usage of the component in this manner via coding?
PROPOSAL
Support timeout value to automatically close alert after specified time.
PROPOSAL
Remove tooltip support.
What benefit is gained by its use?
If decided to remove it the sl-tooltip-enabled mixin can be removed from use.
If decided to remove it https://github.com/softlayer/sl-ember-components/issues/774 can be closed.
If keep, add example to the demo app. If remove, remove reference to mixin from demo app docs.
RESEARCH
The passing of an unsupported theme will still render the component with provided values, etc that a user can "extend" this component to support their own styling without having to extend the component just to redefine the theme constant. @SpikedKira knows more about this as well.