[Discussion] React native without jsx

[umhan35]

We can use react.js without jsx (http://facebook.github.io/react/docs/displaying-data.html#react-without-jsx), but there is currently no implementation for React.DOM in react native.

I have my own implementation now, which allows me to do the following thing in CoffeeScript:

{TouchableOpacity, View, Text} = DOM

...

    TouchableOpacity
      onPress: => @_onPress(event)
      View
        style: [{backgroundColor: event.backgroundColor}, ss.default]
        Text
          style: [s.textCenter, {color: event.textColor}]
          event.raw.description

I'd love to see react native being consistent with react by providing React.DOM or a better name than DOM?

I'd love to contribute this if we agree with this point (and I hope so). React.DOM will include all current components. And which folder should the React.DOM code go?

[alinz]

Hmm... one of the benefit of using JSX is to write a very complex component in a declarative way. So I don't mind having a JSX compiler.

React and React-Native have other things in commons. Such as Component Life Cycle, triggering and registering events, and architecture. So in my point of view, having a DOM namespace make sense to differentiate the Web and Mobile devices.

I'd love you hear from other people.

[umhan35]

@alinz Without JSX, it can be declarative too in CoffeeScript. It's just an alternative. Thanks for the points in second paragraph.

[umhan35]

cc @vjeux because of this post: http://blog.vjeux.com/2013/javascript/react-coffeescript.html

[ide]

Why do you need React.DOM?

[umhan35]

Because I don't need to create short-hand factory functions for each component when I want to use them declaratively without JSX.

The name of DOM is questionable.

[vjeux]

You can do

render: function() {
  return React.createElement(View, {style: {backgroundColor: 'red'}});
}

to use React Native without JSX

[vjeux]

You could do at the top of the files,

c = React.createElement

...

render: ->
  c View,
    style:
      backgroundColor: 'red'

Not as pretty but still quite elegant

[ide]

Providing React.DOM doesn't really solve the problem because there's still the problem of creating elements for third-party components. Probably best to write your own helper like this:

var {
  View,
  Text,
} = require('create-react-factories')(require('react-native'))

[umhan35]

@vjeux As you said, it's not pretty... As you have more components, the clutter c adds up.

@ide The built-in components are used far more often than third-party components. So, it's very convenient to have React.DOM. Third-party components should usually be used in one place (if a third party component is used everywhere, probably we should incorporate in core), so using React.createFactory is ok.

[ide]

@vjeux and co. have the final say but I don't think it makes sense to add this to the core for a couple reasons. It's confusing if core components behave differently even though they otherwise look the same as third-party components. Also while totally ubiquitous components like Text and View belong in core, the majority of the other components in this repo aren't very different from third-party components. It's better for the ecosystem if a solution for MapView applies to react-native-camera's Camera too.

[umhan35]

@ide Sorry, I don't quite understand. Why would adding React.DOM makes it "confusing if core components behave differently even though they otherwise look the same as third-party components". If a third-party component has the same look as a built-in view, their different names can help differentiate them. I also didn't catch this: "the majority of the other components in this repo aren't very different from third-party components" and the last sentence...

I don't see much problem with the namespace thing: React.DOM. It's simply that we enjoy the elegance and readability given by JSX without using JSX that natively uses JS. It's more of an alternative to JSX. 😉

[ide]

Why would adding React.DOM makes it "confusing if core components behave differently even though they otherwise look the same as third-party components".

Take a handful of components: View, Image, Camera, ListView. It's not intuitive to identify which ones let you write Component({style: ...}, child1, child2).

the majority of the other components in this repo aren't very different from third-party components

My point is that I wouldn't be able to tell you that ListView or Navigator are first-party components while Camera or Video are third-party components without background knowledge. There's nothing intrinsic to these components that warrants a different syntax for constructing them.

Something like React.DOM adds a second syntax for a use case that can be addressed with a helper module in a pretty straightforward way (require('create-react-factories') in my comment above). I think the core repo is at the right place now where it makes it possible to create factory functions but doesn't necessarily support this uncommon use case out of the box.

[umhan35]

Take a handful of components: View, Image, Camera, ListView. It's not intuitive to identify which ones let you write Component({style: ...}, child1, child2).

Um... Mixing JSX and non-JSX is a bad practice. When requireing them (either from React or React.dom), we already know how to use them (either <Component> or Component style: ...).

My point is that I wouldn't be able to tell you that ListView or Navigator are first-party components while Camera or Video are third-party components without background knowledge. There's nothing intrinsic to these components that warrants a different syntax for constructing them.

Again, mixing JSX and non-JSX is a bad practice. If someone sticks to JSX, all components should be imported from React rather than React.DOM. If someone sticks to non-JSX and want to import third-party components, always call React.createFactory. And if multiple React.createFactorys are called for a component, you can opt to put it somewhere or wrap it (with adaptor pattern?) to promote DRY principle.

As the title of this issue says, it's about using react native without JSX. And also having React.DOM is being consistent with React.js which has the non-JSX support since first release. Using react native without JSX is a big alternative and there should be an option for this. In React.js's doc (http://facebook.github.io/react/docs/displaying-data.html#react-without-jsx), this has been repeatedly emphasized.

For the use cases, providing React.DOM is more like providing tooling support. Not providing React.DOM discourage people from using RN without JSX and this partly leads to the rare cases. If there is no IDE for Java, I think some people will be reluctant to write Java anymore.

[ide]

And if multiple React.createFactorys are called for a component, you can opt to put it somewhere or wrap it (with adaptor pattern?) to promote DRY principle.

This is a good idea. I just think it should be applied uniformly across all composite components. I'm not proposing to mix JSX and non-JSX; what I'm trying to say is that mixing uppercased composite-component classes and composite-component factories makes things more confusing. Maybe there should be lowercased <view> and <text> that act as primitive components, but I think it's easier to explain to someone that they always receive component classes and can convert them to factories with a helper module.

[brentvatne]

Hi there! This issue is being closed because it has been inactive for a while.

But don't worry, it will live on with ProductPains! Check out it's new home: https://productpains.com/post/react-native/discussion-react-native-without-jsx

[nscarcella]

In case anyone ends up on this issue (as I did) looking for a nice way of creating react-native components without JSX, you may want to check NJSX.
It is quite easy to customize and we built it around plain react/react-native, so it does not require any changes on the react-native framework to work.