Djangocon: React.js workshop - Maik Hoepfel¶

Tags: djangocon

He compares react.js to angular. Angular basically want to take over your whole page. Multiple apps on one page, mixed with some jquery, isn’t really possible. You also have to learn a lot of terminology. It is a full stack framework. And angular 2.0 won’t have a migration path from angular 1.x…

React.js only does one thing and does it well: the view. It doesn’t do data fetching, url routing and so.

React.js is quite pythonic. You can start adding little bits at a time to your code. You cannot really do anything wrong with it.

A core idea is that the html is in one corner. That’s the output. And the state is in the other corner. They’re strictly seperated, which makes it easier to reason about.

It is build by facebook. They take page load time seriously. You can even run react.js partially on the server side (“react native”, inside node.js), taking down rendering time, especially on mobile. Facebook is pretty deeply invested in it, so the chances of it disappearing are low. (As opposed to angular: google is barely using it itself).

When you start using react.js on a page, you’ll have to start thinking about components. An “unordered list of results”, a “search box”. Those kinds of components.

• Component: basically a piece of html, handled by react. If react renders it, html comes out. It looks at its state and properties to render it (“it calls the .render() method”).

• State: the current state of the component. The component can change this.

  If you can do without state: do it. You’re better off calculating it from something else. And if it makes sense to store the state on a higher-level component: do it.

  If a component’s state changes, you can assume that the render method gets called (it does some magic so that it only updates html if there are changes).

• Properties: what you pass a component from the outside. Think parameters, like a list of products. The component cannot change these.

React.js code is quite simple to reason about as there’s a simple path through the code. If some method changes the state, react handles the rendering. The rendering might set up click handlers or other things. If such a click handler changes the state, react renders everything and so on and so on.

Integration with existing jquery plugins is generally possible, but you’d rather not do it. React.js tries to store state nicely in a corner and jquery plugins normally store state on the DOM itself. So watch out a bit. You might have to build some more custom html than you’d have to do otherwise as you’d just download one of the existing jquery plugins.

A note about facebook’s flux. “A flux” is just a structure for building large applications. There are multiple ones. He hopes you don’t have to build such a large application yet, as the flux you’re choosing might not be the one that wins out in the end.

If you need a good example of django and react.js, look at django-mediacat.

Question: “How do you integrate with django? Does django still render forms?” Answer: normally, you’d decouple the front-end and back-end, at least for the bits you let react.js handle. So perhaps generate some javascript variables in the django template. And grab the rest via an REST API.

Some clarification to the previous paragraph: you can choose yourself how much of the page you let react.js handle. He himself is using react.js to handle a couple of interactive elements on an otherwise-static django-rendered page.

Question: “Are you happy with react.js?”. Answer: “YES!”. It is quite small in scope. It doesn’t get in your way. Easy to get started with. You can’t do an awfully lot wrong (he has seen terrible examples with angular: it gives you much more rope to hang yourself with). You can progressively add interactivity to your page.

Tip: keep your react.js components small. Only let it handle spitting out html. Do any calculations you might have to do on the server side, behind your REST API.