41–50 of 98 posts
Ooof. That does not seem like an efficient replacement for promises. Blocking the world while you wait for i/o just seems like a recipe for poor performance. Or did I misunderstand this?
Hooks are not functional. The most elementary rule of functional programming is no state and no side effects. If you break these rules and justify your rule-breaking by pointing to esoteric concepts then you're violating the spirit of functional programming. Thanks to React Hooks a whole generation of JavaScript programmers are being misled into believing they are doing functional programming when they're really not.…
IO isn’t (typically) functional, and neither is the IO monad. But like reference types in Clojure, it’s how you express “the world is stateful, my program usually is not, but for this exceptional case my program interfaces with the world.” I don’t think React hooks are a good way to signal that, but they’re one of the ways people who prefer FP in real world use do it. I think Redux type solutions are a better signal…
Hooks are not functional. The most elementary rule of functional programming is no state and no side effects. If you break these rules and justify your rule-breaking by pointing to esoteric concepts then you're violating the spirit of functional programming. Thanks to React Hooks a whole generation of JavaScript programmers are being misled into believing they are doing functional programming when they're really not.…
I don’t think I’ve ever seen anybody claim that hooks are ‘functional’ The fact that each time you call useState in a render method you get back a different value should be a clue. You have to have a fairly sophisticated/twisted mental model of a react component’s function signature as effectively including each of the hooks it requires to be able to mentally model hooks as pure functions. Hooks are a clever imperati…
That's not quite true. The linked story tries to explain Hooks as algebraic effects. Before Hooks, functional components were explained as "UI is a function of state". After Hooks, they are continuing on FP ideas as the justification or explanation of their design choices: https://overreacted.io/algebraic-effects-for-the-rest-of-us/
Earlier quoted context omitted.
Why is it important to not mislead a whole generation of JavaScript programmers into believing they are doing functional programming when they're really not?
Why is "doing functional programming" important?
Hooks are not functional. The most elementary rule of functional programming is no state and no side effects. If you break these rules and justify your rule-breaking by pointing to esoteric concepts then you're violating the spirit of functional programming. Thanks to React Hooks a whole generation of JavaScript programmers are being misled into believing they are doing functional programming when they're really not.…
I’ve personally never thought I was doing functional programming with React. I think of it more like borrowing from the functional programming paradigm to gain better control over state and corresponding UI behaviours and appearances, at least where it’s useful to do so, and otherwise it’s not very functional at all. It feels like a very borrowed term. There is heaps of non functional programming involved in React co…
That's an exercise in futility. If you are rendering read-only screens than you can use pure functions to render the screen. But if you need interactivity then attempting to add interactivity while using pure functions is counter-productive.
Earlier quoted context omitted.
> I too can't shake the feeling that hooks are off. Well the alternative to hooks is componentDidMount, componentDidUpdate, etc. It's a lot easier to sync state and UI when the logic for doing so can be put in one place.
I’ve been using hooks for a year, and they are awesome (once you get used to it). I can write the same component in 1/3 of the code in a functional style. The debugging story isn’t great if you expect to be able to use breakpoints. It’s all about putting console.log wherever really. The beauty comes in the speed of coding, I can move so fast that I always build a mock version of my api layer and can have the entire U…
I started learning React for starting a large project a few months ago. I have not really liked the experience very much. One seems to still need to know all the JS/CSS/HTML I've been using for 10+ years but also a new stack on top of it, simultaneously. Hooks are one of the strangest features I've seen in a language yet. I doubt they will be a lasting paradigm outside of the React ecosystem. I like JSX a lot. The id…
It wasn't overly complicated from a technical perspective, but when there were forms with say 50-100 different inputs and dozens of state transitions, it was a mentally taxing experience every time to try to maintain the data model and state machine in my head when debugging or introducing changes.
For me the introduction of hooks was amazing as it's allowed us to strip most of the redux state management in favour of managing state with hooks inside of functional components. We still use redux for global application state, but there are also hooks for interacting with that redux state too.
We effectively went from class-based components in react-redux with say 500 LOC in each class, 500 LOC in each action file, 500 LOC in each reducer file, all the way down to about 700 LOC in each functional component file.
I do agree though that debugging sucks. It's incrementally getting better, but it's got a long way to go.
Earlier quoted context omitted.
Why is "doing functional programming" important?
In JavaScript UI development it is not important, IMHO. So why do React developers keep pushing functional concepts, as if React is functional?
Earlier quoted context omitted.
Is OCaml functional?
Pure functional languages such as Haskell have some facilities to do things that are not 100% pure, such as I/O. Similarly, OCaml has effects, but functional programmers minimize their use of such impure facilities. Effects in OCaml are impure: "However, the effect system also allows for tracking side-effects more generally. It distinguishes impure functions, which perform side-effects, from pure functions, which do…
That's a great way of explaining it. But at the same time how can we say that Haskell is a "pure functional language" when Haskell programs consist of both pure and impure functions?
Yes they are separated which in other words means you do have both of them. Is that really "pure" then? Or is that more like 'as pure as possible"?
Earlier quoted context omitted.
I think hooks are more like applicative/arrow and are not monads. This ensures the shape is static and you cannot branch based on input. This also illustrates how weird it is to call function components pure. They’re not, there as effecful as can be!
Yeah I agree that morally the interface is applicative or arrow like but I didn’t think that provided an ergonomic programming interface which is most of the point of hooks (and the pain of arrows). Binds couldn’t really changed the shape of their output because of the second type parameter I described. Also, I don’t see a particular reason to disallow the default value of one state depending on the value of somethin…
type ('a, 'b) t = 'a Value.t -> 'b Computation.t
https://github.com/janestreet/bonsai/blob/master/docs/proc.m...
Gives a bit of an overview. There are some syntax extensions to make working with it a bit easier. But once grokked it seems to fit nicely, and feels like more of a solid foundation than React (imo).
Not all the examples have been updated to the new style, but here's one (albeit trivial) example: https://github.com/janestreet/bonsai/blob/master/examples/tw...