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

81–90 of 98 posts

Re: Algebraic Effects for React Developers

#81

Post by Vinnl »

csande17 wrote: post #58
wbercx wrote: post #19

Earlier quoted context omitted.

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…

One thing that feels off about hooks to me is the "primitive" ones React provides. Like, here are the basic things that hooks can do: 1. Tell the component to re-render 2. Store an object that persists between component renders 3. Run something after the component has been rendered 4. Run something when the component unmounts React doesn't give you functions that do these operations individually. Instead, you get wei…

I don't think hooks can actually do 1, 3 and 4. Components re-render whenever React feels like it's a good moment to do so. That happens to include "when state changes", but you're not able to rely on that. This will supposedly become more apparent once Concurrent Mode finally lands.

(You can certainly fault React for it being hard to grok the "correct" mental model, but it makes sense that its primitives do not match the wrong mental model to me.)

Re: Algebraic Effects for React Developers

#82

Post by acemarke »

scns wrote: post #60
acemarke wrote: post #52

Earlier quoted context omitted.

I worked on a Backbone app for several years (and still do, technically - we're about to do a final push to finish migrating it to React). I also liked the fact that you could step into Backbone code, and back out to app code on the other side. Backbone's source is small, and you can see exactly what it's doing. However... React is simply a fundamentally superior programming model, for a wide variety of reasons. I ca…

Even though i don't do front end anymore, thank you for your tireless work and detailed comments on HN, making the ecosystem better.

Thank you, and you're welcome! Nice to know someone appreciates the time I waste on social media :)

Re: Algebraic Effects for React Developers

#83

Post by whimsicalism »

mejutoco wrote: post #64
galaxyLogic wrote: post #49

Earlier quoted context omitted.

> In Haskell impure functions are fenced off from pure functions 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"?

According to this definition a pure programming language could not have any side effect (Not very useful). Maybe as pure as possible is the only interpretation that makes sense, then.

Agreed - I do not think purity should be core to the definition of what a functional language is.

Re: Algebraic Effects for React Developers

#84

Post by iaml »

bbaumgar wrote: post #31
iaml wrote: post #20

Earlier quoted context omitted.

Best way to debug react is to do it via your IDE debug functionality, to enable debugger on caught errors (if you get errors in other code you usually can blackbox it) or to utilize `debugger;` command. Don't forget browser extension for cases where no error happens.

How can you apply this to debugging useEffect issues?

You can set breakpoint inside useEffect and it will work as expected, you can use something like

if (somevar === 42) debugger;

and you'll see all of the internal call stack and all variables in scope. moreover you can use the console to evaluate your code. Worth mentioning 99% of strange issues in react (in my experience) are caused by mutation or not declaring all deps in hooks.

Re: Algebraic Effects for React Developers

#85

Post by flowerlad »

nkohari wrote: post #78
flowerlad wrote: post #44

Earlier quoted context omitted.

In JavaScript UI development it is not important, IMHO. So why do React developers keep pushing functional concepts, as if React is functional?

I'm not sure that they do. Just because Hooks was inspired by functional concepts like algebraic effects doesn't mean the core React team is suggesting that writing React code is functional programming. With that said, my point is that it's more important what you can _do_ with a tool, rather than the purity of the tool with respect to an abstract concept. Or, in this case, with with respect to your interpretation of…

A lot of React developers believe Hooks are functional and that they are doing functional programming by using Hooks. Whether the core React team is responsible for this perception or not I am not sure, but misleading developers about what functional programming is, is not cool.

Re: Algebraic Effects for React Developers

#86

Post by scns »

acemarke wrote: post #82
scns wrote: post #60

Earlier quoted context omitted.

Even though i don't do front end anymore, thank you for your tireless work and detailed comments on HN, making the ecosystem better.

Thank you, and you're welcome! Nice to know someone appreciates the time I waste on social media :)

s/waste/invest in/g

ftfy

Re: Algebraic Effects for React Developers

#87

Post by the_other »

nicoburns wrote: post #80
the_other wrote: post #76

Earlier quoted context omitted.

I don’t understand this complaint. Components are functions of their props and state, returning markup (in the form of a descriptor foe the rendering engine). When a prop or piece of state changes, the component must re-render. The fact that useState might be responsible isn’t relevant. That said, I’m also still struggling with hooks (and I like functional programming in JS). I want to like that hooks let you wrap yo…

> but I find that I miss the lifecycle callbacks of the older class based style. Why not continue to use the class based style? It's still supported. We're using hooks for some simpler cases where they really cut down on boilerplate, but we're continuing to use classes for more complex cases where we find it more readable.

That's what I did at my last gig, where I owned the codebase. At my current gig, I share it with 10 people and the decision to move to hooks was made before I joined.

Re: Algebraic Effects for React Developers

#88

Post by yumindev »

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…

True

Re: Algebraic Effects for React Developers

#89

Post by hackerfromthefu »

acemarke wrote: post #53
timothy-quinn wrote: post #47

Earlier quoted context omitted.

The value of hooks became apparent to me after working with a very large react-redux application. It was so large and the forms had so many elements that the capture of data, testing, and subsequent state management in redux was enormous. 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 exper…

FWIW, you should also switch to using our official Redux Toolkit package [0] if you haven't already. RTK is our recommended approach to writing Redux logic. It includes a number of utilities that build in our best practices, prevent common mistakes, and simplify most Redux use cases. Related to that, we've rewritten the Redux docs tutorials to teach use of Redux Toolkit and the React-Redux hooks API as the default, a…

You should switch .. we've re-written .. does the re in react stand for rewrite?

Not presented seriously, tongue in cheek only, but it's a serious concern!

Re: Algebraic Effects for React Developers

#90

Post by hackerfromthefu »

stevebmark wrote: post #55
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…

Hooks have unlocked a power in React and front end development we haven't seen before, that is going to lead to bigger things. I don't know if hooks are going to be the end state, but the ability to create reusable functionality encapsulated in a hook has solved a lot of problems we previously had of the awkwardness of sharing behavior across components.

Reusable encapsulated functionality for front end components has existed before in a number of front end frameworks, I can cite Delphi VCL and .NET Winforms as two I'm familiar with. Have a look at how tooltips are implemented in Winforms ..
Post reply on HN