So I've been doing a spike test with a project where I'm trying to use React.js to build a front-end to a Django application. The bulk of this application is basic Django forms, posts, page-loads, etc. but there's a number of complex views for scheduling, content uploading etc. As of now I think I'm willing to say that React is going to become part of my toolbox. There are definitely some issues that I gather Facebook has addressed in their "Flux" framework, but that seems to go a bit too far for me.

Things I wish had been in the tutorial:

• You need to use a separate "storage" somewhere or you will go mad with passing around object references, callbacks, etc.
• You do *not* want to embed ajax calls in your components, they should all be in storage operations
• Your storage objects need to have ways to update the components that reference the data within them, this is basically a matter of doing a setState() on each component that is using the data within them (often only top-level views will need that registration, though any controls such as db-populated selects may need it as well)
• Do not modify this.state directly, always call setState()
• Component state is for "how am I currently displaying this control" (think sort order, filtering options, etc), it should *not* be used for model data AFAICS
• You will be calling function(){ }.bind(this) a *lot*
• There really are no built-in ways to make custom bubbling events, don't spend a day looking for them
• Drag and drop can be done with standard HTML5, but it's not something that's integrated, and it's a bit of a PITA
• Your components will likely want to use callbacks in props if you want them to be reusable, think "action on change" or "action on drop" rather than coding the component to directly update the target values; but premature reusability is an anti-pattern
• If you want to use React.DOM directly instead of jsx transformations, the pattern is RD.div( properties, child, child, child,... ) and child can be RD.* or component instances created with ClassName( properties )
• You can pass Django URLs on a specially designated HTML node (name it #url-conf or whatever) and use that to instantiate your storage object URL references (particularly for root storages, the things that provide the base object-set when a page is loaded)
• There isn't, AFAICS, a clean, documented, way to refer to a React node (like a jquery .data() call) in such a way that you can get a reference to the component back from low-level HTML operations such as Drag and Drop

And that's about it. It's a nice-enough system so far, and the "just re-render it and we'll take care of actual DOM updates" promise does seem to bear out. The GUI is quite snappy-feeling and the separation of code between rendering and modelling is clean. Using React.DOM directly seems reasonable, though obviously most people are going to use the jsx transformations. I'm not blown away by it, but it is cleaner than the way I've been doing these views before, and it seems worth exploring futher.