4 ms·

Out of curiosity, one reason the author mentions (and I know, it's not his selling point) which I've seen others reiterate is that React's render() method doesn

Out of curiosity, one reason the author mentions (and I know, it's not his selling point) which I've seen others reiterate is that React's render() method doesn't support if statements. I know you can write something like the code below in React, so what exactly does that criticism refer to? function Home(props) { return ( <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> { (() => { if (props.location.query.home) { return ( <p>You specified a home query: { props.location.query.home }</p> ); } else { return ( <p>No home query was specified.</p> ); } })()} </div> ); }

M4v3R 10y ago
Yeah, it's possible in React do to it. But compare that to how Vue handles conditionals: <template> <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> <p v-if="location.query.home">You specified a home query: {{location.query.home}}</p> <p v-else>No home query was specified </p> </div> </template> I don't know about you, but to me this code is 100% more readable than the React example you gave.
- insin 10y ago
  This is how I've come to write that in React, after giving up on attempting to find a consistent way to write ternaries which I would find acceptable when revisiting them (it just never happened): let Home = ({location}) => <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> {!location.query.home && <p>No home query was specified.</p>} {location.query.home && <p>You specified a home query: {location.query.home}</p>} </div> I usually put all the possible negative cases first because outside of micro-snippets they tend to be short and sweet compared to the positive condition.
  - bestest 10y ago
    Come on people. It's so much simpler: return ( <div> <h2>hello</h2> { location.query.home ? <div>foo</div> : <div>bar</div> } </div> ) Or just replace that with a one-liner like, and put the respective code where it belongs: {location.query.home ? this.renderHomeStuff() : this.renderEtcStuff()} And simple ifs are obvious: <div> <h2>hey</h2> {foo && <div>foobar</div>} </div> Always strive to make your render methods simpler.
- straye 10y ago
  It's strange to me to embed conditions in attributes - particularly the v-else case in a different tag. It requires several visual scans of the block of code to determine what's going on. In my opinion the following requires less cognitive overhead: function Home(props) { var query = props.location.query.home ? ( <p>You specified a home query: { props.location.query.home }</p> ) : ( <p>No home query was specified.</p> ); return ( <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> {query} </div> ); }
  - straye 10y ago
    This also works: function Home(props) { return ( <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> { props.location.query.home ? ( <p>You specified a home query: { props.location.query.home }</p> ) : ( <p>No home query was specified.</p> ) } </div> ); }
- hokkos 10y ago
  Mixing tag and conditionals in attributes is so messy, I don't know how people accept that. It messes with the level of the scope, you can't quickly see that only one of the <p> will be outputted.
- unsoundInput 10y ago
  What bothers me about this and other templating is that branching is so inconspicuous and therefore hides its complexity . Lets takes this extended example: <template> <div> <h2 class="c-section-heading">HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> <p v-if="location.query.home">You specified a home query: {{location.query.home}}</p> <a v-else v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a> </div> </template> And compare it to: <template> <div> <h2 class="c-section-heading">HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> <p>You specified a home query: {{location.query.home}}</p> <a v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a> </div> </template> The first one creates a div with 3 children with the type of the last one depending on the condition. The second one creates a div with 4 children (and a warning in the dev console). Both have 4 lines between the <div> with the same content except for two attributes on two elements and are indented the same by convention of the framework. They look nearly identical when quickly parsing over them but results are very different. Compare this to the other react solutions, or my personal favorite: const Home = ({location}) => <div> <h2 className="c-section-heading">HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> {location.query.home ? <p>You specified a home query: {location.query.home}</p> : <a onClick={specifyHomeQuery} className="u-warn">No home query was specified.</a>} </div> I think it's pretty clear which "templating system" better represents the fact that this has more complexity than just a simple, linear component.
Rooster61 10y ago
Although I am admittedly fairly green when it comes to using React (full disclosure, I use Flux to manage state), I am unsure as to why you would NEED or want to handle conditional forks within the view itself. My understanding of React was that conditions such as this should be handled by whatever is managing the state of the component, be it a method call within your view that alters your the local state, or a store based system such as Flux/Redux where the state is handled outside the view itself. Part of what makes React a beautiful framework (to me) is the concept of a state which controls what is rendered. Controlling what is rendered directly from the render method in the view seems to defeat one of the purposes of using a stately framework such as React in the first place. Sort of a cart-leading-the-horse situation. Again, though, I am new to this framework (and JS frontend development in general) so please feel free to correct me.
fbonetti 10y ago
To be fair, writing if statements in JSX is messier than it should be, but this is the fault of JavaScript and not JSX. If statements don't return anything, so we have to either create an immediately executed anonymous function (like you showed) or use a ternary operator. I'm pretty sure the author knows that you can put if statements in JSX but is frustrated that it requires boilerplate, which I think is a valid criticism. That being said, I greatly prefer using plain JavaScript over custom DSLs like Mustache.
- joatmon-snoo 10y ago
  I can see that. I just wasn't sure, because every time a React debate gets kicked off, I inevitably see the "doesn't support if-else" thing get brought up, and having finally worked through a MWE with it, wasn't sure if it was just the (somewhat) convoluted syntax or whether I was missing something bigger.

M4v3R 10y ago

Yeah, it's possible in React do to it. But compare that to how Vue handles conditionals: <template> <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> <p v-if="location.query.home">You specified a home query: {{location.query.home}}</p> <p v-else>No home query was specified </p> </div> </template> I don't know about you, but to me this code is 100% more readable than the React example you gave.

insin 10y ago
This is how I've come to write that in React, after giving up on attempting to find a consistent way to write ternaries which I would find acceptable when revisiting them (it just never happened): let Home = ({location}) => <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> {!location.query.home && <p>No home query was specified.</p>} {location.query.home && <p>You specified a home query: {location.query.home}</p>} </div> I usually put all the possible negative cases first because outside of micro-snippets they tend to be short and sweet compared to the positive condition.
- bestest 10y ago
  Come on people. It's so much simpler: return ( <div> <h2>hello</h2> { location.query.home ? <div>foo</div> : <div>bar</div> } </div> ) Or just replace that with a one-liner like, and put the respective code where it belongs: {location.query.home ? this.renderHomeStuff() : this.renderEtcStuff()} And simple ifs are obvious: <div> <h2>hey</h2> {foo && <div>foobar</div>} </div> Always strive to make your render methods simpler.
straye 10y ago
It's strange to me to embed conditions in attributes - particularly the v-else case in a different tag. It requires several visual scans of the block of code to determine what's going on. In my opinion the following requires less cognitive overhead: function Home(props) { var query = props.location.query.home ? ( <p>You specified a home query: { props.location.query.home }</p> ) : ( <p>No home query was specified.</p> ); return ( <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> {query} </div> ); }
- straye 10y ago
  This also works: function Home(props) { return ( <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> { props.location.query.home ? ( <p>You specified a home query: { props.location.query.home }</p> ) : ( <p>No home query was specified.</p> ) } </div> ); }
hokkos 10y ago
Mixing tag and conditionals in attributes is so messy, I don't know how people accept that. It messes with the level of the scope, you can't quickly see that only one of the <p> will be outputted.
unsoundInput 10y ago
What bothers me about this and other templating is that branching is so inconspicuous and therefore hides its complexity . Lets takes this extended example: <template> <div> <h2 class="c-section-heading">HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> <p v-if="location.query.home">You specified a home query: {{location.query.home}}</p> <a v-else v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a> </div> </template> And compare it to: <template> <div> <h2 class="c-section-heading">HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> <p>You specified a home query: {{location.query.home}}</p> <a v-on:click="specifyHomeQuery" class="u-warn">No home query was specified</a> </div> </template> The first one creates a div with 3 children with the type of the last one depending on the condition. The second one creates a div with 4 children (and a warning in the dev console). Both have 4 lines between the <div> with the same content except for two attributes on two elements and are indented the same by convention of the framework. They look nearly identical when quickly parsing over them but results are very different. Compare this to the other react solutions, or my personal favorite: const Home = ({location}) => <div> <h2 className="c-section-heading">HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> {location.query.home ? <p>You specified a home query: {location.query.home}</p> : <a onClick={specifyHomeQuery} className="u-warn">No home query was specified.</a>} </div> I think it's pretty clear which "templating system" better represents the fact that this has more complexity than just a simple, linear component.

Rooster61 10y ago

Although I am admittedly fairly green when it comes to using React (full disclosure, I use Flux to manage state), I am unsure as to why you would NEED or want to handle conditional forks within the view itself. My understanding of React was that conditions such as this should be handled by whatever is managing the state of the component, be it a method call within your view that alters your the local state, or a store based system such as Flux/Redux where the state is handled outside the view itself. Part of what makes React a beautiful framework (to me) is the concept of a state which controls what is rendered. Controlling what is rendered directly from the render method in the view seems to defeat one of the purposes of using a stately framework such as React in the first place. Sort of a cart-leading-the-horse situation. Again, though, I am new to this framework (and JS frontend development in general) so please feel free to correct me.

fbonetti 10y ago

To be fair, writing if statements in JSX is messier than it should be, but this is the fault of JavaScript and not JSX. If statements don't return anything, so we have to either create an immediately executed anonymous function (like you showed) or use a ternary operator. I'm pretty sure the author knows that you can put if statements in JSX but is frustrated that it requires boilerplate, which I think is a valid criticism. That being said, I greatly prefer using plain JavaScript over custom DSLs like Mustache.

joatmon-snoo 10y ago
I can see that. I just wasn't sure, because every time a React debate gets kicked off, I inevitably see the "doesn't support if-else" thing get brought up, and having finally worked through a MWE with it, wasn't sure if it was just the (somewhat) convoluted syntax or whether I was missing something bigger.