Search jQuery

jQuery Forum

Templating Syntax

in Developing jQuery Core • 9 years ago

Hello All -

This is a follow-up to the previous templating discussion (the thread was getting a bit unwieldy and I wanted to address some of the concerns found therein).

To start, I wanted to make one point very clear: The templating code being developed is a jQuery plugin. It's being developed by the jQuery team and will be maintained by the jQuery team as an official plugin. As with every major feature in jQuery we look to see how the community responds and interacts with existing plugins for guidance on what to land into jQuery core. Maybe it'll eventually land in core, maybe not, but our primary goal is to get it out and into the hands of developers to help them to ease their development.

I will also say that no one cares more about increases in complexity or filesize more than me - I'm jQuery's biggest advocate when it comes to keeping a minimal featureset and reasonable download. With templating, especially how I've proposed it, it's possible to add no overhead for existing users, only one new API method, a minimal increase in filesize, and yet yield a surplus of simplification for developing complex HTML structures.

As usual I've been doing my development in the templating plugin Github repository .

The original plugin that I posted had a very crude templating syntax, mostly copied from my older micro templating library .

My original goal was to discuss the overall API for the templating system and then discuss the actual templating syntax second. Either the API, as proposed, is spotless or everyone loves to bikeshed templating syntax (I suspect it's the latter, rather than the former). Regardless I've read through the criticism of the templating syntax and feel as if I've come up with a solution that's good enough to handle most concerns.

I've reduced the templating syntax to three basic components: variable substitution, looping, and conditional (if/else) statements. All of it is extensible and it's possible to override every method with your own functionality, if you so choose. With this reduction there is no longer any overt inline JavaScript code and all logic can be written externally to the template.

I've taken a lot of inspiration from Mustache.js when working on the syntax. I think they did a lot to try and reduce complexity and make it easier for developers to get started - and especially in reducing the interspersing of logic in templates. I've taken some of the core ideas presented, expanded on them slightly, and layered in additional extensibility to build a final solution that should better meet the needs of JavaScript developers.

Variable Substitution

You can use ${varName} or {{= varName}} to insert in a value. Both map to the same functionality and can be overridden/extended.
Will output an empty string if null or undefined are found.
All output is encoded to avoid attempts at injection or malformed output.
If you wish to inject raw HTML you can do:
1. {{html varName}}
If the value is a function it is executed and its contents are substituted. Thus logic can be contained in the data object and be injected directly into the template.
1. var user = {
2. firstName: "John",
3. lastName: "Resig",
4. name: function() {
5. return this.firstName + " " + this.lastName;
6. }
7. };
8. // Ignore the extra spaces, the forum will mess it up otherwise
9. $("#users").append("< li >${name}", user);
10. // Will insert the following:
11. // < li >John Resig
In this way you can continue to keep a clean separation between your template logic and the actual markup.

Looping

jQuery's each method is exposed via the 'each' template method.
1. {{each someArray}} ... {{/each}}
You can pass the same arguments to the each callback as you would to jQuery's .each():
1. {{each users}}< li >${this.name}{{/each}}
2. {{each(i, user) users}}< li >${user.name}{{/each}}
Additionally the properties of each iterated object are exposed, allowing for this simple result:
1. {{each users}}< li >${name}{{/each}}
There are also two shortcuts for substituting the current value:
1. {{each name}}${this}{{/each}}
2. {{each name}}{{=}}{{/each}}

Conditionals

The only piece of logic introduced into the templating.
Can do simple if statements - work similarly to the variable substitution, will pass if the result is not equal to null or undefined (thus will pass if the result is false or 0 or an empty string, for example). (Now works identically to normal JavaScript if statements - I'm considering an ifdef or some such to check to see if a variable is defined.)
1. {{if user.name}} User Name: ${user.name}{{/if}}
You can do basic expressions as well.
1. {{if user.height > 5}} This user is tall!{{/if}}
You can also do else statements.
1. {{if user.name}}
2. User Name: ${user.name}
3. {{else}}
4. No user name.
5. {{/if}}

Extensibility

The majority of the logic in the templates will be contained within the builtin commands or in the data objects themselves.
New functionality can be easily snapped into the templating system.
Methods can be standalone (like {{= varName}}) or involve open/closing syntax (like {{each someArray}} ... {{/each}}).
All native functionality can be overridden, even variable substitution.
For example, let's add in a new 'join' method for joining the results from an array.
1. jQuery.tmplcmd.join = {
2. prefix: "_.push($1.join('$2'))"
3. };
You can use it like so:
1. {{join cities}} // Will produce: AtlantaBostonPortland
2. {{join(, ) cities}} // Will produce: Atlanta, Boston, Portland

I hope this helps to explain some of the changes that've been made and I hope that the majority of the concerns that were discussed have been addressed.

(Note: I'm going to be away for the next couple days but I hope to address any comments or questions when I return, either this weekend or next Monday.)

Response title

Attachments

Replies(33)

Statistics

Tags

Actions