Skip to content

Make templateExportDefault default to trueΒ #352

@bendemboski

Description

@bendemboski

I don't think making removing export defaults the out-of-box behavior is the right way to go. In gjs files where there are no imports or other code, I think omitting the export default does make sense so it looks like "just HTML":

<template>
  Hello world
</template>

That's nice and clean! However, if there is other code in the file, especially other exports, I think it's confusing:

import { State } from '../utils/state.js';

export function createStateForComponent(data) {
  return new State(data, 'component1');
}

<template>
  {{@state.output}}
</template>

Now we have a mix of standard ES module syntax and...weird magic where there's no default export but somehow there is, and readers of the file just have to know that <template> tags are special-cased.

Moreover, it's pretty common (at least for me) to implement "private" components in gjs/gts files, e.g.

const Message = <template>
  <div>
    <span class="bold">{{@label}}:</span>
    {{@text}}
  </div>
</template>

<template>
  {{#each @messages as |msg|}}
    <Message @label={{msg.label}} @text={{msg.text}} />
  {{/each}}
</template>

So now readers have to know that <template> tags that are assigned to variables don't get exported, but the ones that aren't become the default export. Oh, and if you realize that you need a component class wrapping your template you have to add the export default. Oh, and if you have two "bare" <template> tags in a single file, it's an error even though it's not really evident why.

One of my favorite things about template tags is that template-only components become "regular values" like anything else that can be assigned to variables, passed to functions, etc etc. Once users adopt that mental model, I think it really starts unlocking the potential of low-overhead component composition, code organization, etc that template tags provide. So I really think that for consistency, clarity, and learning, our default happy-path should be that they follow ES module semantics as well and don't represent an exception.

If folks agree that this makes sense, I'm happy to open a PR.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions