Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Algebraic Effects for React Developers

reesew.io

Post reply on HN
Print view View original

21–30 of 98 posts

Re: Algebraic Effects for React Developers

#21

Post by unityByFreedom »

wbercx wrote: post #19
etaioinshrdlu wrote: post #4

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…

I too can't shake the feeling that hooks are off. I like JSX and the component model. In React and like-minded projects, I look at a stack trace and see that it starts at some kind of batch renderer. I can't tell "why", "how" or sometimes even "what" broke. The input part of it is completely lost. I work on a Backbone application where stack traces are much more obvious. They usually tell you the whole story. I find…

> 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.

Re: Algebraic Effects for React Developers

#22

Post by dan-robertson »

sfvisser wrote: post #10
dan-robertson wrote: post #7

So I think this is a good introduction to what algebraic effects are but I think it also misses the mark a bit. The one sentence summary I would use for algebraic effects is “they’re the way to add delimited continuations to a statically typed language.” Similarly, one might say that ML/ocaml/haskell style polymorphism [excluding typeclasses] is the way to take functions like map or filter from dynamically typed to s…

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 something else. You can’t really stop them from depending on eg function arguments in a nice way.

Re: Algebraic Effects for React Developers

#23

Post by FpUser »

quickthrower2 wrote: post #17
etaioinshrdlu wrote: post #4

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…

You might want to watch this https://www.youtube.com/watch?v=i__969noyAM (2014) to see why React exists and the sort of problem it solves. But now in 2020 you have 2 reasons to pick React. One is because it's the right tool. The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight, and is probably safe for the next 5 years, and you can hire React developers, and…

>"One is because it's the right tool. "

Yeah sure. You choose the right tool because it it the right tool.

>"The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight"

If we always pick "most popular" there will be only one left.

>"you can hire React developers, and you can hire them knowing they will want to stay React developers etc."

I guess some big companies might hire narrow scope developers (and throw those away when they the size of tool they were using changed from 9mm to 10mm). Me being more down to Earth I prefer to look at the resume and list of accomplished projects and hire persons who are creative and do not get fixated on a single thing.

>"Also you might pick React for your own CV!"

Sorry, no ;) I pick projects for money and being interesting. Using XYZ language/framework does not come as a reason into that picture for me.

Re: Algebraic Effects for React Developers

#24

Post by smallnamespace »

mikeryan wrote: post #18
etaioinshrdlu wrote: post #4

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…

Something is off with your transpiling set up if you’re not getting accurate stack traces. A “create react app” default setup will should have accurate stack traces out of the box. To your point about best practices React, at least at the beginning was not supposed to be the entire stack, by design you needed other libraries to deal with large portions of the web state and as such it could only control a small part o…

What GP means is that the stack traces will often just point you to React’s runtime code.

This is a general debugability problem that all runtimes have-you now need an understanding of how React’s implementation works to map the runtime’s state to what you’re attempting to do.

Re: Algebraic Effects for React Developers

#25

Post by quickthrower2 »

FpUser wrote: post #23
quickthrower2 wrote: post #17

Earlier quoted context omitted.

You might want to watch this https://www.youtube.com/watch?v=i__969noyAM (2014) to see why React exists and the sort of problem it solves. But now in 2020 you have 2 reasons to pick React. One is because it's the right tool. The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight, and is probably safe for the next 5 years, and you can hire React developers, and…

>"One is because it's the right tool. " Yeah sure. You choose the right tool because it it the right tool. >"The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight" If we always pick "most popular" there will be only one left. >"you can hire React developers, and you can hire them knowing they will want to stay React developers etc." I guess some big companies…

I agree with you on all these points! However the "market" behaves the way it behaves (in general), and we need to try to avoid the 99% of it.

Re: Algebraic Effects for React Developers

#26

Post by dragonwriter »

smallnamespace wrote: post #24
mikeryan wrote: post #18

Earlier quoted context omitted.

Something is off with your transpiling set up if you’re not getting accurate stack traces. A “create react app” default setup will should have accurate stack traces out of the box. To your point about best practices React, at least at the beginning was not supposed to be the entire stack, by design you needed other libraries to deal with large portions of the web state and as such it could only control a small part o…

What GP means is that the stack traces will often just point you to React’s runtime code. This is a general debugability problem that all runtimes have-you now need an understanding of how React’s implementation works to map the runtime’s state to what you’re attempting to do.

> What GP means is that the stack traces will often just point you to React’s runtime code.

I very rarely run into a case where that occurs, and almost never that doesn't involve ignoring one of the ESLint warnings that CRA sets up in its default settings.

Now, getting the stack trace to only point you to some part of a component library's code seems more common.

Re: Algebraic Effects for React Developers

#27

Post by jiofih »

dragonwriter wrote: post #26
smallnamespace wrote: post #24

Earlier quoted context omitted.

What GP means is that the stack traces will often just point you to React’s runtime code. This is a general debugability problem that all runtimes have-you now need an understanding of how React’s implementation works to map the runtime’s state to what you’re attempting to do.

> What GP means is that the stack traces will often just point you to React’s runtime code. I very rarely run into a case where that occurs, and almost never that doesn't involve ignoring one of the ESLint warnings that CRA sets up in its default settings. Now, getting the stack trace to only point you to some part of a component library's code seems more common.

I run into this daily. There isn’t a single JS error in our monitoring that has a useful stack trace. It would have to extend another 30 layers down to start going into actual application components or code. They all look the same going through different bits of React internals.

Re: Algebraic Effects for React Developers

#28

Post by tartoran »

quickthrower2 wrote: post #17
etaioinshrdlu wrote: post #4

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…

You might want to watch this https://www.youtube.com/watch?v=i__969noyAM (2014) to see why React exists and the sort of problem it solves. But now in 2020 you have 2 reasons to pick React. One is because it's the right tool. The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight, and is probably safe for the next 5 years, and you can hire React developers, and…

I wouldn’t put all my eggs in one basket, things evolve rapidly on this front, 5 years is impossible to forsee

Re: Algebraic Effects for React Developers

#29

Post by nkohari »

flowerlad wrote: post #11

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.…

Why is that important?

Re: Algebraic Effects for React Developers

#30

Post by eyelidlessness »

flowerlad wrote: post #16
eyelidlessness wrote: post #14

Earlier quoted context omitted.

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…

IO isn't functional and that's the reason FP languages such as Haskell have a system for dealing with functions that have side-effects, that neatly separates the part of the program that is pure and the part of the program that is impure (and does all the dirty work like updating the screen). Impure parts of the program is fenced off from the pure parts. Pure functions cannot call impure functions. The important part…

That was exactly my point!
Post reply on HN