The Road to Stable

[chriskrycho]

The Road to Stable

Background

RFC #0779: First-Class Component Templates picked one of the formats from this repo as the the ability for Ember (and Glimmer) developers to write components with template tags embedded in their JS, like so:

import Component from '@glimmer/component';

const Button = <template>
  <button
    type='button'
    class="my-button"
    {{on "click" @onClick}}
  >
    {{@label}}
  </button>
</template>

export default class Player extends Component {
  @tracked isPlaying = false;

  play = () => (this.isPlaying = true);
  pause = () => (this.isPlaying = false);

  <template>
    <audio src={{@srcUrl}} {{playWhen this.isPlaying}} />

    <Button @label="Play" @onClick={{this.play}} />
    <Button @label="Pause" @onClick={{this.pause}} />
  </template>
}

This is not only a general win for ease of working with Ember: it is also a key part of our TypeScript story, because it makes things like go-to-definition, documentation hovers, autocomplete, auto-import, etc. all much easier to manage. So: what do we need to do to finish unblocking its adoption?

Work to be done

There are only three fundamental blockers to adoption:¹

• Prettier support.
• ESLint support.
• ember-template-lint support.

Prettier support

Thanks to @wondersloth at LinkedIn, there is an existing Prettier plugin for one of the alternatives to the final first-class component templates design, which used hbs tags (like you see in tests), as used by Play/Glimmer. You can find that here. In this case, the work to be done is building on that and using the preprocessor from ember-template-imports to get the contents of the template, with the existing indentation, run Prettier on that, apply appropriate indentation, and replace it in the <template> tag.

ESLint support

This is really two things:

1. Help land this PR by @NullVoxPopuli (who would welcome the help)! It may be helpful to compare with the eslint plugin for GlimmerX, which works with hbs tagged template literals and would need similar updates as the Prettier plugin, but may be useful input.

2. See the next section about ember-template-lint: we want to basically make ember-template-lint an embedded ESLint reporter.

ember-template-lint support

For ember-template-lint, we need to integrate it with ESLint, so that from the end user’s perspective, they just have one linter giving them feedback on their.

There is a branch of this work started here, but again, @NullVoxPopuli does not currently have time to finish it and would love help!

Footnotes

1. Beyond this, the specification working group is also working on nailing down what we want the exact design constraints for <template> tags (as well as any other future tags in the same direction), which we expect to publish as and we take that design to be a blocker for making it the recommended and default experience for Ember developers, but not a blocker for folks adopting and using it. ↩

[NullVoxPopuli]

compare with the eslint plugin for GlimmerX, which works with hbs tagged template literals

To catch folks up,
I started with this, and didn't find it all that useful.

In the eslint plugin, the current approach is:

1. preprocessor (emit strict mode raw format to eslint, so native eslint can run normally)
2. postprocessor (process the messages from eslint running normally to map back to the line/column in the original source)

pre/post processors run "automatically" based on file extension when a plugin provides a file extension<->processor mapping
(more information in the already linked PRs)

Thanks, @chriskrycho !!

[chriskrycho]

Thanks for the clarification – that’s super helpful!

[chriskrycho]

• Thanks to @ventuno, we have ember-template-lint support!
• Thanks to @gitKrystan, we have Prettier support!
• Thanks to @NullVoxPopuli and @nlfurniss, we have ESLint support!

Thanks as well to @wycats, @bmish, and @rwjblue for helping get those various efforts across the line.

I’ll make sure we follow up on this in one of the next few Framework Core team meetings—this is amazing progress, and represents a huge step toward stabilizing this and eventually making it the recommended way of writing Ember templates.

(Keep your eyes open for code-mods coming soon™!)

[chriskrycho]

This is done. We will keep polishing, but all the hard blockers are wrapped; now we need to (a) do that polish work, (b) write an RFC for route templates, and (c) start the path to documenting it as a supported path (though not yet a recommended one).