HTML-first .gc syntax

[gossi]

I was trying a PoC for what's been discussed in #20

Mainly to get an experience for the haptics of this syntax.

Spoiler Alert: It's ❤️❤️❤️

---

The code itself is regexforcing my way through it, then offload it to the available hbs literal. As a matter of that, this isn't even working properly. I basically failed when import the {{on}} modifier and tried to use it. Then I learned, I have no clue how strict template syntax works, what functions are available and what their signatures are. Also I've seen, you offloaded lots of the work to glimmer itself.

I would like to hear what's the proper way of moving this forward.

[NullVoxPopuli]

Thanks for doing this! Even though I don't personally like this syntax / approach to template imports (and the tradeoffs it makes), the PR's existence for how to add your own transform will be fantastic for enabling other people to try out other kinds of transforms!!!! ❤️ 🎉

[pzuraq]

The {{on}} modifier may have extra issues until 3.27, due to the modules API transform (which has mega bad ordering issues with all the other babel plugins 🙃 )

I would think this strategy would work, since the JS preprocessor should run before Babel. For the regex portion, you're going to want to build a better parser eventually. Here are a couple example failure cases:

<script>
  let bar = "</script>";

  // </script>
</script>

In general when you have arbitrary code like this, you need a stack based parser (also known I think as a shift-reduce parser). This is what we implemented for .gjs, and the two main types of places where these re-entry issues can occur are comments and strings.

Also, it seems like you may not be adding the import statement? That's definitely necessary, import { hbs } from 'ember-template-imports';. Ideally you would also use preprocessTemplate rather than using one of the other transforms, but that's a lot of work and I think this is fine for bootstrapping/experimenting, we could always do it properly if the format became more mainstream.

Last note, this PR should include documentation that matches the level of detail of the existing proposals. This could also help other folks who want to contribute understand the semantics you're after, so you can get more help on this PR.

[NullVoxPopuli]

In case other folks don't know why I'm against this syntax, it's because:

• there is no way to define multiple components in one file (that I can see being done in a consistent way)
• it breaks my understanding of scope / doesn't follow JS scoping rules where outside the <script> tag, the template stuff has access to the things within the <script> tag.
  • especially since a this is still possible, yet the template is not only outside the scope of the class, but also outside the scope of <script>

This is where I think the <template> approach shines, because you treat the scope like any other JS function

traditionally things in <script> tags are in the global scope -- except for type="module", but then everything defined in there is fully contained within -- which maybe would lead to:

<script type="module" lang="gjs">
  export default class Foo extends Component {
    name = "me";
    
    <template>
      hello {{this.name}}!
    </template>
  }
</script>

anything out here should not have access to anything in the `script`, because it is of type "module"

I may be in a minority, and that's fine, but I think at some point, we should make a comparison table, where we go through different features we all want and say if the syntax supports them, how they look, etc

[chriskrycho]

@gossi this is still welcome if you want to land it, but I’m checking in given that emberjs/rfcs#779 landed with an official direction – happy to leave it open for you to continue building this variant if you like, or to close it if you are no longer interested!

[gossi]

As much as I still prefer native html ;) this was overall a ~30-min experiment. So this can be closed.