Rendering templates fails on various line breaks about riot

[tipiirai]

Just a quick question before I start fixing these. What issues does this cause? When do you want to preserve line breaks on the rendered output?

It doesn’t matter whether they’re preserved, but they certainly shouldn’t break anything.

I’ll amend that to say it doesn’t usually matter. People have their reasons. It’s not much trouble to escape them either way.

And in various situations involving backslashes, too.

This is not fixed. \n is not \u2028. Why did you bother using a second regular expression at all?

I am also pretty sure this was fixed ages ago, with a test. What happened?

Ah, what the heck, I don’t care anymore. The direction your template engine has taken is slightly nauseating. Maybe more than slightly.

’Bye.

[tipiirai]

Sorry, what should I use as the replacement for \u2028 and \u2029?

Nauseating? What do you mean precisely? What's the issue and how would you fix it?

Two things that are valued on Riot:

1. extreme performance
2. small file size

I think those two are met on the current template engine.

[andyvanee]

I've pretty much come to the conclusion that escaping these is worthless, and the issue is a troll because:

1. It only affects template authors, developers who are fully capable of keeping these characters out of their templates.
2. The actual characters themselves display nothing in HTML.

I'm happy to be proven wrong though...

[tipiirai]

Makes perfect sense to me. I'm happy to remove \u2028/9 escapes from the code.

@rminty, what is your reponse to this?

[tipiirai]

Yup, cannot see any reasons why developer would use \u2028/9 characters on templates. A crazy edge case that need not to be addressed. Curious why @rminty was so obsessed with this.

Nauseating? What do you mean precisely? What's the issue and how would you fix it?

The fact that you’re moving away from security and consistency in the template engine by:

• Making escaping not the default
• Making edge cases that had been previously fixed fail just because you can’t see a reason for them
• Sacrificing performance and robustness for some warped sense of convenience by squashing all errors involved in accessing a property for whatever reason

To answer your question:

Cool. Mind giving solutions?

Yes, I now mind giving solutions. I gave solutions, they got implemented, and you’ve somehow gone backwards from there. Silently removing test cases instead of fixing your code? Really?

I've pretty much come to the conclusion that escaping these is worthless, and the issue is a troll because:

This is another reason why I’m tired of helping. Yawn.

Oops, missed a part.

Sorry, what should I use as the replacement for \u2028 and \u2029?

How about… \u2028 and \u2029?

[tipiirai]

@rminty looks like you are missing the point here: \u2028 and \u2029 characters on templates are not valid use cases. There is no reason to tests for cases that are never used. This is especially important for Riot where code size is critical. You are taking an extreme use case and making it a major issue.

I can also see you are being upset about the comments here which made your comments emotional and harsh. I'm sorry you feel that way. Hope you can help on other areas in future.

The thing is, it looks like you’re going out of your way to make them not work. They were already working, and there is already an escape map; adding the second regular expression that silently changes a pair of completely valid characters makes it:

• longer
• incorrect

If you’re truly aiming for a lean template engine, drop it all together and let an actual error happen. The error will be confusing, but at least less confusing than a squash-all-errors policy. Same thing for the try. Did you benchmark it? It’s longer, slower, and makes mistakes pass uncaught (ironically enough).

This template engine that I built has accurate escaping and loops and recursion and things and it actually ends up smaller than Riot when the Node parts are stripped out and it’s minified. Maybe you can take inspiration from it. It’s pretty fast.

[tipiirai]

The purpose of try is to enable nested object access {x.y.z}. Rendering should not break if y does not exist. It's not perfect but it's the best I know so far. I'm all open to suggestions here!

btw: I just realized that the try block should not be the outmost block and it should be done per property. Unfortunately it slows down a lot. Clearly an area for improvements.

Rendering should not break if y does not exist.

Yeah, it should! When is this not a mistake? That is a worse policy than PHP-style error handling. It is less intuitive than Jinja.

If you’re really attached, though:

function squashPropertyChain(name) {
    var parts = name.split('.');

    return '(' + parts.map(function (part, i) {
        return parts.slice(0, i + 1).join('.') + ' != null';
    }).join(' && ') + ' ? ' + name + ' : "")';
}

Or, if you can guarantee a free variable name (_ here; more effort), this might be more efficient and should also play nicely with getters… not that anyone will use those:

function squashPropertyChain(name) {
    var parts = name.split('.');

    return '((_ = ' + parts[0] + ') != null' + parts.slice(1).map(function (part) {
        return ' && (_ = _.' + part + ') != null';
    }).join('') + ' ? _ : "")';
}

I don’t like this code as much, though.

[tipiirai]

Hmm... I suppose I could remove that try block and let bad property access throw an error. Good point, thanks. @andyvanee what is your thought on this?

As an alternative I'd personally use something like this (pseudo code)

return name.indexOf(".") > 0 ? /* try block here */ : _.$1

[andyvanee]

Yeah, that try is definitely in the wrong spot.

I'm not opposed to letting it throw an error, but it should be consistent. It was returning an empty string for {x}, so it seemed to make sense to do the same for {x.y}. This is what mustache (and it's descendants) do, but many others will throw errors or have that as a configuration option.

When is this not a mistake?

I'm coming around to this point of view, especially in the context that riot seems to require.

The mustache technique is good if the rendered template is purely display. For example, rendering from some 3rd party json that you don't control. But if you are taking the data from a rendered template, watching it and feeding it back into your app, it only makes sense to throw an exception.

[tipiirai]

I'll remove the try block in v1.0.1. Thank you guys!