Go library support for Google Closure templates (Soy)
|
2 years ago | |
---|---|---|
generator | 2 years ago | |
test | 2 years ago | |
.gitignore | 3 years ago | |
AUTHORS | 3 years ago | |
BUILD | 2 years ago | |
CONTRIBUTORS | 3 years ago | |
LICENSE | 3 years ago | |
README.md | 3 years ago | |
WORKSPACE | 2 years ago | |
defs.bzl | 2 years ago | |
soyotto.go | 3 years ago | |
typedarray.js | 3 years ago |
SoyOtto provides Go support for Google Closure templates. Most users should prefer robfig/soy as it is written in pure Go.
SoyOtto invokes the JavaScript version of Closure templates from Go using robertkrimen/otto -- a pure Go JavaScript interpreter. This design is inherently slow but provides first class support for all Soy language features (some of which at not supported by robfig/soy).
To provide strong compile time type checking for template parameters, soyotto
generates *.go
and *.js
binding files. These binding files also provide
transparent proto.Marshal()
-> pbType.deserializeBinary()
calls to
seamlessly pass template parameters between Go and JS native types. This design
comes at a significant performance penalty. For each template invocation, the
following steps are required:
<TmplName>()
or Call<TmplName>()
)proto.Marshal()
parameters (as necessary)vm.Copy()
the otto vmsoyotto.<TmplName>()
)<protoType>.deserializeBinary()
parameters (as necessary)By sharing soy templates between your back-end and front-end you can generate HTML at initial page load (on the back-end) to render quickly in the browser. Then update (a portion of) the page dynamically on the front-end based on user interaction. Combining this pattern with the incremental-dom soy back-end results in a particularly smooth UX.
Prefer robfig/soy
in the vast majority of cases.
TODO(hochhaus)