3 ms·

> You could argue that the real innovation of React was "unidirectional data flow" Isn't this just how the DOM works? Data flows down through attributes and pr

> You could argue that the real innovation of React was "unidirectional data flow" Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up? > but React team made Flow architecture central to the framework Didn't they call it Flux rather than Flow?

picardo 1y ago
> Didn't they call it Flux rather than Flow? Ah, you may be right. It's been a long time.
- remixff2400 1y ago
  Flow was a type checker (used to be Typescript vs. Flow debates early on before Typescript ended up with more support), Flux was the unidirectional data flow architecture.
picardo 1y ago
> Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up? That's right, but this communication pattern causes serious complexity. Imagine trying to find out what triggered a state change. You would have to listen to every event source to find out. With Flux, all state changes were mediated by the reducer in the store. It made things a lot simpler.
- aatd86 1y ago
  Shouldn't a state change should be purely event driven, and not dispatch its own events as side effect? That avoids reetrancy and is an easy rule to adopt...? Or am I misunderstanding the issue?
  - picardo 1y ago
    You're right about that, but that wasn't common practice at the time. We learned about side-effects from Elm and Flux.
flufluflufluffy 1y ago
The native DOM doesn’t have an idea of “data flow”, it’s just a big tree that you can modify in whatever way you see fit through its imperative API. For example you could add an event handler to a child node which directly modifies one of its ancestor nodes. With React, your “nodes” in the tree are functions. The child node has no idea about what its ancestors are, it only knows what it is passed as arguments (i.e. “props”). The only way implement a similar thing would be to raise the state/event handling code to the ancestor node, and passing relevant information down as props, thus giving the unidirectional data flow. Of course, if you really needed to, you could drop back down to the native DOM API, with React’s useRef and useEffect hooks, but the default behavior is this unidirectional data flow through function composition.
paulddraper 1y ago
There is no notion of components in the DOM (or at least there wasn’t, until after React), so there’s no sense of data flow. There is a DOM tree, but parents don’t pass data into or receive events from children.

picardo 1y ago

> Didn't they call it Flux rather than Flow? Ah, you may be right. It's been a long time.

remixff2400 1y ago
Flow was a type checker (used to be Typescript vs. Flow debates early on before Typescript ended up with more support), Flux was the unidirectional data flow architecture.

picardo 1y ago

> Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up? That's right, but this communication pattern causes serious complexity. Imagine trying to find out what triggered a state change. You would have to listen to every event source to find out. With Flux, all state changes were mediated by the reducer in the store. It made things a lot simpler.

aatd86 1y ago
Shouldn't a state change should be purely event driven, and not dispatch its own events as side effect? That avoids reetrancy and is an easy rule to adopt...? Or am I misunderstanding the issue?
- picardo 1y ago
  You're right about that, but that wasn't common practice at the time. We learned about side-effects from Elm and Flux.

flufluflufluffy 1y ago

The native DOM doesn’t have an idea of “data flow”, it’s just a big tree that you can modify in whatever way you see fit through its imperative API. For example you could add an event handler to a child node which directly modifies one of its ancestor nodes. With React, your “nodes” in the tree are functions. The child node has no idea about what its ancestors are, it only knows what it is passed as arguments (i.e. “props”). The only way implement a similar thing would be to raise the state/event handling code to the ancestor node, and passing relevant information down as props, thus giving the unidirectional data flow. Of course, if you really needed to, you could drop back down to the native DOM API, with React’s useRef and useEffect hooks, but the default behavior is this unidirectional data flow through function composition.

paulddraper 1y ago

There is no notion of components in the DOM (or at least there wasn’t, until after React), so there’s no sense of data flow. There is a DOM tree, but parents don’t pass data into or receive events from children.