Combining with client-side templates, syntax compatibility

[wnewbery]

Often I have the need to do at least some of the rendering client side. But as well as really liking Slim's syntax, its often useful to still have a server-side pass (e.g. to make use of Rails helpers like image_path/image_tag, route helpers, etc.).

For example Ive been trying out JsRender recently, and so would be nice to be able to have Slim pass through certain things.

a.add href=new_item_path New Item
ul.items
  {{for items}}
    li id={{>id}}
      a [{{if external}}target="_blank"{{/if}}] href={{>url}} {{>title}}
      button.del

But the { confuses Slim and it wont accept that indentation.
{ can already be disabled as an attribute wrapper, but I cant see how to treat lines or attributes starting with { as literal text up to a }, or some sort of plugin interface so I can tell Slim what to do when it encounters a {.

Is there any light-weight client syntax with better compatibility?

Or scope to make it easier to tell Slim to output certain patterns as literal unescaped text in attribute and indentation contexts?

A compromise syntax style for example might be like:

a.add href=new_item_path New Item
ul.items
  / slim doesnt know what this `{` means, so just ignore the indent change
  / (as if it was  `=some_unknown_ruby do`, but no automatic `end` either)
  {{for items}}
    li id=="{{>id}}"
      / just put the evaluation of ~"ruby-string" in the relative position in the <a> tag
      a ~'{{if external}}target="_blank"{{/if}}' href=="{{>url}}" {{>title}}
      button.del
  / slim doesnt know what {{for}} is so cant auto-close it, but also doesnt throw a syntax
  / error for the indent change (and does the `</li>` as normal
  {{/for}

[Spone]

I usually convert my Slim templates to Pug when I need to use them client-side. It's pretty easy to do it manually as the two languages are similar (except with Pug, expressions will be interpreted as JavaScript instead of Ruby).

[wnewbery]

Not the same thing in many cases unfortunately. The main template will often refer to server-only things (like that new_item_path), and for a small JS component it may not be desirable to make the entire site a JS app, so its an issue of mixing both in the same file.

For now I have just been keeping JS views separate, and letting the JS find the right DOM location using an id attribute. But means those things have their views separately from the main site. Also means giving JS URLs and stuff by another channel to insert into the JS template.