Update the homepage with ES6

[gaearon]

Sending this against master because it's independent and self-contained.

A few changes to unpack here:

• Updated it to use babel-standalone because it is much newer. This is already done in [docs] Use react-standalone #7668 but since that didn't get merged yet I'm just doing it here, and we can clean up other places as part of New Docs #7864. There were no other places where this particular hosted file was used.
• Changed homepage examples to use ES6 classes.
• Changed code editor to only show JSX transform but eval code with JSX+ES2015. Verified the eval'd code has ES2015 by console.log()-ing it.
• Tweaked the examples for better readability.
• Changed the render() to be at the top of Todos example so that you see it immediately and it matches what you see on the screen.
• Updated main README too.
• Trimmed extra newline at the beginning from the examples.

Here's how it looks now:

Compiled JS view:

[lacker]

Do you think it would be more similar to real usage if you used document.getElementById('root') or similar here, rather than mountNode?

[gaearon]

Yes, but this would require some further changes to how this page is set up (e.g. passing IDs as props to the code editor). Can do separately.

[lacker]

how about just using concat to avoid ...

[lacker]

Also - wasn't someone talking recently about, you shouldn't use this.state.foo in setState, because there's some race condition if you do it twice per update cycle? I really prefer the look of this code, but, I just want to make sure we're not suggesting something buggy.

[gaearon]

It used to be concat but it looked pretty crowdy and I thought this could save some space. IMO it's not hard to guess what it does even if you don't use ES6. But happy to change back to concat if you think that was better. (Many people don't know concat() exists or what it does either.) It's also not really the point of the example, and the code is more for illustrative purposes rather than for direct learning.

Also - wasn't someone talking recently about, you shouldn't use this.state.foo in setState

Ideally you shouldn't but the alternative is too much syntax noise for this example so I think it's okay.

[acdlite]

It's not quite a race condition, it's that setState is potential asynchronous and/or batched. I don't think it's a good idea for the official docs to implicitly communicate that this is okay. Nobody will know this is a problem unless we're explicit about it.

[acdlite]

Did we reach a decision on whether to use the updater form here or not? Even though it doesn't matter for a Timer where state is only updating once a second, people will see this and use it elsewhere.

[gaearon]

Fixed.

[acdlite]

It's not quite a race condition, it's that setState is potential asynchronous and/or batched. I don't think it's a good idea for the official docs to implicitly communicate that this is okay. Nobody will know this is a problem unless we're explicit about it.

[gaearon]

K, updated to address both concerns.

[GIARGIARI]

THANK YOU !

On Tuesday, October 4, 2016 2:18 PM, Andrew Clark <[email protected]> wrote:

@acdlite commented on this pull request.In docs/_js/examples/timer.js:> - this.setState({secondsElapsed: this.state.secondsElapsed + 1});

• },
• componentDidMount: function() {
• this.interval = setInterval(this.tick, 1000);
• },
• componentWillUnmount: function() {
  +class Timer extends React.Component {
• constructor(props) {
• super(props);
• this.state = {secondsElapsed: 0};
• }

• tick() {
• this.setState({

•  secondsElapsed: this.state.secondsElapsed + 1
  

• });
  Did we reach a decision on whether to use the updater form here or not? Even though it doesn't matter for a Timer where state is only updating once a second, people will see this and use it elsewhere.In docs/_js/examples/todo.js:> {'Add #' + (this.state.items.length + 1)}

);
}
-});
+

• handleChange(e) {
• this.setState({text: e.target.value});
• }

• handleSubmit(e) {
• e.preventDefault();
• var newItem = {

•  text: this.state.text,
  

•  id: Date.now()
  

• };
• this.setState({

•  items: [...this.state.items, newItem],
  

  It's not quite a race condition, it's that setState is potential asynchronous and/or batched. I don't think it's a good idea for the official docs to implicitly communicate that this is okay. Nobody will know this is a problem unless we're explicit about it.—
  You are receiving this because you are subscribed to this thread.
  Reply to this email directly, view it on GitHub, or mute the thread.

[lacker]

LGTM

[GIARGIARI]

THANK YOU !

On Tuesday, October 4, 2016 2:29 PM, Dan Abramov <[email protected]> wrote:

@gaearon commented on this pull request.In docs/_js/examples/timer.js:> - this.setState({secondsElapsed: this.state.secondsElapsed + 1});

• },
• componentDidMount: function() {
• this.interval = setInterval(this.tick, 1000);
• },
• componentWillUnmount: function() {
  +class Timer extends React.Component {
• constructor(props) {
• super(props);
• this.state = {secondsElapsed: 0};
• }

• tick() {
• this.setState({

•  secondsElapsed: this.state.secondsElapsed + 1
  

• });
  Fixed.—
  You are receiving this because you commented.
  Reply to this email directly, view it on GitHub, or mute the thread.

[GIARGIARI]

YOU ARE WELCOME !

On Tuesday, October 4, 2016 2:34 PM, Kevin Lacker <[email protected]> wrote:

LGTM—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[GIARGIARI]

On Tuesday, October 4, 2016 2:45 PM, CARMELO GIARGIARI <[email protected]> wrote:

YOU ARE WELCOME !

On Tuesday, October 4, 2016 2:34 PM, Kevin Lacker [email protected] wrote:

LGTM—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.