-
-
Notifications
You must be signed in to change notification settings - Fork 81
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
Allow component tags to take chained classes and id #228
Comments
This has been on my mind lately as well. Would love this. Great issue write-up |
👍 This is a cool idea |
How would this work with contextual components? A yielded hash that contains components are accessed via the . operator. For example
Would that cause issues confusing the contextual component with a class? I do wish this existed though, the ergonomics would be great. The contextual case is where it might get tricky. |
@kjhangiani i'm not sure how the underlying parsing works or might work for your example, but from a dev experience i imagine that a harder distinction would need to be drawn so that angle brackets are default for this type
where I dunno though, just brainstorming |
While doing some work on the docs I discovered this already exists!
There are a couple of limitations:
|
TL;DR:
This is a feature suggestion: Allow this syntax
my-component.class#id
A vanilla html tag can take classes and id with this syntax
div.class#id
But components, which require a
-
in the "custom tag" name can'tmy-component.class#id
throws an error.
Currently, you have to / can do something like this
my-component class="class" id="id"
What would be the challenges, conflicts, or issues around allowing the more intuitive, uniform syntax?
Currently, this (a component with a class, id, an action string to be sent to the heirarchy, and a variable passed in):
theory-button class="clickable" id="clickable" isGeneral=isGeneral action="toggleGeneral"
results in:
<div id="clickable" class="ember-view clickable"></div>
And this (a vanilla HTML tag with the same additions):
div class="clickable" id="clickable" isGeneral=isGeneral action="toggleGeneral"
results in:
<div id="clickable" action="toggleGeneral" class="clickable" isgeneral="false"></div>
In short, the same syntax behaves vastly differently when the tag is a component, rather than a vanilla HTML tag. As a component, none of the "attribute definition" shows up in the rendered HTML, unles made to do so under the hood. As a vanilla HTML tag, "attribute definition" is treated as HTML attributes, and thus shows up in the rendered HTML. And that's all fine and understandable, since we pass things into components when using ember, while vanilla HTML elements do not/cannot take any parameters or attributes.
But this, to my understanding, shouldn't necessitate of conflict with the convenient
component-or-element.class#id
style of syntax.One reason I can think of for disallowing the convenient syntax on components would be to allow for component names with
.
or#
as the tag name. but including those characters in component names seems to be quite bad naming practice anyway.Any "attribute definitions" such as
action="myAction"
orrandomString=someControllerVariable
following a component call is detected, and has code to process it under the hood anyway (that may be an ember thing rather than an emblem or hbs thing). So wouldn't implementing a simple string parse operation to detect any.
or#
characters, if any, after a component call work just fine to enable the convenient syntax, and eliminate having to do the inconsistent and more verboseclass="my-class"
?The text was updated successfully, but these errors were encountered: