Multiline strings in JavaScript
github.com
github.com
function checkType(f) {
return function(a) {
var type = f.toString().match(/\/\/(.*)\n/)[1].trim();
if(type !== typeof(a)) throw new Error('Invalid type');
return f(a);
}
}
var halve = checkType(function(n) {
// number
return n / 2;
});
halve(4); // returns 2
halve('string'); // emits errorProbably because sometimes they're not, depending on the JavaScript engine (though perhaps all of the major modern browsers do)
- Latest Chrome
- Firefox >=17
- Safari >=4
- Opera >=9
- Internet Explorer >=6
From: https://github.com/sindresorhus/multiline#compatibility
1) There have been so many versions and not easy to know what came when.
2) Most people get updated to Chrome latest automatically without any fuss.
From http://arstechnica.com/information-technology/2014/07/window...
[1]: http://zurb.com/forrst/posts/Javascript_native_multi_line_st...
I think for this reason I still prefer using Array.prototype.join for multiline strings:
var str = [
'<!doctype html>',
'<html>',
'<body>',
'<h1>❤ unicorns</h1>',
'</body>',
'</html>',
].join(''); var str = ' \
<!doctype html> \
<html> \
<body> \
<h1>❤ unicorns</h1> \
</body> \
</html> \
'
I find it's better than string concat because the trailing \ is just one annoying thing rather than three. var str = ' \
<!doctype html> \
<html> \
<body> \
<h1>❤ unicorns</h1> \
</body> \
</html> \
'
Help I'm maintaining your code and I get a syntax error var str = [
//...
].join("\n");Since to preserve these comments in minification requires conscious effort, I wonder if there's an alternative that could convert the comments to regular JS before minification. Obviously you can't just run it in Node as normal doing it this way.
var str = multiline(function(){/*!@preserve
multi
line
string
*/console.log});
Really?The topic is about how to do multiline string in Javascript in one way, and one alternative is not to use multiline strings in Javascript. It's kinda big jump from the original purpose of the topic to start suggesting alternative languages... if we are to be this slack, then we can start spamming most threads with weakly related stuff. For example, you can easily advertise coffeescript in each and every javascript thread in a similar way you did in this specific thread but do we really need want that?
<script id="fragment" type="x-shader">
precision highp float;
uniform vec3 glyphColor;
void main() {
gl_FragColor = vec4(glyphColor, 1.0);
}
</script>Firefox Nightly currently supports just enough of template strings to give you multiline strings.
1: https://bugzilla.mozilla.org/show_bug.cgi?id=688857#c22
2: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
3: https://developer.mozilla.org/en-US/docs/Web/JavaScript/ECMA...
Using this in a library would be pretty unsafe, given how it's browser-dependent, is prone to issues with minifcation, and could just break with future versions of your JS engine.
http://stackoverflow.com/a/15558082/2371924
var myString = function(){/*
multi-line
string
*/}.toString().slice(14,-3)
take this code snippet, throw a package.json and some yaml in and make another npm to Show HN.Did you even read TFA?
var htmlFragment = "" + (<r><![CDATA[
l(a
le
af
fa
ll
s)
one
l
iness
- e.e. cummings
;
]]></r>);
And then `htmlFragment` would contain your multi-line string. (The addition with the empty string coerces the <r> element to output its `toString()` value, which happens to be the innerHTML).This is largely a historical factoid, though. I don't think browsers beyond Mozilla ended up supporting E4X.
Really clever hack with the function's toString method!
That said, I've seen multiline abused for writing SQL queries as well, which would have been better off being written in a separate .SQL file and `fs.read` into a string with a descriptive var name. (Ignoring that massive SQL strings is a code smell imo).
var multiline = function(){/*
foo
bar
baz
*/}.toSource().match(/\/\*([\s\S]*)\*\//)[1].trim()appendChild instead of innerHTML .html file instead of html inside a .js file. .css file instead of css inside a .js file.
It can get very messy if you store "data" inside JS. Especially if you store markup or styling in the JS.
(And people complain about Python having significant whitespace?)
Alternatively wait for ES6 or ES7 to (maybe) solve the problem.
Edit: Yawn.