I have to plead ignorance here. Does it have a way of detecting circular events?

amelius · on Feb 14, 2021

The idea is to separate the state of the application from the presentation, which in practice leads to not having circular dependencies in the first place. And you can update the display after all changes are finished, so you won't get the flashing xmas tree effect.

TeMPOraL · on Feb 14, 2021

I thought TFA meant flashing in the metaphorical sense - it's the code paths that light up, not things on the screen.

Circular dependencies are an unfortunate fact of life, and I wish we had tools to deal with them, instead of desperately trying to avoid them.

A good test for a UI paradigm is, how do you handle a UI like this:

  A = [50] [====|     ]
  B = [10] [|         ]
  C = [60] [=====|    ]
  A + B = C

Where [===| ] things are sliders, all three are changeable, and the relation A+B=C must always hold.

kilburn · on Feb 14, 2021

The problem is under-specified. When you move a slider, how should the other two adjust? There are many possible solutions and you haven't specified any preference here.

The easiest solution is to maintain a fixed order of preference, something like:

  values = [a:0, b:0, c:0]
  fn onChange(key, value) {
    values[key] = value
    for (k,v) in values {
      if (k !== key) values[k] = adjust(k)
    }
  }
  fn adjust(key) {
    switch(key) {
      case 'a': return max(0, values[c] - values[b])
      case 'b': return max(0, values[c] - values[a])
      case 'c': return values[a] + values[b]
    }
  }

The alternative is to maintain the latest selections made by the user and use that as the iteration order.

Whatever approach you go with, the "single source of truth" approach of react/vue/svelte + state (whether it is state in hooks, redux, mobx or whatever) holds. The "values" above is the source of truth, and the components just reflect that.

In other words: from a state point of view you don't have three sliders each with a value but a "three-valued component that happens to be shown as three sliders".

amelius · on Feb 14, 2021

You can add a constraint solver on top of it. So when e.g. C changes, you solve for A and B. You then update the state of A, B, C and redraw. This kind of interaction can be handled by a separate library which is not necessarily part of a GUI system.

auggierose · on Feb 14, 2021

A constraint solver is overkill here, in particular as you cannot solve for A and B uniquely, you might want to add some further rule, like A and B should grow proportionally, when C is modified.

But otherwise, yes, just use a framework that separates State from UI and has bidirectional updates, like SwiftUI.

diggan · on Feb 14, 2021

React itself doesn't have any way of "listening" to events, so the data is only flowing in one direction always. Redux et al introduces more things on top of that, where you can fire off events ("Actions" in Redux terms) that react/trigger other events, but doesn't really have anything to do with React itself.

Then that some people make React components change state on render/mount/update, is a different failure, but not really a failure of React as much as a failure of the one using React.

But in general no, React doesn't really prevent you from having a component updating and re-rendering because some state changed, and because of that, changes the state again and thus re-renders again, forever.