public class TranslateToJsExprVisitor
extends AbstractReturningExprNodeVisitor<JsExpr>

Visitor for translating a Soy expression (in the form of an ExprNode) into an equivalent JS expression.

Important: Do not use outside of Soy code (treat as superpackage-private).

---

Types and Dependencies

Types are used to allow reflective access to protobuf values even after JSCompiler has rewritten field names.

For example, one might normally access field foo on a protocol buffer by calling

my_pb.getFoo()

A Soy author can access the same by writing

{$my_pb.foo}

But the relationship between "foo" and "getFoo" is not preserved by JSCompiler's renamer.

To avoid adding many spurious dependencies on all protocol buffers compiled with a Soy template, we make type-unsound (see CAVEAT below) assumptions:

• That the top-level inputs, opt_data and opt_ijData, do not need conversion.
• That we can enumerate the concrete types of a container when the default field lookup strategy would fail. For example, if an instance of my.Proto can be passed to the param $my_pb, then $my_pb's static type is a super-type of my.Proto.
• That the template contains enough information to determine types that need to be converted.
  Pluggable SoyTypeRegistries allow recognizing input coercion, for example between goog.html.type.SafeHtml and Soy's html string sub-type.
  When the converted type is a protocol-buffer type, we assume that the expression to be converted can be fully-typed by expressionTypesVisitor.

CAVEAT: These assumptions are unsound, but necessary to be able to deploy JavaScript binaries of acceptable size.

Type-failures are correctness issues but do not lead to increased exposure to XSS or otherwise compromise security or privacy since a failure to unpack a type leads to a value that coerces to a trivial value like undefined or "[Object]".