4 ms·

> In functional programming, functions are not allowed to do that. The only thing a function is allowed to do is return a value. Oh, yes, they are allowed to d

> In functional programming, functions are not allowed to do that. The only thing a function is allowed to do is return a value. Oh, yes, they are allowed to do that. You capture the effects into a list, and return the tuple of list and return value. If you feel like it, you wrap that into a monad to pretend you are only "returning" a single thing. > In FP functions can only rely on the parameters passed to it (it cannot refer to anything outside) and it should not do anything beyond return a value. You mean explicit parameters (props) and implicit parameters (context), right? I thing you forgot the latter. Implicit parameters have existed for quite a bit, for example in the reader monad. > In FP, functions can be called in any order (unless one function needs the return value of another), and the final result is not affected by the order. Yup, except if you write a bunch of functions and store them in a list with the intention of applying the result of the first entry of the list against the first entry of the list. Now, if you construct the list of functions as effects (by hiding them behind a monad) you find out that you need to call the effects in the same order as to construct the list of effects in the same order. This doesn't contradict FP, it contradicts your mental model of how React is supposed to work. > If you have state it is not FP, whether it is global or not. The state resides in the runtime executor, exactly like Haskell's IO monad. Again, this contradicts your mental model, not React or FP.

petilon 4y ago
I think you may be missing the forest for the trees. The point of FP is that you can glance at a function and say 'this is obviously correct' without having to work out the state and context of every call.
- ojkelly 4y ago
  But you can do that with algebraic effects. That’s kind of the point. You keep the clarity of declaring what you want to happen, and abstract the how to the effect handler.
  - petilon 4y ago
    None of that is true in React hooks. The negative sentiment towards hooks that you see here is because it is weird and complicated. Want to see how much simpler code can get when you code without React or any such fat frameworks? Take a look: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie... You just need to know JavaScript, HTML and CSS, not much else. The code is simple, and yet maintainable. No need for hooks, useEffect, useState, useMemo and all that crap.
    - _v7gu 4y ago
      How can you ever be sure that your state is valid when you’re putting it on the DOM? Worse yet, only parts of the state is stored there. I can’t really call this code simple since it had to resort to timing hacks to get its functionality in order. A random 250ms delay and bam, bugs you cannot reliably reproduce
      - petilon 4y ago
        Can you clarify what you mean here? What state is in DOM? Do you mean the state inherent in input elements? What timing hacks are you talking about?
        _v7gu 4y ago
        The first file I looked into was the combo box. This is what I consider to be a timing hack: private onDropDownMouseOver(ev: MouseEvent): void { if ((new Date()).getTime() < this.whenScrolled + 250) { // We automatically get a hover event when we scroll, ignore it in order to keep our current highlight. return; } const element = ev.target as HTMLElement; if (element.classList.contains('combo-dropdown-item')) { addClassExclusively(element, 'combo-highlighted'); } } Some event stores the time it has been fired, and this method checks that it has not been long since the firing. With react, which item has the highlight would have to explicitly be in the state and completely remove the need to do this optimization. And this is an example of what I consider state being stored in the DOM: private isDropDownVisible() { return isVisible(this.dropDown); } The view has logic that depends on whether the dropdown is visible, which is checked by dropdown.style.display !== none. Now any element in your page has the power to modify this component’s logic by modifying the DOM
- javcasas 4y ago
  No. The point of FP is "minimize state and effects so that the code is easier to understand", not "write it in FP style so that by magic is correct". For exactly the same reason OO is "put the code that manages the state near to the state and split it in manageable parts" and not "dog inherits from animal therefore the code is correct". Leave the faith at the church and approach code with science.
dgb23 4y ago
No matter how sophisticated the language we use to describe it: it’s still a bunch of side effects and state. If you’re fetching some data in a useEffect you might not get a result that day. If you’re updating something with setState, you are still managing state. UseState is a reference to a mutable object now. You’re simply not getting the same answer every time your now impure function is called. In order to do understand what’s happening you need to recreate the whole state. Which is exactly the same reason state management is hard as in OO or procedural. You might have a mental model that explains why it is still FP, but for all practical purposes of that paradigm it isn’t.
brabel 4y ago
Wow, I've never seen a reply that so thoroughly fails to address any of the points it's trying to reply to. When you reply to "in FP, functions cannot do that (change state anywhere)", you say "you are allowed to do that: capture the effects into a list, return the tuple of list and return value" without realizing you're saying exactly the same thing?! The distinction between "return value" and "return value plus some other thing" does not exist. What matters is that the function's only observable modification is in what it returns, be it one value of many. This is basic FP.
- javcasas 4y ago
  You return a tuple, which first element is the value the function would return (I/E "return jsx stuff") and the second value is a list of operations (effects) you intend to perform I/E "I intend to change this variable to value X", "I intend to run this external function when these values change". The function's only observable behavior is that it returns a tuple with JSX and some effect descriptors. No, this is not basic FP. This is somewhat advanced FP.

petilon 4y ago

I think you may be missing the forest for the trees. The point of FP is that you can glance at a function and say 'this is obviously correct' without having to work out the state and context of every call.

ojkelly 4y ago
But you can do that with algebraic effects. That’s kind of the point. You keep the clarity of declaring what you want to happen, and abstract the how to the effect handler.
- petilon 4y ago
  None of that is true in React hooks. The negative sentiment towards hooks that you see here is because it is weird and complicated. Want to see how much simpler code can get when you code without React or any such fat frameworks? Take a look: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie... You just need to know JavaScript, HTML and CSS, not much else. The code is simple, and yet maintainable. No need for hooks, useEffect, useState, useMemo and all that crap.
  - _v7gu 4y ago
    How can you ever be sure that your state is valid when you’re putting it on the DOM? Worse yet, only parts of the state is stored there. I can’t really call this code simple since it had to resort to timing hacks to get its functionality in order. A random 250ms delay and bam, bugs you cannot reliably reproduce
    - petilon 4y ago
      Can you clarify what you mean here? What state is in DOM? Do you mean the state inherent in input elements? What timing hacks are you talking about?
      - _v7gu 4y ago
        The first file I looked into was the combo box. This is what I consider to be a timing hack: private onDropDownMouseOver(ev: MouseEvent): void { if ((new Date()).getTime() < this.whenScrolled + 250) { // We automatically get a hover event when we scroll, ignore it in order to keep our current highlight. return; } const element = ev.target as HTMLElement; if (element.classList.contains('combo-dropdown-item')) { addClassExclusively(element, 'combo-highlighted'); } } Some event stores the time it has been fired, and this method checks that it has not been long since the firing. With react, which item has the highlight would have to explicitly be in the state and completely remove the need to do this optimization. And this is an example of what I consider state being stored in the DOM: private isDropDownVisible() { return isVisible(this.dropDown); } The view has logic that depends on whether the dropdown is visible, which is checked by dropdown.style.display !== none. Now any element in your page has the power to modify this component’s logic by modifying the DOM
javcasas 4y ago
No. The point of FP is "minimize state and effects so that the code is easier to understand", not "write it in FP style so that by magic is correct". For exactly the same reason OO is "put the code that manages the state near to the state and split it in manageable parts" and not "dog inherits from animal therefore the code is correct". Leave the faith at the church and approach code with science.

dgb23 4y ago

No matter how sophisticated the language we use to describe it: it’s still a bunch of side effects and state. If you’re fetching some data in a useEffect you might not get a result that day. If you’re updating something with setState, you are still managing state. UseState is a reference to a mutable object now. You’re simply not getting the same answer every time your now impure function is called. In order to do understand what’s happening you need to recreate the whole state. Which is exactly the same reason state management is hard as in OO or procedural. You might have a mental model that explains why it is still FP, but for all practical purposes of that paradigm it isn’t.

brabel 4y ago

Wow, I've never seen a reply that so thoroughly fails to address any of the points it's trying to reply to. When you reply to "in FP, functions cannot do that (change state anywhere)", you say "you are allowed to do that: capture the effects into a list, return the tuple of list and return value" without realizing you're saying exactly the same thing?! The distinction between "return value" and "return value plus some other thing" does not exist. What matters is that the function's only observable modification is in what it returns, be it one value of many. This is basic FP.

javcasas 4y ago
You return a tuple, which first element is the value the function would return (I/E "return jsx stuff") and the second value is a list of operations (effects) you intend to perform I/E "I intend to change this variable to value X", "I intend to run this external function when these values change". The function's only observable behavior is that it returns a tuple with JSX and some effect descriptors. No, this is not basic FP. This is somewhat advanced FP.