google / closure-templates

A client- and server-side templating system that helps you dynamically build reusable HTML and UI elements

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Recent "special tokens not allowed inside html tags" change breaks existing templates

sgammon opened this issue · comments

Hey there esteemed closure templates authors,

A recent change on this line:

errorReporter.report(node.getSourceLocation(), SPECIAL_TOKEN_NOT_ALLOWED_WITHIN_HTML_TAG);

Throws an error for any case involving a "special token" inside an HTML tag. however, that eliminates previously-valid syntax and that change is preventing us from upgrading our Closure Templates compiler.

there is a valid use case for spaces within HTML tags, for instance, declaring a space explicitly to separate conditional attributes:

{template .script}
  {@param script: trusted_resource_uri}  /** JavaScript asset that we wish to create a link for. */
  {@param? id: string}  /** Optional ID at which to attach the script in the DOM. */
  {@param? module: bool}  /** Whether this should be a module or not. */
  {@param? nomodule: bool}  /** whether this should be a `nomodule`-flagged script or not. */
  {@param? async: bool}  /** Whether we should add the async flag. */
  {@param? defer: bool}  /** Whether we should add the defer flag. */
  {@param? integrity: string}  /** Integrity fingerprint to apply. */
  {@param? crossorigin: string} /** Cross-origin value to use. */

  <script type="text/javascript"
          src="{$script}"
          {if isNonnull($id)}{sp}id="{$id}" {/if}
          {if isNonnull($module) and $module}
              {sp}module
          {else}
              {if isNonnull($nomodule) and $nomodule}{sp}nomodule{/if}
          {/if}
          {if isNonnull($async) and $async}{sp}async{/if}
          {if isNonnull($defer) and $defer}{sp}defer{/if}
          {if isNonnull($integrity)}{sp}integrity="{$integrity}"{/if}
          {if isNonnull($crossorigin)}crossorigin="{$crossorigin}"{/if}></script>
{/template}

arguably this can be accomplished for new code with type=attributes, but this breaks old code in a significant way, and changes the syntax rules of the language. is this a deliberate change, that we cannot come back from, such that we must update old (but previously valid) Soy code to adopt new compiler versions?

A few more details:

The command characters, like {sp}, are meant for printing text, so within an html tag they don’t really make sense.

In most cases, it looks like you're adding an {sp} at the beginning or end of a line, but the soy html parser handles newlines between attributes and tag names as a separator, and already parses this correctly. In cases like this, you can just delete the {sp}.

Does this make sense?

@emspishak @iteriani thank you for the quick response here. yes, that makes sense, but we occasionally get double-spaces in the output between attributes. would that, then, be considered a bug on its own, alleviating the need to use {sp} for manual control? that's the goal of the above code's use of those symbols

hey all-
just wanted to follow up that i believe this to be fixed, and we've repaired our code to remove the offending {sp}. thank you for your help!

Really sorry about this. We'll be releasing a formatter/code fixer for similar issues soon!