<angle-bracket> components

[buschtoens]

What are the plans on supporting <angle-bracket> components?

The old {{mustache-component}} syntax will not be abandoned before 3.0, as the new syntax won't land until 2.1. Therefore Emblem can't just make the new syntax the default one.

We need a way to indicate that the new syntax should be used. Alternatively we could upgrade the major version number and do the opposite by using the new <angle-bracket> syntax by default, while keeping the old {{mustache-component}} syntax accessible through said indicator.

Obviously, this issue doesn't need to be addressed until Ember 2.0 comes out, but I'm curious for your ideas.

Personally, I'd prefer the latter option and bump the major version number, so the new syntax can be used by default without additional indicators, while still enabling users to use legacy components, as <angle-bracket> components are the way to go.

[thec0keman]

One thought I had was to use = some-component for mustache and some-component for angle bracket, but since both forms of syntax currently work for mustache there definitely would need to be a version bump.

[petejkim]

One thought I had was to use = some-component for mustache and some-component for angle bracket,

No, that would break existing apps... I think something like the following would be better.

div
  <some-component> foo=bar baz=qux

or

div
  < some-component foo=bar baz=qux

[thec0keman]

@petejkim definitely agree that breaking apps would be bad, so a change like that would require some communication.

At the same time, what I like about that approach is that the long term goal (I believe) is that all or most components are angle brackets, so something like adding a new prefix such as < ultimately makes the syntax less clear.

Also, perhaps this is just my preference, but I tend to think of emblem lines without an = as regular HTML tags, whereas lines with an = are handlebars. If that is the intended mindset for the syntax, then it would make a lot of sense to assume a component name without a = would be a angle component.

[buschtoens]

Also, perhaps this is just my preference, but I tend to think of emblem lines without an = as regular HTML tags, whereas lines with an = are handlebars. If that is the intended mindset for the syntax, then it would make a lot of sense to assume a component name without a = would be a angle component.

Really agree with this. :+1:

[shaunc]

@thec0keman, @buschtoens -- +1

Perhaps as a transition, a comment at top for new syntax:

/ default-component-angle-bracket

Then after transition period (and release of new major version)

/ default-component-moustache

would be required to get old semantics by default.

[petejkim]

@shaunc that makes sense

[shaunc]

hmm... otoh -- can emblem access ember feature flags? Perhaps a more "ember-compliant" way to implement would be to use a feature flag.

Another concern when moving to support angle bracket components: How to support non-top-level components?

Ember supports handlebars reference to a component in components/foo/bar/my-component via

<foo.bar.my-component>

But I assume

foo.bar.my-component

or

= foo.bar.my-component

are problematic in emblem. Emblem could use a backslash as css does:

foo\.bar\.my-component

But prettier would be simply to support forward slashes:

foo/bar/my-component

or

= foo/bar/my-component

Would that work? (EDIT oh -- I guess this is a question with current non-top-level components as well...)

[thec0keman]

I'm not sure what all would be involved for feature flags (perhaps that being something ember-cli-emblem would handle?)

The / namespace issue is one that I believe is currently unresolved for Ember.

[shaunc]

The current ember canary recognizes ".". It would seem to me that "/" isn't valid html, which is the problem in handlebars, but emblem needn't be concerned with that -- "/" is natural to write, easy to parse, and can be translated to (whatever), as both "." and ":" are problematic for emblem.

[buschtoens]

:+1: for using / instead of . or \..

[thec0keman]

So is the thought that / in component names should map to whatever Ember / Ember-CLI lands on?

i.e.:

inputs/my-component value=foo   =>   <inputs.my-component value={{foo}}/>

[buschtoens]

I'd say so. It maps to the directory strcuture / paths 1:1.

[shaunc]

@thec0kemam -- exactly. As current canary uses ".", that would be a good first target.

[kjhangiani]

I actually much prefer the explicit

< some/component-name 

to no prefix. It makes the parsing easier, it is obvious when scanning through files quickly, makes it easier to grep, and it is called "angle bracket" syntax after all.

Personally, I never call components without the = prefix either, it's a bit vague, especially in a multi dev environment. It is also confusing to new developers we hire, when it is very obvious with the prefix.

My preference would be

< some/component-name 

for angle brackets and

= some/component-name

for legacy components (so as not to break existing apps). I feel that the non-prefixed version should be used only for helpers... however that is probably not possible as currently components can be called that way as well. My opinion is that support for either legacy or angle components without a prefix should eventually be deprecated - it's less confusing when there's only one way to call them.

As projects continue to evolve and angle brackets become the standard, the support for legacy components without an = can just remain an undocumented shortcut... but I would definitely prefer that the only way to use angle bracket components be with a prefix, rather than causing a confusing syntax change where the unprefixed version can refer to a helper, legacy component, or angle bracket component based on the version of emblem.

[machty]

It was probably a mistake to create a white list of known HTML attributes that determines whether foo is interpreted as {{foo}} or <foo>, because it's a bit confusing and not exactly future proof (Glimmer angle bracket components as a primary example, but also new additions to HTML elements, etc).

Emblem isn't 1.0 yet so technically the rules for semantic versioning don't apply, but since it's been around for a few years, it's fair to say it's post 1.0 in spirit, so I'm pretty hesitant to "fix" the white-listing mistake if there's any other way around it, since it'll break everyone's templates.

I haven't seen anyone mention it in this thread, but as a reminder, you can prefix with % to force interpretation as an HTML element, e.g. %foo produces <foo>. Angle-bracket Glimmer components are being designed such that the way you bind attributes, pass in properties, etc., is the same syntax as what how you'd do such things with a normal HTML component, e.g. in Glimmer you can do <div class={{foo}}> or <my-component items={{things}}>.

Emblem already specifies how to pass in attributes to HTML elements, e.g. %div class="wat" (the % is optional since div is on the whitelist) so maybe going forward the safest thing to do is stick with % as the way to prefix angle-bracket components.

%my-component items=things

produces

<my-component item={{things}}></my-component>

This I believe is working syntax today. We'll probably need to add things like block syntax for angle bracket components and maybe some other things that come along, but am I missing anything fundamental about % limitations?

Separately, we can decide:

1. Should we remove the white-list and treat ALL un-prefixed identifiers as angle-brackets, and if so, when? (This would break older Emblem templates)
2. Perhaps as a midterm solution we can treat all unprefixed identifiers with dashes (a requirement for Glimmer components is that there is a dash in the name) as angle brackets.

How's that all sound?

[nybblr]

The % route is :+1: to me. I personally prefer the angle bracket syntax, but since this is transitional syntax anyway it seems unimportant.

[brandensilva]

Yeah I'm fine with % as a temp solution as well. If its as simple as removing all %'s in a template later down the road to conform with your 1 or 2 machty that will be simple clean up work that can be done fairly quickly.

[thec0keman]

I'd like to start working on an implementation for angle bracket components.

Initially my goal is:

• [x] make sure all mustache features (like block syntax) work for % elements
• [x] add tests for the basics of angle bracket components
• [x] add deprecation notice for any existing statements that:
  • are currently interpreted as mustache
  • are not prefixed with =
  • would be a valid component name

Does this sound like a good path forward?

[thec0keman]

Here is my WIP branch. I think the basics are all in place. I know there are some outstanding issues with documentation for Ember, so I suspect that when that is finalized some tweaks may be necessary.

The biggest question I have right now is how much refactoring should be expected when transitioning from explicit mustache components to glimmer components. Glimmer components act like normal DOM elements in Ember, so you have to change your syntax for subexpressions:

= my-component model=model isOpen=(if equal(currentOpen 'foo') 'open' 'closed') changeAction=(action 'thingChanged' model) do |component|
  = component.name

would now be:

% my-component model=model isOpen={ if equal(currentOpen 'foo') 'open' 'closed' } changeAction={ action 'thingChanged' model } do |component|
  = component.name

I think since there is a substantive change on Ember's side it is worth requiring a change in your emblem template. Or should we instead support the exact same syntax as mustache components?

[shelby-carter]

The new syntax is mentioned here http://emblemjs.com/idioms/ but deprecated version still persists here http://emblemjs.com/syntax/ which is confusing and led me to this ticket. Also posted about the issue here #286

[kjhangiani]

What's the latest status on this? Are angle bracket components supported in the latest emblem? We've finally updated to ember 1.13, and are looking to migrate to glimmer components, but can't find any updates on the latest syntax.

[thec0keman]

Emblem does have some preliminary support, however we are still waiting on this feature to land in Ember before that is finalized.