marko: Error for unrecognized tags

For the record, I now believe this was the right choice. After upgrading to rc.13, marko immediately informed me about two invalid tags that I forgot to change during a rename! 😄

Related to this, Patrick and I are looking at creating a “standard” of sort that could be adopted by web component libraries to make their custom tags visible to tooling.

Marko’s autocomplete in Atom was originally forked from autocomplete-html and it was extended to autocomplete not just HTML elements, but also Marko custom tags that were discovered through directory scanning and marko.json files.

We’re thinking that we could submit a PR back to the original package that would support discovering an html-elements.json in project, but also at the root of any packages that the project depends on. This process and the format of the json file would be similar to the Marko process and format, which has worked well for us.

This would allow a web component package to simply add this file (which could be generated) and autocomplete would be made available to the autocomplete-html package (which has over 200k downloads). There’s an immediate benefit to doing so, but future tools would also be able to make use of this information.

And of course so would Marko. If we could get the web community to adopt this, it would mean you might never (or rather, rarely) have to add definitions/exceptions for third-party custom element tags on your own.

That’s definitely a big “IF”, but between reaching out to other developers, possibly making some PRs to popular libraries and the fact that there’s benefit to the libraries and end users (it’s not purely driven by a need of Marko) it could very well work.

@mindeavor I’m not sure what that has to do with throwing errors for invalid tag names, and those are all just different examples of the same thing - plain text as a root element.

@patrick-steele-idem On further thought, I think I would agree with throwing errors by default, as long as it’s easy to disable and clearly documented.

If concise were disabled, @ramses0’s examples of surprises would no longer be surprising; they would do what you’d expect in any HTML document.

this is
for
you
<h1>Test</h1>
var not_a_var = "this is just text, just like HTML"

for this is text as well!

${ "interpolated" + "value" }
$ console.log("this is JS code. Iffy, but acceptable")

I am plain text
<my-custom-element>
  No problems here
</my-custom-element>

When building a complex project you will often need to rename a UI component. It would be really nice if you could recompile all of your templates to figure out exactly which UI components broke as a result of the name change. I’m strongly in favor of throwing an error when the Marko detects an unrecognized tag as long as we get the error message perfect (the developer should know exactly what to do to register the tag and it should be super simple).

I’m not convinced this is the right idea, but we could also only have the warning for tags names without dashes in their name. Custom Elements require hyphens in their names so we wouldn’t catch those tags with this rule.

I think @jsumners has a point. It might only make sense to throw an error on a would-be concise tag.

My vote is for disabling concise mode by default (with exceptions for class, import, and export), and making it easy to enable it via a flag. That should solve most all confusion around syntax.

An error should not be thrown – https://html.spec.whatwg.org/multipage/scripting.html#custom-elements