search

denoland / std

The Deno Standard Library
https://jsr.io/@std
MIT License
3.19k stars 623 forks source link

[discussion] text template #391

Closed zekth closed 3 years ago

zekth commented 5 years ago

I just added a repo : https://github.com/zekth/deno-templates

Which kind of do the job of : https://golang.org/pkg/text/template/ Without the logic in it.

Just wondered if it's revelant to expand and add to deno_std

j-f1 commented 5 years ago

What do you think about implementing mustache instead?

zekth commented 5 years ago

What do you think about implementing mustache instead?

First it was just to write a module for myself so just wondering. I've thought about migrating mustache : https://github.com/janl/mustache.js/ I may need some help because it's a bit a lot of work. Especially for the tests.

kitsonk commented 5 years ago

I don't think templating languages should be part of deno_std. They really are an opinionated specialist area.

Also, Template Literals (in particular tagged templates and template functions) that are part of ES6 are the best parts of un-opionated templating built into the language. There is no need these days to build new stuff that deviates from that.

zekth commented 5 years ago

I don't think templating languages should be part of deno_std. They really are an opinionated specialist area.

Also, Template Literals (in particular tagged templates and template functions) that are part of ES6 are the best parts of un-opionated templating built into the language. There is no need these days to build new stuff that deviates from that.

Template literals does not fit the same purpose as Go Template does. Compare : https://godoc.org/text/template#ParseFiles You don't have this possibility in ES6 except using workarounds like using eval.

And that's one of the main reason to use this.

axetroy commented 5 years ago

@kitsonk

We need an official template language so that users can develop quickly without wasting time looking for which library is appropriate.

This template engine may not be the fastest or strongest but it should exist.

Template Literals can't satisfy a simple template engine

ry commented 5 years ago

@kitsonk has a point. It's also important to note that template literals almost solve this purpose at the language level.

That said... I do agree that template files are a very common and useful pattern, and it would probably help deno developers. Also the existence of text/template in Go generally satisfies my requirement for deno_std.

If we did add a templating module the question is what will be the syntax? Should we copy Go's exactly? (This seems to be more or less what mustache.js does?) Given the existence of template literals now, are there not new template modules which try to match the native language syntax?

If someone wants to do this, they would need to research the state of the art and present their case for one syntax over the others. I'm open to it.

In the meantime, it would be nice to have a port of mustache or handlebars in the registry.

zekth commented 5 years ago

I've worked with both mustache and handlebars. I prefer mustache and as i've said the only real work to port it would be the tests. +1 to port mustache in registry.

kitsonk commented 5 years ago

There are some very basic code snippets that would support interpolation of strings with object values, in line with template literals in ECMAScript. It wouldn't allow running of arbitrary code, like you can with template literals, but it could solve the main use case of templating loaded strings. So for example, it would be something like this:

interpolate("hello ${foo}", { foo: "world" }); // returns "hello world"

const myTemplate = template("hello ${foo}");
myTemplate({ foo: "world"}); // returns "hello world"

So I think it either should be kept dead simple like the above, or adopt more of a Go approach (but hopefully with using the JavaScript escape sequence of ${...} instead of Go's {{ ... }}.

akircher commented 5 years ago

I originally proposed using ${} in Angular 2 templates rather than {{}}, this did not stick but did get picked up in Aurelia's templating language. I think it was the right decision for Aurelia, in order to achieve the consistency with ECMA template literals, but there is a downside - if you ever want to put the template within a template literal then you have to escape it. eg.

var view = `<html><body>\${escaped_template_var}</body></html>`
zekth commented 5 years ago

@kitsonk i'm ok to stick with ES syntax. The module i've written handle this, but i have to add the logic to render logic of functions.

import { Template } from "./mod.ts";
const t = new Template("hello ${foo}", {openBracket: '${', closeBracket:'}'});

Also we need to find a symbol for conditionnal statements if we want to add it.