10 ms·

Thank you for the thoughtful replies. It helps a lot in understanding the kinds of problems React was facing. With all due respect, > For this reason, you rea

by ww520 2y ago

Thank you for the thoughtful replies. It helps a lot in understanding the kinds of problems React was facing. With all due respect, > For this reason, you really are writing a pure function with respect to props and state. A pure function by definition is one which returns the same output for the same input. The output (html) of the React functional component with the same props can be different based on the changed state. It is not a pure function. It's really no different from an OO object with internal state. > There's no difference in handling state update ordering between React and others. > > it is not possible to read an intermediate value. There is no intermediate value. All value changes are in the final form as there is no multi-threads reading and mutating the state. The block of code mutating the value is executed fully before another block of code can read it. As for multiple handlers reading and rendering the state and some might miss the change by another handler, again it's a problem of React's inability to detect change for each handler. If every handler can detect change by any other code (other handlers included), there's no problem. > That's because React is built in a way to provide a set of very specific guarantees when it comes to managing state and rendering it. React requires that set of guarantees because its design decision - its use of diff to detect changes. It's a non-issue in other frameworks and solutions.

phailhaus 2y ago
> A pure function by definition is one which returns the same output for the same input. Yes, and the input includes state. React manages it and sets it before your function runs; your function then reads those values when it calls the hooks, and it is read-only. If I adjusted the React syntax to pass in state as a function argument instead, wouldn't you agree that it is pure? It's the same! Just because it's not passed in via arguments does not mean it is not an input. And a pure function is still pure even if the caller is stateful. Consider the "rules of hooks" in React: you cannot conditionally use a hook, and hooks must be used in the same order every time. That's exactly the same as regular arguments, making them functionally identical but with better dev ergonomics. That's on purpose: state is an input, but having it passed via function arguments would suck to use. Question: have you written any React components? This is a basic rule that is one of the first things you learn: components should be pure functions with respect to props and state. They're not even allowed to set state as a side-effect. If you're still convinced it's not pure, can you tell me how a component function's output can change given the same props and state? > The block of code mutating the value is executed fully before another block of code can read it. And that's the problem: with arbitrary code, there is no such thing as a distinct "block of code". One function can read value A, set it to B, then call another function, which sees value B, does something as a result, and then it renders. But that's wrong: value B has not been persisted to the DOM yet, so it should not have been read by the second function. Now you're in trouble, because your component is behaving as if both A and B are true at the same time. This is not possible with React. But to pull that off, they had to externalize state and make it read-only to your component.
- ww520 2y ago
  > Yes, and the input includes state. ... state is an input. This is the same argument that the member variables of an OO object are additional input to its member method and the method is "pure." > how a component function's output can change given the same props and state? This is the same argument that given the same values of the member variables of an OO object and the same method arguments to its member method, the method returns the same value. All these are just twisting the meaning of words and concepts to fit the square React into a functional round hole. > a basic rule that is one of the first things you learn: components should be pure functions with respect to props and state. You can certainly mutate the state in a React component; otherwise, what's the purpose of [.., setXX] = useState()? If such a "rule" is so important, why don't React remove the ability? BTW, the "rules of hooks" are another set of extra burdens. All these rules imposed on the programmers are there due to React's weak design. > And that's the problem: with arbitrary code, there is no such thing as a distinct "block of code". One function can read value A, set it to B, then call another function, which sees value B, does something as a result, and then it renders. But that's wrong: value B has not been persisted to the DOM yet, so it should not have been read by the second function. Now you're in trouble, because your component is behaving as if both A and B are true at the same time. If every renderer can detect every single update of a variable/state, the above is a non-issue. Function1 can set v1 to A. The renderer detects the change to v1 and renders it as A. Function2 set v1 to B; the renderer detects it and renders it to B. Function1 and Function2 can be called in any order; the rendering output is consistent with the state. The renderer might be called twice but who cares the eventual outcome is the same (certainly there're memorizing optimization to avoid re-rendering). It's really React's weak design causing all the out-of-sync rendering problems.

by ww520 2y ago

phailhaus 2y ago

> A pure function by definition is one which returns the same output for the same input. Yes, and the input includes state. React manages it and sets it before your function runs; your function then reads those values when it calls the hooks, and it is read-only. If I adjusted the React syntax to pass in state as a function argument instead, wouldn't you agree that it is pure? It's the same! Just because it's not passed in via arguments does not mean it is not an input. And a pure function is still pure even if the caller is stateful. Consider the "rules of hooks" in React: you cannot conditionally use a hook, and hooks must be used in the same order every time. That's exactly the same as regular arguments, making them functionally identical but with better dev ergonomics. That's on purpose: state is an input, but having it passed via function arguments would suck to use. Question: have you written any React components? This is a basic rule that is one of the first things you learn: components should be pure functions with respect to props and state. They're not even allowed to set state as a side-effect. If you're still convinced it's not pure, can you tell me how a component function's output can change given the same props and state? > The block of code mutating the value is executed fully before another block of code can read it. And that's the problem: with arbitrary code, there is no such thing as a distinct "block of code". One function can read value A, set it to B, then call another function, which sees value B, does something as a result, and then it renders. But that's wrong: value B has not been persisted to the DOM yet, so it should not have been read by the second function. Now you're in trouble, because your component is behaving as if both A and B are true at the same time. This is not possible with React. But to pull that off, they had to externalize state and make it read-only to your component.

ww520 2y ago
> Yes, and the input includes state. ... state is an input. This is the same argument that the member variables of an OO object are additional input to its member method and the method is "pure." > how a component function's output can change given the same props and state? This is the same argument that given the same values of the member variables of an OO object and the same method arguments to its member method, the method returns the same value. All these are just twisting the meaning of words and concepts to fit the square React into a functional round hole. > a basic rule that is one of the first things you learn: components should be pure functions with respect to props and state. You can certainly mutate the state in a React component; otherwise, what's the purpose of [.., setXX] = useState()? If such a "rule" is so important, why don't React remove the ability? BTW, the "rules of hooks" are another set of extra burdens. All these rules imposed on the programmers are there due to React's weak design. > And that's the problem: with arbitrary code, there is no such thing as a distinct "block of code". One function can read value A, set it to B, then call another function, which sees value B, does something as a result, and then it renders. But that's wrong: value B has not been persisted to the DOM yet, so it should not have been read by the second function. Now you're in trouble, because your component is behaving as if both A and B are true at the same time. If every renderer can detect every single update of a variable/state, the above is a non-issue. Function1 can set v1 to A. The renderer detects the change to v1 and renders it as A. Function2 set v1 to B; the renderer detects it and renders it to B. Function1 and Function2 can be called in any order; the rendering output is consistent with the state. The renderer might be called twice but who cares the eventual outcome is the same (certainly there're memorizing optimization to avoid re-rendering). It's really React's weak design causing all the out-of-sync rendering problems.