CoffeeScript Version ?

[Drasky-Vanderhoff]

Hi, i'm interested in working with React.js at some point and i use exclusively CoffeeScript. Anyway i can add a CoffeeScript option ? What files i need to work with in order to change it ? First time i work on Sublime package but i'm very eager to do it.

Thanks!

[jgebhardt]

Great idea! I'd have to look into the exact coffeescript syntax, but here's how this could work: there is a single file per snippet in /snippets and each is scoped to a language context. You could just
duplicate the snippets in a coffeescript subfolder, change the scope to coffeescript and adjust the content. The downside is that we'd need to maintain these in parallel.

[jblock]

There's also the issue of semantics. There's currently two (good) ways to handle writing JSX in CoffeeScript:

1. Lispy

Since all JSX compiles down to is an object-based description of the DOM nodes, you can get a little functional and express the JSX syntax similar to ClojureScript:

{div, h1, h2, input} = React.DOM

NewComponent = React.createClass
  render: ->
    (div [
      (h1 {}, 'This is an h1'),
      (h2 {}, 'This is an h2'),
      (input {onChange: @handleChange}, value: @props.name})
    ])

The downside: even more abstraction from pure markup. This makes it even harder for designers to get in there and mess around with the code.

Reference

2. Cheating

Escape the JSX code using tickmarks (including the JSX comment at the top of the document) so they just get compiled down to pure JS

`/**
 * @jsx React.DOM
 */`

ProfileEdit = React.createClass
  handleChange: ->
    this.props.changeProfileInformation(
      this.refs.profileName.getDOMNode().value,
      this.refs.profileEmail.getDOMNode().value
    );
  onSubmit: (e) ->
    return false;
  render: ->
    return `(
      <div>
        <h4>Edit Profile Information</h4>
        <form onSubmit={this.onSubmit}>
          <input
            type="text"
            placeholder="Enter a name..."
            onChange={this.handleChange}
            value={this.props.profileName}
            ref="profileName"
          />
          <input
            type="text"
            placeholder="Enter your email..."
            onChange={this.handleChange}
            value={this.props.profileEmail}
            ref="profileEmail"
          />
          <button>Change</button>
        </form>
      </div>
    )`

Now, you have another compilation step to bring the JSX code down to actionable JS. Not impossible, but another complication during the build process.

Reference

I'm tempted to go with the latter as to minimize intrusion in a CoffeeScript codebase (for example, it's unlikely that we'll adopt React wholesale immediately and I want the markup layer to be as transparent as possible if designers wanted to get in there).

TLDR:
I'm going to investigate this further, and see what works best as I start to inject it into our codebase.

[jgebhardt]

@jblock I have no experience with coffeescript projects, but solution 1 seems way more elegant. I can see the benefits of solution 2 for getting your feet wet though.
Either way, I've been thinking about the best way to maintain a coffeescript version and I think it would be best to create a separate fork. There may be overhead from keeping projects in sync, but only a small fraction of React users will be using coffeescript, and an inclusion would imply that other JS dialects and meta-languages could be included as well, which is beyond the scope of this project. So please fork away! :)

[jblock]

@jgebhardt oh, way ahead of you :)

On Mar 17, 2014, at 11:47 PM, Jonas Gebhardt notifications@github.com wrote:

@jblock I have no experience with coffeescript projects, but solution 1 seems way more elegant. I can see the benefits of solution 2 for getting your feet wet though.
Either way, I've been thinking about the best way to maintain a coffeescript version and I think it would be best to create a separate fork. There may be overhead from keeping projects in sync, but only a small fraction of React users will be using coffeescript, and an inclusion would imply that other JS dialects and meta-languages could be included as well, which is beyond the scope of this project. So please fork away! :)

—
Reply to this email directly or view it on GitHub.