4 ms·
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 mor
by jiaweihli 10y ago
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.
[1] http://marionettejs.com/docs/v2.4.7/marionette.layoutview.html http://marionettejs.com/docs/v2.4.7/marionette.layoutview.ht...
- Silhouette 10y agoReact'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.