-
-
Notifications
You must be signed in to change notification settings - Fork 407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise RFC #389 with details about its argument #620
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -43,14 +43,29 @@ With the `element` helper proposed in this RFC, this can be accomplished with so | |
|
||
## Detailed design | ||
|
||
We propose to add a new `element` helper that takes a tag name and generates a contextual component that, when invoked, renders the selected element. | ||
We propose to add a new `element` helper that takes a single positional argument. | ||
|
||
* When passed a non-empty string it generates a contextual component that, when invoked, renders an element with the same tag name as the passed string, along with the passed attributes (if any), modifiers (if any) and yields to given block (if any). | ||
* When passed an empty string, it generates a contextual compoment that, when invoked, yields to the given block without wrapping it an element and ignores any passed modifiers and attributes. | ||
* When passed `null` or `undefined`, it will return `null`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The proof-of-concept addon currently throws here. The motivation for this is to mostly match the |
||
* When passed any other values (e.g. a boolean or a number), it will result in a development mode assertion. | ||
|
||
Example: | ||
|
||
```hbs | ||
{{#let (element @htmlTag) as |Tag|}} | ||
<Tag>...</Tag> | ||
<Tag class="my-element" {{on "click" this.tagClicked}}>Hello</Tag> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm aware this is probably not the most sensible (and accessible) example, but it's really just the simplest example to show that "modifiers get passed through" without too much bloat. Happy to change it to something else though. |
||
{{/let}} | ||
|
||
{{!-- when @htmlTag="button" --}} | ||
<button class="my-element" {{on "click" this.tagClicked}}>Hello</button> | ||
|
||
{{!-- when @htmlTag="" --}} | ||
Hello | ||
|
||
{{!-- when @htmlTag=null or @htmlTag=undefined, it renders nothing --}} | ||
|
||
{{!-- when @htmlTag=true or @htmlTag=1, it throws in development mode --}} | ||
``` | ||
|
||
Unlike ids, classes or other attributes, the tag name of DOM element cannot be changed in runtime. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Despite unspecified, this is how the proof-of-concept addon already behaves today. It's largely just a happy accident due to implementation uses an
Ember.Component
under-the-hood, but there are tests for this behavior and seems like a useful feature in general.