Deprecation notice - any good alternatives?

[max-degterev]

We're using this compiler in our app and leaving coffee-script for the semicolon-braces hell looks like a very unappealing option. Does anyone know any good forks/alternatives? Or maybe there are people who are willing to maintain it?

[jsdf]

You could try teact or react-hyperscript

[max-degterev]

Thanks but that kind-of doesn't help. Would prefer a drop in replacement. If i had to rewrite the codebase, might as well go all in and use ES6 (or whatever flavor of the month/time of day it currently is)

[jsdf]

You don't have to rewrite anything. You can use the codemod to codemod your existing codebase to use teact, or anything else which has the same method signature as React.createElement.

[max-degterev]

Very true, but most people are using CoffeeScript and CJSX for its nice terse syntax. Having to use factory functions is opposite of terse and nice. That is a viable middle ground, but not a good long term solution

[jsdf]

If you or anyone else is interested in having a go at building an alternative to this project, a much more robust alternative to the CJSX syntax would be to just fork the coffeescript compiler (or even use a macro system like blackcoffee) and add a simple syntax enhancement just using an additional operator to mark React elements, like:

class MyComponent extends React.Component
  render: ->
    <>MyContainer
       className: 'age-field'
       <>input
         name: 'age'
         value: @state.age

which would compile the same as the following coffeescript:

class MyComponent extends React.Component
  render: ->
    React.createElement(MyContainer,
       className: 'age-field'
       React.createElement('input'
         name: 'age'
         value: @state.age
      )
    )

This would be much easier to maintain as a patch to the coffeescript compiler, because it is a fairly unobtrusive change, and is much simpler to parse than the JSX grammar. By being implemented as part of the coffeescript compiler, you'd get features like good error messages and source mapping for free.

[PascalSenn]

For anyone who is interested in a bit a different approach.

You can use Webpack to compile CoffeScript to JSX and then use Babel to compile the JSX down to valid javascript.

What you basically have to do is to use the back tick's of CoffeScript to exclude JSX from the CoffeScript compiler:

class Foo extends React.Component
    @propTypes =
        foo: React.PropTypes.string.isRequired
        bar: React.PropTypes.number.isRequired
    @defaultProps =
         foo: 'Foo'
         bar: 42

    render: =>
        `<div>
                <div>Foo:{this.props.foo}</div>
                <div>{this.props.bar}</div>
         </div>`

To compile it down in valid JavaScript just use Webpack with the following loader combination:

...
      resolve:
        extensions: ['', '.js', '.coffee', '.jsx', '.js.jsx']
      module:
        loaders: [
          {
            test: /\.coffee$/
            loader: 'coffee-loader'
          },
          {
            test: /\.cjsx$/,
            loaders: ['babel',"coffee-loader"]
          },
....

[isaacw]

@PascalSenn Have you tried this approach, is it working out for you?

I'm new to React, but have been knee deep in CoffeeScript for the last year, and would like to combine the two. I just assumed this would be the approach in the first place. What's the downside to doing it this way?

[PascalSenn]

@isaacw it is working indeed. Compiling takes a while obviously.

We still struggle to have proper code coverage reports with the test though. Code coverage itself is working. But to propagate the sourcemaps down to the reporter is a different thing. It should be possible to fix this. I basically haven't got the time to do it yet. At the moment we split up code coverage of plain coffescript and cjsx files to get at least with the plain files proper coverage reports.

So downsides are:

• Compile time
• Code coverage
• Syntax highlighting and auto complete is not working for react inside the backticks

[isaacw]

Yeah, makes sense. Thanks for the reply! I'm gonna have to experiment with a few methods... or maybe it's finally time to dive into ES6.

[PascalSenn]

If you are willing to try new things, definitely check typescript out. It's basically Javascript which scale for enterprise applications cause of strict types. Which has the nice side effect of intelisense support and auto completion for any object at any place in your code. It's different but worth looking at 👍

[alexdavid]

We are using react-e which is similar to react-hyperscript, but with a slightly cleaner syntax for children and has the classnames module built in

[isaacw]

Nice, looks fairly concise. I ended up just biting the bullet and went back to good old vanilla JSX. As a designer, and someone who's been doing a lot of Framer prototyping, I still really miss being able to write in CS. Perhaps after I'm done learning React and become proficient, I'll look into CS again as an option.

[MaxPleaner]

I didn't find this project until it was deprecated, but it seemed to provide a bridge between the React and Coffeescript worlds, one that has not been rebuilt. Now that React is the flavor of the week, we correspondingly see Coffeescript use decline.

The debate seems pretty dumb to me. There is really nothing about React that is opposed to Coffeescript other than you write your HTML inside the script file. I decided to move forward with Vue rather than React for this reason - like Angular, it lets you write logic inside regular HTML templates using a special DSL. This means that I can use my favorite templating language, Slim, and load the result as a string into Coffeescript (I authored a loader for this, by the way - slim-lang-loader).

Diatribe aside, I came here to ask whether this project is really unusable? The README talks about insurmountable challenges, but only evidences this by the fact that line numbers aren't returned correctly in errors. This isn't necessarily a dealbreaker, in my opinion. What other flaws does it have at this time? What work would need to be done to bring it up to speed?

[jsdf]

Coffeescript 2 has JSX built in

[MaxPleaner]

That's awesome. I think it ought to be better known. Search Google for "coffeescript 2 jsx". None of the results indicate this recent development. I've also been asking around and nobody has told me about this yet. Maybe this project and the coffee-react package should have a note added to the readme

On Tue, Aug 1, 2017 at 10:32 PM, James Friend [email protected] wrote:

Coffeescript 2 has JSX built in http://coffeescript.org/v2/#jsx

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jsdf/coffee-react-transform/issues/77#issuecomment-319571934, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzWxw2NpBmnz-53n0KGQZsj_8mQL1Rsks5sUAnygaJpZM4KN09A .

[MaxPleaner]

by the way if anyone wants to try this out, you can use this boiler:

https://github.com/MaxPleaner/webpack_boiler

[microdou]

The latest commit of coffeescript 2 added the support for {props...} (or {...props}) inside <>.

So JSX (or you can call it CSX now) is now FULLY supported!

During the waiting for the new release of coffeescript-2.0.0-beta4, you can temporarily use "coffeescript": "jashkenas/coffeescript#2" inside package.json to include the latest commit.

As of the loader in webpack, coffee-loader added support for coffeescript 2 in its latest commit, so you can use "coffee-loader": "webpack-contrib/coffee-loader" in package.json. Alternatively, you can just use coffeescript-loader.

[microdou]

FYI, coffeescript-2.0.0-beta4 is out! Also, to comment inside CSX, you can use block comments syntax wrapped in { }.

<div> {### A CSX comment ###} </div>

<div>
{###
  Multiline
  CSX comment
###}
</div>