?

Log in

No account? Create an account
Using react.js for the first time - mostly good, some bad - Greg [entries|archive|friends|userinfo]
Greg

[ website | gregstoll.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| * Homepage * Mobile apps (Windows Phone, Win8, Android, webOS) * Pictures * LJBackup * Same-sex marriage map * iTunesAnalysis * Where's lunch? ]

Using react.js for the first time - mostly good, some bad [Aug. 28th, 2015|11:04 pm]
Greg
[Tags|, ]
[Current Mood |contentcontent]

My JavaScript coding has been pretty basic in the past - I've gotten good at using jquery.com to hack together things that work, which has been plenty good enough for my side projects. Now that JavaScript frameworks and libraries are all the rage (here's a giant list of frameworks and libraries) I decided to learn React (or react.js), which I've heard some good things about.

Since I had just improved my baseball win expectancy finder and it was fresh in my mind, I decided to try to rewrite the whole thing in React. And I was able to do it in just two nights! If you're interested in looking at the code, here's the original jQuery-only version and here's the version in React.

I read a bunch of the React docs and thought I knew what I was doing, so I started to write it, then got confused/uncertain about how to approach it very quickly. Finally I read Thinking in React which made everything click for me and I was off to the races! I highly recommend the article.

So what's good and bad about React? Here's what I've found:
- Good: Changing the inputs (inning, number of outs, runners, etc.) to React was very natural. This is where React really shines - you just define how these things should render if they have a particular value. Here's what the code looks like for the runners combobox:

var RunnersOnBaseList = React.createClass({
handleChange: function(e) {
this.props.setRunners(e.target.value);
},
render: function() {
return

Runners on base: 
<select ... >
<option ... >none</option>
<option ... >1st</option>
/* etc. */
<option ... >loaded</option>
</select>

;
}
});
The key point here is that you're just responsible for setting the properties and state of things and defining how those component should look. React will figure out if anything has actually changed and re-render if so, since updating the DOM is notoriously slow. It's similar to data binding in XAML, although it's not two-way (more on that later). In the jQuery version of the code I have statements like $('#runners').val(runners); all over the place to set values, and it's just ugly.

- Good: React specifically plays nicely with other frameworks. So even in the React version of the page I still use jQuery to do the AJAX request, which is handy. I also use it for the highlight effect.

- OK: The way React handles events (like doing something when a button is clicked) is a little clunky - the parent components pass down callback functions to their children, and the children call them when appropriate. But that means if there are multiple levels of components you have to pass down callbacks to each of them.

- Bad: Getting the highlight effect after the AJAX request was done was a big pain. I'm pretty sure I went down the wrong track somewhere, but I'm not sure where. I tried to use the builtin animation stuff, but couldn't get that to work so I ended up checking in componentDidUpdate() whether any properties have changed, but only _certain_ properties...anyway, I struggled with it and the code is a mess. In jQuery this is extremely simple - just highlight the output after the AJAX request is done!

- Good: React lets you write code in JSX (although it's not required), which is basically JavaScript, but it lets you return HTML in each component's render() function that really looks like HTML. This makes writing components really nice.

- Bad: Debugging JSX isn't possible, at least not that I saw. You can run a JSX transformer to generate JavaScript and debug that, but that's an extra step between making a change and seeing if it works. At least if there's an error, Firefox will tell you what line number of the JSX it happened on, so that's something.
LinkReply