Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected indentation with newline delimited attributes #59

Open
rraval opened this issue Aug 25, 2015 · 5 comments
Open

Unexpected indentation with newline delimited attributes #59

rraval opened this issue Aug 25, 2015 · 5 comments

Comments

@rraval
Copy link

rraval commented Aug 25, 2015

Try Coffee-React link

If I have JSX that looks like:

<Foo
  className="Foo">

  <Bar
    className="Bar">

    {expr}
  </Bar>
</Foo>

This gets compiled to:

React.createElement(Foo, { \
  "className": "Foo"},

  React.createElement(Bar, { \
    "className": "Bar"},

    (expr)
  )
)

CoffeeScript chokes on this input, claiming unexpected indentation. Strangely, if I remove either of the backslashes (or put the attributes on the same line, which makes the transform produce equivalent code), it works without a problem.

@jsdf
Copy link
Owner

jsdf commented Aug 25, 2015

Try to keep your closing brackets in line with your opening ones. I want to remove this limitation in future but it's a big piece of work

@jsdf
Copy link
Owner

jsdf commented Aug 25, 2015

Example

@rraval
Copy link
Author

rraval commented Aug 25, 2015

Ah I see. Forgive my ignorance but is there a specific reason why the newlines aren't simply stripped? This was the implicit behaviour I was expecting before I actually looked into what the output looked like.

For example:

<Foo
  className="Foo">

  <Bar
    className="Bar">

    {expr}
  </Bar>
</Foo>

would be converted to

React.createElement(Foo, {"className": "Foo"},
  React.createElement(Bar, {"className": "Bar"},
    (expr)
  )
)

@jsdf
Copy link
Owner

jsdf commented Aug 25, 2015

As I haven't implemented source maps yet, the temporary (but long standing) solution was to make sure the input lines had 1 to 1 parity with output lines.

@rraval
Copy link
Author

rraval commented Aug 31, 2015

Fair enough. I don't really use source maps since the transformation is pretty trivial to work backwards to the offending line, but I can see the reasoning.

Perhaps in the short term a --ugly could be introduced to explicitly opt into a more permissive parsing mode provided that the output doesn't need to match 1 to 1?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants