Skip to content
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

Merged
merged 3 commits into from
May 1, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 17 additions & 2 deletions text/0389-dynamic-tag-names.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Member Author

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.

* When passed `null` or `undefined`, it will return `null`.
Copy link
Member Author

@chancancode chancancode May 1, 2020

Choose a reason for hiding this comment

The 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 (component) helper's behavior with this, and acknowledge that there are useful patterns arising from this. Note that when null is "invoked" it's a no-op, which is why this works for contextual components in general.

* 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>
Copy link
Member Author

Choose a reason for hiding this comment

The 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.
Expand Down