Just imagine any non-trivial set of relationships in the underlying data, and then some rendered content that doesn't just depend on individual data points.
For the record, I haven't actually seen anyone address my earlier example with the sorted/filtered/paginated table yet.
Another typical example might be a complicated form where some fields are shown or hidden or have different options available depending on the values of other fields, perhaps including circular dependencies.
Another might be some sort of dashboard that adds a tab/tile/panel for each of some varying set of data sources and adjusts the layout or level of detail depending on how many sources need to be included.
Another might be rendering a chart showing several different data series over time, where the scales and positions of the axes are adapted to span the entire data set.
Of course you could manually update the DOM in response to relevant changes in the data in all of these cases, but keeping track of all the different variations and transitions gets old very quickly once your UI has a few different cases like this.
I think I understand what you're getting at - correct me if I'm wrong.
React's templating allows you to execute arbitrary JS logic when rendering, which is more versatile than simple one-way data binding.
My thoughts there are that I'd probably extract the logic first into the view model before passing the buck to the templater. For example, instead of filtering/sorting a collection in the template, I'd create a `normalizedCollection` computed property in the view model first (which helps with testing as well). In practice I've found that Rivets' binders are enough - showing/hiding/looping over data covers nearly every UI.
In the case of bigger chunks getting un/re-rendered (such as adding tabs/tiles/panels), you can take advantage of a framework that does sub-view management (such as Marionette[1]).
Computed properties can solve the hidden fields and multi-data series chart problem you mentioned.
React's templating allows you to execute arbitrary JS logic when rendering, which is more versatile than simple one-way data binding.
Yes, that's what I'm getting at here. In particular, you only have to write that arbitrary JS logic once to cover both the rendering and all the updating cases, so you get the same kind of automagic monitoring in your view that data binding gives but in the general case.
As an aside, nothing about React precludes using a separate view-model style layer between your base data model and the rendering logic to deal with computing derived information. Indeed, this is often useful as a form of cache if you have computationally expensive work to do when certain source data changes, for example to summarise a large data set or compute the layout for some complex visualisation. Again, computed properties seem to be a variation on this theme.
No doubt there are other ways to achieve the desired results, though inevitably they need their own version of plumbing to connect everything up, and in quite a few that I've seen over the years it's still difficult to co-ordinate updates and maintain good performance as systems scale up.
The main advantages of a library like React, in my experience at least, are that it is simple and universal in its design and interface, but also reasonably transparent about both behaviour and performance characteristics, with enough hooks that you can help it out in cases where the basic usage is inadequate.
For the record, I haven't actually seen anyone address my earlier example with the sorted/filtered/paginated table yet.
Another typical example might be a complicated form where some fields are shown or hidden or have different options available depending on the values of other fields, perhaps including circular dependencies.
Another might be some sort of dashboard that adds a tab/tile/panel for each of some varying set of data sources and adjusts the layout or level of detail depending on how many sources need to be included.
Another might be rendering a chart showing several different data series over time, where the scales and positions of the axes are adapted to span the entire data set.
Of course you could manually update the DOM in response to relevant changes in the data in all of these cases, but keeping track of all the different variations and transitions gets old very quickly once your UI has a few different cases like this.