Closed stefanomondino closed 2 years ago
Hm, why not to make this a configurable error if default behaviour to render nothing is not desirable? There is a good error support already in Stencil that shouldn't require any additional preprocessing on the client side.
My point was to perform some kind of analysis on the template itself before it's actually rendered. Basically I'm developing a CLI that can display all needed variables with some kind of --help
command, I can try to see if I can handle this with errors.
I've tried my own fork (with public tokens) in my use case and it works but doesn't handle well filters:
{{ name | uppercase }}
has a variable name of name | uppercase
and not name
as I expected, probably I'm missing some key concepts in the whole process :)
In some cases it would be useful to analyze a template and report back all occurences of variables to do some client-side validation for provided context before actual render happens. example:
template string:
hello my name is {{ name }}
provided context:["something": "someValue"]
In my scenario I can give feedback to users before rendering happens ("warning!
name
variable is missing from your context but is used in templates", something like that), but I don't know how to retrieve template's variables, since thetokens
seems to be internal and not public.