I would add:

1."now you have to create 10 functions to get input from 10 inputs".

Or you can learn JavaScript:

  handleChange(event) {
    this.setState({ [event.target.name]: event.target.value })
  }

Nobody forces you to use Redux.

https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

Dumb question but I've never seen this syntax before. What does it do or what is it called? (The brackets)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Most of the React community has forged forward with ES6/ES2015, so learning that is definitely a part of the process.

  var stateUpdate = {}
  stateUpdate[event.target.name] = event.target.value;
  this.setState=(stateUpdate);

FWIW, this is supported in the newest Chrome as well.

I wondered what the issue was myself, so I actually implemented that pattern in a codepen, then looked at the compiled form of the JSX to Javascript.

The essential issue is that the value of a prop is always evaluated at runtime, regardless of if the prop is actually used. In the case of props.children this means that <Then> and <Else> are both evaluated, and thus rendered, and only one of them is actually used.

Thus you can't have conditionally rendering children, unless you've written them to be okay with failing at a render, with a blanket state---which is what most people are trying to avoid writing into their components, and simply want to conditionally render in a higher level component.

https://www.npmjs.com/package/jsx-control-statements

Disclosure: self-promotion. It's really frustrating that I see this React-is-crap-because-no-conditionals come up again and again but if you want them all it takes is an npm install and a line of babel config :(.

    render() {
      return <If
        cond={ this.state.loggedIn }
        then={() => `Hello ${ this.state.userName }`}
        else={() => `Please log in` }
      />
    }

  {this.state.user.case({
    some: user => `Hello ${ user.name }`
    none: () => `Please log in`
  })}

https://twitter.com/Tholle1234/status/804796967222202372

return ( <Foo> { selected ? <Bar /> : null } </Foo> );

or

let children = []; if (selected) children.push(<Bar />); if (blah) children.push(<Blah />); return ( <Foo> { children } </Foo> );

or

const bar = selected ? <Bar /> : null; return ( <Foo> { bar } </Foo> );

It sounded more just like "we couldn't figure out how to make it work for us", which is a perfectly plausible position.

The author just stated that React didn't work for them, not that it's "impossible to use React" as you are implying.

From the article:

> I guess this level of strictness and purity is something that may be useful when you have 1000 devs in your company [...] But most of companies have far smaller dev teams and other goals than Facebook.

why would you do this in Angular? i thought the whole point was to use html templates in separate .html files. as for "magical" attributes, angular2 moved away from that and is using mostly native html attributes. i.e. [disabled]="x" [hidden]="x" (click)="myfunc()". Can't imagine it being more intuitive than this.

In React, there is no 'direction' of binding---its all one way, just like in vanilla Javascript, and in fact no binding on anything except low level elements' like divs. Components only receive props, which do not do anything at all until you write code that reads them and runs operations based on their values.

Thus components are simply function calls (it's what they compile to anyways), and JSX is just a syntax to write functional code.

JSX, on the other hand, is Javascript function calls. You're writing JS to describe the UI.

That's not a bad thing of course.

In practice, I've find that I now segregate heavy logic into it's own function, which ends up making my components very readable. The lack of first class support for conditionals as a part of JSX has forced me to encapsulate code better.

I would say the only trade-off I've noticed is I end up losing a little bit of DRY-ness here and there with some components having near identical functions. I think it's an acceptable trade off as long as functions are small.

  Mustache.render( "{{#loggedIn}}Hello{{userName}}{/loggedIn}}
   {{^loggedIn}}Please log in{{/loggedIn}}", state );

After all, we're not just displaying "Hello" or "Please log in" all day.

To answer you question, you use JS! Or PHP! Or any of the other 2 dozen languages Mustache supports. Mustache is all about logic-less templates, which by definition assumes the logic is being written elsewhere. Edited my example to make that clearer.

EDIT:

  const tpl = "{{#loggedIn}}Hello{{userName}}{/loggedIn}}{{^loggedIn}}Please log in{{/loggedIn}}";
  Mustache.render( tpl, state );

There is even a ClojureScript implementation: https://github.com/fotoetienne/cljstache

Yes mustache, JSX and all the other templating syntax aren't pretty, but my point was that Mustache is the best I've come across so far. elegance and simplicity are in the eyes of the beholder though, so to each their own.

[0]: https://www.youtube.com/watch?v=x7cQ3mrcKaY

I've spent decades telling people that trying to keep logic out of templates is a waste of time. A useful templating language has variables, conditionals, and even functions. There's no reason not to use a real programming language.

There's no good automated way to enforce MVC. How is an automated tool going to know whether "show this number to two decimal places" is a model thing (inherent precision of the data) or a view thing (presentation choice)?

I would prefer keeping presentation logic, or any logic for that matter, out of the HTML.

[1]: https://news.ycombinator.com/item?id=13153298

They are very readable... maybe people just dont like the "logic" in a tag... i guess... whatever, made for some really readable code...

  render() {
    return <div>
      {do {
        if (loggedIn) { <a>Logout</a>; } 
        else { <form onSubmit={ ... } />; }
      }}
    </div>
  }

    var o = {p: 42, q: true};
    var {p, q} = o;

    console.log(p); // 42
    console.log(q); // true

<component /> compiles to React.createElement('component') (html tag)

<Component /> compiles to React.createElement(Component)

<obj.component /> compiles to React.createElement(obj.component)