Error parsing {token}s

[snuggs]

Currently if a {token} is found within a component we search for a property of the same name on the claas definition. However if the token is not available we return undefined this is printing to the DOM. We can do the following:

1. silently fail (empty string. possibly confusing)
2. keep undefined as a hed nod to change.
3. leave the token in place. (which in my case i need because i want {fields} to actually display not get parsed.

This brings up another question. Do we have to escape? {{token}} would render {token} << TO BE CLEAR I DON'T LIKE THAT. I just want to know the best way to "Escape" a token.

Please advise

[brandondees]

interesting options.... have you looked at how say handlebars does this? might be safest to stick with something familiar. on the other hand, i kind of find interesting the possibility of having the option as a developer. In some cases, I may want to opt out of handlebars {} syntax altogether and treat it as literal content characters. in other cases i may want the interpolation always, even when undefined and maybe still in other cases it might be preferable to be able to mix and match, having some {} escaped as output, others interpolated with property values, others failing over to a safe default like empty string, etc.

does \{ backslash escaping make any sense? that'd probably be the most obvious/familiar for most devs, I should think.

as for failure defaults, i'd say undefined by default helps me find problems with my code and fix them. if i want to explicitly use an empty string or a safe default value, i can either design the property getter to work that way, or maybe {prop || 'default'} i would presume, which isn't horribly verbose and should get the job done (i'm assuming).

[snuggs]

{prop || 'default'} i would presume, which isn't horribly verbose and should get the job done (i'm assuming). - @brandondees

VERY modern JS pattern right there my man. Ancient ruby pattern tho. #ISeeWhatYouDidThere #NowYouGetIt

However you'd do that within the computed getter property instead. Remember ZERO logic views ;-). Tokens are merely symbolic references. At least that's what Webster's says hehe

<foo-bar> {message} </foo-bar>

<script>
Element `foo-bar`

(class extends HTMLElement {
  get message ()
    { return undefined || 'default message' }
})

</script>

That would be ok @brandondees however the undefined is coming due to there not even being the property on the class. That's what is "bug" like Imagine if get message () didn't exist on previous class. Please advise.

CATAT /cc @tmornini @kurtcagle @rianby64

[tmornini]

I'd suggest HTML escaping the {token} if there's no match.

[brandondees]

great idea @tmornini

@snuggs so then yeah, let it fail to undefined, or something configurable as the default failure value if there's a way to hook that in.

[brandondees]

or @tmornini 's suggestion, which probably makes the most sense

[snuggs]

@brandondees @tmornini @RobertChristopher @btakita formal discussion over @ WHATWG

https://github.com/whatwg/html/issues/4219

[snuggs]

I actually noticed a bug in our code that breaks parser when value is undefined property. Will write test and close out this issue.

[antman3351]

Hello, this isn't really an issue so as it's related to the token parsing I'll add it here 🙃. I've just started looking at Snuggsi to use in an existing PHP application. Unfortunately the { } conflicts with the PHP template engine, the engine can be told to ignore parts of the HTML but it would be simpler and clearer if I could set the opening and closing token to a different character(s), would this be possible?

Thanks!

[rianby64]

This question leads to the possibility to customize the token... and, by default it could be {}. However, what about if two instances of the framework are loaded?

And what about the compatibility with the standard?