JSX string literal

[cristianoc]

Special case string literals in JSX so ReasonReact.string is added automatically.

[IwanKaramazow]

This raises another natural question, what happens with floats, ints, lists and arrays?
Since their "type" can be determined at lex-time and compiled with a ppx, do we still want the conversion for those others?

[wegry]

@IwanKaramazow wouldn't it make sense that if we aren't sure about conversions, we stick with vanilla React's behavior, i.e. only strings are valid and not floats, ints, list, and arrays?

edit: Arrays of elements are valid children.

[rickyvetter]

There are some pretty serious problems that come with this because ppx doesn't have access to the type information. It doesn't allow strings to be lifted outside of the ppx in a typesafe manner which will almost certainly result in issues with refactoring and some really confusing bugs for newcomers.

As an example:

<div> "foo" </div>

will typecheck and

let foo = "foo";
<div> foo </div>

will not.

[gilbert]

I think the string literal lifting issue is a small price to pay and should not be considered a deal breaker.

[rickyvetter]

@gilbert it's not just lifting that will cause issues:

<div> {"Hello, " ++ name} </div>

won't typecheck and

<div> {localize("Title of the Page")} </div>

won't typecheck unless localize only works as a React element. You'll need a different function to operate outside of React.

If everyone were very familiar with these nuances then sure, I think this would be fine for convenience. What I'm worried about is how to explain this differing behavior to people who aren't aware of the nuances.

[gilbert]

I see, thanks for showing the other issues.

[kujon]

It doesn't allow strings to be lifted outside of the ppx in a typesafe manner which will almost certainly result in issues with refactoring and some really confusing bugs for newcomers.

TypeScript has got a very similar behaviour when using type guards. It's the most annoying thing in the world, it makes you re-factor code only because the compiler doesn't understand.

Let's not go there with Reason please.

[rickyvetter]

As an alternative I'm curious about how people feel about React Native's implementation with Text. We could expose a new <Text> </Text> element which takes a string as it's child and renders as you would expect. If we did that then we would probably remove ReasonReact.string and ask that strings are always placed into Text elements.

[kennetpostigo]

@rickyvetter I wonder how that would work for people using bs-react-native? They could probably alias the text from that library?

[rickyvetter]

Yeah if this was a path we wanted to explore we'd work with the bs-react-native folks to make sure it would work for them.

[texastoland]

A text element makes sense. Alternatively why not just coerce {j|hello, $interpolation|j} (js too) to reactElement? That seems less intrusive and a newcomer likely also wants interpolation.

[facebook-github-bot]

Thank you for your pull request. We require contributors to sign our Contributor License Agreement, and yours has expired.

Before we can review or merge your code, we need you to email cla@fb.com with your details so we can update your status.