3 ms·

I don't get how your table example justifies the need for such a complex rendering pipeline. There are plenty of template libraries that can optimally re-rende

I don't get how your table example justifies the need for such a complex rendering pipeline. There are plenty of template libraries that can optimally re-render a list/table after row insert/remove/move operations. Events generated by elements in rows can easily be associated with the proper data item. React doesn't own declarative templating, and if you only use one-way databinding, and re-render only what changes (again, plenty of template libraries do this), you get `v=f(d)` and efficient updates. Why the extra complexity?

Silhouette 10y ago
The table was just an example. The point is that if you use a declarative rendering approach, any non-trivial rendered output you want to generate only needs to be specified once, relative to a neutral starting point. React certainly doesn't own the idea of declarative rendering, I agree, but what template libraries do you have in mind that offer that sort of functionality without either being limited to some specific case (tables, say), having questionable performance properties, or implementing the same sorts of techniques that virtual DOM-based libraries like React are using? Perhaps it would help if you could give some concrete examples of the libraries you are thinking of, and point at some documentation (or give your own example code) to show how they would handle the kinds of events I described in my post above more efficiently and/or with cleaner code than a library using declarative rendering and a virtual DOM such as React.
- jiaweihli 10y ago
  Are you thinking of computed properties? If so, there are many libraries that have solved this, e.g.: https://vuejs.org/guide/computed.html https://vuejs.org/guide/computed.html https://guides.emberjs.com/v2.3.0/object-model/computed-properties/ https://guides.emberjs.com/v2.3.0/object-model/computed-prop... When implemented using one-way data binding (as both of the examples do), this is more performant than DOM diffing.
  - Silhouette 10y ago
    No, I'm talking about arbitrary relationships in the underlying data model, such that arbitrary events from anywhere in the DOM can lead to arbitrary changes in rendering anywhere in the DOM. Computed properties of the kind you linked to, when then used to drive rendering via one-way data binding, are a common but relatively simple example. And yes, that sort of direct DOM manipulation is likely to be faster, often much faster, than DOM diffing in the cases it covers. The advantage of the more general diff-based libraries is their generality, not their rendering speed.
    - jiaweihli 10y ago
      Can you give an example of a more general problem that you see React solving better? The example you gave earlier doesn't fully answer this.
      - Silhouette 10y ago
        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.
        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 ago

The table was just an example. The point is that if you use a declarative rendering approach, any non-trivial rendered output you want to generate only needs to be specified once, relative to a neutral starting point. React certainly doesn't own the idea of declarative rendering, I agree, but what template libraries do you have in mind that offer that sort of functionality without either being limited to some specific case (tables, say), having questionable performance properties, or implementing the same sorts of techniques that virtual DOM-based libraries like React are using? Perhaps it would help if you could give some concrete examples of the libraries you are thinking of, and point at some documentation (or give your own example code) to show how they would handle the kinds of events I described in my post above more efficiently and/or with cleaner code than a library using declarative rendering and a virtual DOM such as React.

jiaweihli 10y ago
Are you thinking of computed properties? If so, there are many libraries that have solved this, e.g.: https://vuejs.org/guide/computed.html https://vuejs.org/guide/computed.html https://guides.emberjs.com/v2.3.0/object-model/computed-properties/ https://guides.emberjs.com/v2.3.0/object-model/computed-prop... When implemented using one-way data binding (as both of the examples do), this is more performant than DOM diffing.
- Silhouette 10y ago
  No, I'm talking about arbitrary relationships in the underlying data model, such that arbitrary events from anywhere in the DOM can lead to arbitrary changes in rendering anywhere in the DOM. Computed properties of the kind you linked to, when then used to drive rendering via one-way data binding, are a common but relatively simple example. And yes, that sort of direct DOM manipulation is likely to be faster, often much faster, than DOM diffing in the cases it covers. The advantage of the more general diff-based libraries is their generality, not their rendering speed.
  - jiaweihli 10y ago
    Can you give an example of a more general problem that you see React solving better? The example you gave earlier doesn't fully answer this.
    - Silhouette 10y ago
      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.
      - 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...