What kind of Ruby / Erb is allowed inside HAML's :javascript

rubyonrails-talk
1

It seems that inside of HAML's :javascript filter, no Ruby code is allowed, not even a comment.

So this is NOT allowed:

:javascript   - 1.upto(10) do |i|

:javascript   -# just a comment not to show to public

(somebody said there is not way to hide comment like that inside a :javascript filter. Is that true?

but it seems the only thing allowed is

:javascript   $('#aDiv').html('#{a_ruby_variable}';

only this #{ } is allowed. Nothing else that is Ruby is allowed?

2

Jian Lin wrote:

but it seems the only thing allowed is

:javascript   $('#aDiv').html('#{a_ruby_variable}';

correction: (missing the ending paren)

    :javascript       $('#aDiv').html('#{a_ruby_variable}');

3

Jian Lin wrote:

It seems that inside of HAML's :javascript filter, no Ruby code is allowed, not even a comment.

I believe that's correct. But you should never need Ruby within JavaScript, nor should you ever need JavaScript within HTML (it's best to put it in a separate file).

So this is NOT allowed:

:javascript   - 1.upto(10) do |i|

:javascript   -# just a comment not to show to public

(somebody said there is not way to hide comment like that inside a :javascript filter. Is that true?

Probably.

but it seems the only thing allowed is

:javascript   $('#aDiv').html('#{a_ruby_variable}';

only this #{ } is allowed. Nothing else that is Ruby is allowed?

I'm surprised that #{} works here.

If you think you need Ruby in your JS, you've got a design problem. Fix it.

Best,

4

Marnen Laibow-Koser wrote:

If you think you need Ruby in your JS, you've got a design problem. Fix it.

i can think of a few cases where Ruby might be wanted inside of Javascript output:

1) -# to add comment but not to show it to the public 2) using if else to output something based on some condition 3) using loop 4) providing values to javascript code by json

5

Jian Lin wrote:

Marnen Laibow-Koser wrote:

If you think you need Ruby in your JS, you've got a design problem. Fix it.

i can think of a few cases where Ruby might be wanted inside of Javascript output:

And all of them represent design problems and are better handled in other ways.

1) -# to add comment but not to show it to the public

Use a JS minifier.

2) using if else to output something based on some condition 3) using loop

Use JavaScript control structures for these, not Ruby control structures.

4) providing values to javascript code by json

Put the JSON in a (hidden) div, have the JavaScript read its content.

Best,

6

Marnen Laibow-Koser wrote:

1) -# to add comment but not to show it to the public

Use a JS minifier.

2) using if else to output something based on some condition 3) using loop

Use JavaScript control structures for these, not Ruby control structures.

4) providing values to javascript code by json

Put the JSON in a (hidden) div, have the JavaScript read its content.

JS Minifier when there are 5 lines of code?

Also, I think we can always do things another way... but just that why embedding values from Ruby to Javascript is bad, while hiding them first in a div and read it back from the div is good? (suppose they are simple keywords from our db which keywords like "shirt", "shorts", "jacket" which will not cause any javascript injection by user input.)

7

Jian Lin wrote:

Marnen Laibow-Koser wrote:

1) -# to add comment but not to show it to the public

Use a JS minifier.

2) using if else to output something based on some condition 3) using loop

Use JavaScript control structures for these, not Ruby control structures.

4) providing values to javascript code by json

Put the JSON in a (hidden) div, have the JavaScript read its content.

JS Minifier when there are 5 lines of code?

If there are only 5 lines of code, why do you need private comments in the first place?

Also, I think we can always do things another way...

Yes.

but just that why embedding values from Ruby to Javascript is bad, while hiding them first in a div and read it back from the div is good?

Because it separates the Ruby and JavaScript more cleanly. This makes the code more maintainable, and also improves performance by allowing the client to cache one JavaScript file instead of the server having to regenerate it for each call.

  (suppose they are simple keywords from our db which keywords like "shirt", "shorts", "jacket" which will not cause any javascript injection by user input.)

Then they should still be handled in the way I suggested. Dynamically generating JavaScript is almost always a bad thing.

Best,

8

Marnen Laibow-Koser wrote:

JS Minifier when there are 5 lines of code?

If there are only 5 lines of code, why do you need private comments in the first place?

Do you often see other people's way of doing things needing to abide to your rule book? Such as: if there are only n lines of Javascript code, they shall never have private comments there.

9

Jian Lin wrote:

Marnen Laibow-Koser wrote:

JS Minifier when there are 5 lines of code?

If there are only 5 lines of code, why do you need private comments in the first place?

Do you often see other people's way of doing things needing to abide to your rule book? Such as: if there are only n lines of Javascript code, they shall never have private comments there.

You missed my point. It wasn't "shall never". My point was this: a 5-line routine should normally not need comments. If you need comments on something that short, perhaps your code isn't as clearly written as it should be...

Best,

10

Marnen Laibow-Koser wrote:

Jian Lin wrote:

Marnen Laibow-Koser wrote:

JS Minifier when there are 5 lines of code?

If there are only 5 lines of code, why do you need private comments in the first place?

Do you often see other people's way of doing things needing to abide to your rule book? Such as: if there are only n lines of Javascript code, they shall never have private comments there.

You missed my point. It wasn't "shall never". My point was this: a 5-line routine should normally not need comments. If you need comments on something that short, perhaps your code isn't as clearly written as it should be...

A reason may be, a comment that says "TODO: we don't have enough time to do more than this right now. talk to Simon for when it will be done" -- or any other similar comment -- may not be totally appropriate for the public.

11

Jian Lin wrote: [...]

A reason may be, a comment that says "TODO: we don't have enough time to do more than this right now. talk to Simon for when it will be done" -- or any other similar comment -- may not be totally appropriate for the public.

I see your point about TODO comments. But the fundamental problem here is that your client-side JS has to be delivered to the client to get run. If there are things in the JS that your client shouldn't see, then you need a minifier or an obfuscator.

Or...hmm. Check out CoffeeScript; it's a bit like Haml for JS.

Best,

12

Marnen Laibow-Koser wrote:

Or...hmm. Check out CoffeeScript; it's a bit like Haml for JS.

if only there is a Ruby to JS converter.

13

Jian Lin wrote:

Marnen Laibow-Koser wrote:

Or...hmm. Check out CoffeeScript; it's a bit like Haml for JS.

if only there is a Ruby to JS converter.

Well, there's RJS and CoffeeScript. But Ruby and JS work very differently. My advice is to write each one directly rather than relying on converters.

Best,