The enthusiasm around React is infectious and I'm thinking about integrating it into one of my projects but I can't quite tell what exactly it's supposed to be used for. Is it only for SPAs or is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side?
React seems kind of like an all-or-nothing approach. It seems like overkill if you just want to provide a little more structure to jQuery spaghetti code.
Can React be a competitor to, say, Knockout? React seems more in the realm of angular or ember to me.
> is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side?
This is more or less what I've been using it for at work. My general "rule" is that if I've got a form and any other field or set of fields depends on what's happening in another field or set of fields I try wrap both parts up into a React component (with as many subcomponents as necessary). I'm using react-rails[1] and creating custom form builder modules which I include in my main form builder class. The custom form builder methods just call react_component and pass in the form object as a property to the component so I get server-side rendering of the component and the same code gets reused client-side. Obviously it can be used for much more than dynamic forms, but for what I'm currently doing this is all I need.
> React seems kind of like an all-or-nothing approach. It seems like overkill if you just want to provide a little more structure to jQuery spaghetti code.
I've found that > 90% of my front-end bugs around forms involve fields that are somehow linked. Handling that with unstructured jQuery goes from easy to a horrible mess at a nearly exponential rate as the number of interacting parts increases linearly. React makes it really easy to keep track of state and have it flow downwards as properties to subcomponents. Obviously you can go way overboard with it and I wouldn't recommend it for everything, but the ability to use it in just one troublesome spot and nowhere else if that's all you need is really cool. It's the opposite of all-or-nothing. I have a very large application that uses it in about a dozen tricky places like dynamic lists of things. The rest of the application is just plain old server-side rendered HTML.
React works great in existing websites! Last time I checked, React is about the same size as jQuery minified and gzipped.
There are many benefits to using React in an existing website: a great developer experience, performance, avoiding jQuery spaghetti, ease-of-use, etc. It might be overkill to use React for just a few components, but if you want to move to React, then you can incrementally implement components using React and then switch over fully.
> Is it only for SPAs?
In my opinion, React is like the declarative jQuery. It works just as well for SPAs as it does for traditional websites.
React is the view layer only so it's not all-or-nothing. That means it can be implemented in a traditional PHP website that's been sitting around for 10 years. And it's not overkill at all, it brings sanity to code and makes it more maintainable. You'll be able to do more with less.
React is perfect for replacing turning your cooked spaghetti into dry pasta. Entropy for the win!
Interesting you draw the Knockout comparison. I'm pretty new to React, but have done a fair amount with Knockout. I find that I use the two in very similar ways. I know knockout has a large feature set and claims to be a VMMV (whatever that means), but in practice I used it mostly to go between some dynamic JSON and DOM.
Here's an example of a web application built with React, Express and Browser Express that defines the same UI components and routes for both the server and the browser:
React is really 2 things. One is an implementation of web components which makes it a competitor to Polymer and is is useful on almost any project. Secondly, React is an implementation of the Flux architecture (one-way data binding) which is most useful for SPAs, but doesn't disrupt a static site as much as Angular does.
React is not an implementation of the Flux architecture. Flux is an architecture that works well with react.
I would argue that the primary contribution from React is not the web component aspect but the declarative, immutable-friendly approach to UI rendering
> Is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side?
Not if you want to reuse the server-generated markup. You can use it for little pieces in an otherwise static page, but it needs to own rendering of those pieces.
React is more similar to jQuery than Knockout, but it abstracts away DOM manipulation. I'd say it's better than jQuery, but not as good as web components.
I have a slightly different view of the value of React. It's not the code of the library, per se, but the development patterns. These techniques will work anywhere. If you can get yourself to use them, then React (or anything that works the same way) will be a great boon for you. If not, then you might be better off with something else. Please excuse me for this explanation, which you might already be familiar with.
Imagine your data is in a tree. Go to the very lowest nodes on the tree. You should be able to imagine that rendering these nodes is quite easy. It's just simple data. Now move up a node. Rendering this node is just rendering the data at that level and telling the next level to render. Keep doing that until you get to the very top.
The rendering at every node is now very simple. It is also very easy to write tests for: You just need to make sure that the data in the node has been rendered and that the nodes below are present.
Of course, that's just rendering a static tree. How do we deal with dynamism? In it's simplest form, you don't. Instead, any time you want to change some data in your tree, make a new tree and then render that new tree. This has the advantage that it is very simple. You tree of data is immutable, and so you never have to worry about state changing. At every change you just re-render the entire tree.
Of course, that is costly, so we can be clever and notice that we don't have to re-render the entire tree. We just have to compare the first tree with the second and re-render the highest subtrees that have changed. React does this behind the scenes.
If you are trying to do a kind of hybrid approach of using react for some parts and not for others, this is actually one of the easiest ways to do it. If you want to update your data from the server, you simple make an endpoint for the data at the top of your React tree and every time you change something you make an Ajax call from that top node to get the new data. This will cause the tree to re-render fairly efficiently.
Of course, this doesn't solve all your problems, because often you don't want to get new data from your server, you just want to update data around your tree. In this case, you need to image every node as the top of a subtree. If you want to change the data in the subtree, you simply make a request to the top of the subtree to modify the data in that subtree. This causes the entire subtree to re-render.
So the main flow is that you have a tree of data which you render. Anytime you want to modify the data, you need to make a request up the tree (never sideways and almost never downwards).
These requests can be made in many ways, but the simplest is simply by passing a callback down the tree as a piece of data. You decide which node "owns" a piece of data and then you pass a callback for modifying that data down the tree. Anyone below can potentially call that callback, which will modify the data at the top of the tree and re-render the entire tree.
There are other ways of doing it. Passing a whole whack of callbacks can be tiresome. Flux, for instance, sets up a series of singleton objects that anyone can access. You make a request of the object, it creates a new tree of data and updates the top node of the tree. (Note: Highly simplified explanation to the point of being wrong ;-) ).
Anyway, the point of this is to say that, if you want to write code this way, then you should use React or something like it. If not, you should stay away, because you will make a huge mess.
React seems kind of like an all-or-nothing approach. It seems like overkill if you just want to provide a little more structure to jQuery spaghetti code.
Can React be a competitor to, say, Knockout? React seems more in the realm of angular or ember to me.