node.jscoffeescriptcoffeekupzappa

embedded coffeescript in a coffeekup view in zappa


Is there a way to pass variable values (just for reading, obviously) from the app to the embedded coffeescript in a coffeekup view (in zappa), such as:

.... @render 'index', myVar:"something"

@view index: ->
  coffeescript ->
    $(document).ready ->
      I need to get to myVar here...

It seems really slick if it would work... (as an alternative to embedded javascript)

Update: Here are a few attempts. I'm just trying to use the string in my embedded script as an id.

coffeescript ->
  $(document).ready ->
    id = myVar

coffeescript ->
  $(document).ready ->
    id = "#{myVar}"

coffeescript ->
  $(document).ready ->
    id = @myVar

coffeescript ->
  $(document).ready ->
    id = "#{@myVar}"

I've written some quick javascript in a script -> function (since it's just a string, I can interpolate the variables easily), so I've worked around it, but the coffeescript way would be cleaner. It makes sense that the scope would be lost on the browser side--I was just trying to figure out how to do it.


Solution

  • I guess by "script -> function", you mean something like:

      doctype 5
      html ->
        body ->
          h1 "Hello world."
          script "myvar = \"#{@myvar}\""
          coffeescript ->
            console.log myvar
    

    At least that's a hackish workaround. It could be done with objects as well, typically using JSON or similar for serialization.

    But I would not categorize this as a "clean coffeescript way", so I guess the question still stands!

    Just to elaborate a bit; The problem here is that we're executing coffeescript code in two contexts; one on the server which generates the html to send to the client, and the other on the client itself through in the context of the coffeescript -> construct.

    The server side knows about locals and similar, so for the code that runs on the server, it's simple to evaluate the coffeescript based template and replace template variables with values and similar.

    Not so on the client. First of all the client knows nothing about locals / template variables, it only sees whatever those contained when the page got rendered server side. And doing simple template expansion inside the coffeescript construct would not work either, as coffeescript would not know if you refer to a local variable on the client or a template variable on the server. In theory there could be special sequences that signal "expand template variable inside coffeescript code" as well, but then we're just - again - creating a new template language on top of coffeecup. It could be made to look like regular coffeescript of course, e.g. serverLocal(SOMEREF), where SOMEREF would be replaced with the corresponding value.

    In theory, Coffeecup could support a construct that shared all (or a selection of) locals also as variables to be accessed client side, using a "hack" similar to the script hack I showed above, and it would probably be not too different, except using JSON or similar for supporting more kinds of data than simple strings.