Template Abstract Syntax Tree (aka: templast )
a unist compliant syntax tree spec for templating languages
Because there are plenty of "components" and views that are really nice but only available in some other template engine. It would be nice to make a bridge to common ground such that the template langauge could be ported to templast which would unlock a world of templates, view, components such that I am not limited to my epression types based on some historical choice of template language I learned.
npm i @federa/templast @federa/templast-cli -D
pipe it in
$> cat someTemplate.hbs | npx templastCLI -c config.js > someTemplate.apacheVTL
use the command line args
$> npx templastCLI -c config.js -i someTemplate.hbs -o someTemplate.apacheVTL
redirect a file in
$> npx templastCLI -c config.js < someTemplate.hbs > someTemplate.apacheVTL
use the lib/module in with es modules
import templast from '@federa/templast'
import hbsParse from '@federa/handlebars-parse'
import vtlStringify from '@federa/vtl-stringify'
import vfile from 'to-vfile'
templast()
.use(hbsParse)
.use(vtlStringify)
.process(vfile('./myexmaple.hbs')) // or change it to a real handlebars example
use the lib/module in within node
const vfile = require('to-vfile')
const templast = require('@federa/templast')
const hbsParse = require('@federa/handlebars-parse')
const vtlStringify = require('@federa/vtl-stringify')
templast()
.use(hbsParse)
.use(vtlStringify)
.process(vfile('./myexmaple.hbs')) // or change it to a real handlebars example
EJS
but you are trying to migrate to handlebars
doT.js
you can now convert your own examples to that flavor of templating languageIf you deal with enough template languages it would be nice to be able to move back and forth as much as is possible.
For exmaple Mustache
template for example would not easily/beautifully support all the features from a handlebars
template but for many other types it would be very nice.
the AST would need to support
ROOT
COMMENT
LITERAL
string
number
array
object
boolean
PARTIAL
inlineDefinition
referenced
EXPRESSION
BlockStatement
// hash lookup to be replaced with string
SubExpression
// is it needed, given children nodes?MustacheStatement
// hash.lookup with children conditionally availalbe StateDeclaration
// ApacheVTL - - to a pure data in template - Warn that some data 'defaults' may be lostContextLookup
// Blcok ExpressionMacro-Helper Block
doT + VTL + handlebars + EJS
EJS Examples:
<% const someFunc = ()=>{} %>
<% const|let|var someFunc = function(){} %>
childrenContext
List = DATA[]
INDEX = intergerSetContext
ExitContext
ConditionalContext
To give some assurances that this AST works well, it should be demonstrated that many template languages fit into the paradigm.
templast
templasTree
could be rendered to handlebars without issuewarnings
or failures
to the template if the source file was from some other template system and is now going to be rendered as a mustache file.templast
templast
templast
templast
templast
templast
templast
templast
templast
js template literals are stringified as a function that receives input data and pumps them into a string that mixes in the data. SUPER NICE because it is a least common demoninator, for just looking at the markup, for any server side rendering environment,
const t = (data)=>`some text ${data.attr} with more static content`
hast
compatible. hast
nodes and templast
nodes such that you might be able to represent a template as:virtual-dom-strigify
with the fucntion token to use: default is 'h' but could easily be preact.h
or React.createElement
/** @jsx Preact.h */
import attrs from 'myCSSinJSfile.js'
const t = (data) => h('div',attrs.div, [
h('div', attrs.div, [
h('h3', attrs.h3, data.title )
]),
h('form', attrs.form,
h('input','button',data.buttonText)
])
templast
templast
templast
templast
templast
templast
virtual DOM
parse
and stringify
jade
pug
EJS
ERB
PHP.twig
templatesnpm start
will download a ton of other git repos into the packages folder.
Where each of the packages have their own repo and lifecycle.
Then use the npx meta
command to manage all those sub-repos in some type of lerna-overlord-style
to-and-fro-Apache-Velocity-Templates
#with
and #each
Babel7Ast-to-mdxast
TSast-to-mdxast
MDXAST
MDAST +
JSX -> script
COMMENT
Import
Export
MDXHAST
HAST + type: element tagName: div, span, form, input, properties: {} children:[] ƒ h(tagType, {props}, [ children ] )
imports
exports
inlineCode
means that an .mdx file is really a fancy JS file a certain type of JS file that has some convention allowing it to be rendered when invoked with proper context
#with
and #each
What's the difference in a partial and a helper? other than the partial is often requiring a template fetch.
parserconfig for every *-parse
expandPartials = true
partialsProvided = {}
partialsResolverFunction = ()=>{}
configDelimiters =null = auto
/default
handlebars.parse( string ): AST
hbs.AST.MustacheStatement
hbs.AST.BlockStatement
hbs.AST.PartialStatement
hbs.AST.PartialBlockStatement
hbs.AST.ContentStatement
hbs.AST.CommentStatement
hbs.AST.SubExpression
hbs.AST.PathExpression
hbs.AST.StringLiteral
hbs.AST.BooleanLiteral
hbs.AST.NumberLiteral
hbs.AST.UndefinedLiteral
hbs.AST.NullLiteral
hbs.AST.Hash
hbs.AST.HashPair
Engines Considered:
Can you view MDX as a fancy system of tons of partials?
If so what if templates that rendered HTML <div> etc... </div>
could also render a virtual dom via h functions?
What if you could easily make interop on things that usually render a virtualDOM? - and coerece them to render strings?
hbs-parse // HBS source --> TASTY verify-hbs // TASTY --> HBS dialect hbs-stringify --> HBS Dialect --> string
mustache-parse
verify-mustache // assigns warnings
or failures
to the template if the source file was from some other template system and is now going to be rendered as a mustache file.
mustache-stringify
apacheVTL-parse verify-apacheVTL apacheVTL-stringify
doT-parse verify-doT doT-stringify
jsTemplateLiterals-parse verify-jsTemplateLiterals jsTemplateLiterals-stringify