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

91–98 of 98 posts

Re: Algebraic Effects for React Developers

#91

Post by hackerfromthefu »

onion2k wrote: post #62
TrevorLee wrote: post #51

Earlier quoted context omitted.

I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable. Usually it’s always the same error anyways. Something is undefined or typed wrong.

I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable. This highlights one of the biggest issues with React: usually it works really well, but if you're unlucky enough that it doesn't then there's almost no way to work out why . I've been developing with React for about 4 years and…

I completely understand what you mean about not upgrading things in the working ecosystem, it's the pragmatic choice in the short term.

But then the churn in the interdependent platform and packages means your project is moving towards a state that it cannot be upgraded without significant risk and rewriting around the deprecated packages.

In my opinion this is a major issue with React in the landscape of businesses that have a halflife of more than a few years.. ie most long term businesses.

Yet despite the long term fragility and maintenance issues it's a topic that is missing in most discussions about React. The React conversations tend to be 'how can we keep up with the latest churn' instead of recognising the churn itself is a problem and stability provides realworld business value in the medium and long term.

Re: Algebraic Effects for React Developers

#92

Post by flowerlad »

whimsicalism wrote: post #83
mejutoco wrote: post #64

Earlier quoted context omitted.

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.

Pure functions (with no side effects or state mutation) is pretty core to functional programming.

Re: Algebraic Effects for React Developers

#93

Post by whimsicalism »

flowerlad wrote: post #92
whimsicalism wrote: post #83

Earlier quoted context omitted.

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

Pure functions (with no side effects or state mutation) is pretty core to functional programming.

https://en.wikipedia.org/wiki/Functional_programming

> Functional programming is sometimes treated as synonymous with purely functional programming, a subset of functional programming which treats all functions as deterministic mathematical functions, or pure functions. When a pure function is called with some given arguments, it will always return the same result, and cannot be affected by any mutable state or other side effects.

It is a closely associated idea, but it is not necessarily "core" to what FP is.

Re: Algebraic Effects for React Developers

#94

Post by WorldMaker »

the_other wrote: post #76
csande17 wrote: post #58

Earlier quoted context omitted.

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

> Hooks based components are trying to make modules that are “about” the problem domain they illustrate, but they do it as a feature of React. React isn’t about your problem domain, it’s about driving the DOM and rendering, and I think it makes more sense to treat React code that way.

This is why I think it's going to take a bit more time with hooks code to realize the opposite to csande17's complaint is really true: the problem with the hooks React ships with is not that they aren't primitive enough (as the sibling comment points out, csande17 probably is also missing that some of the primitives they are looking for expressly don't exist as React hooks because they don't fit the algebraic effect model React is moving toward, versus the lifecycle model React is moving away from), but instead that the hooks React ships with are still (or least feel) far too primitive an algebra for the "calculus" needed for at least some problem domains (if not most problem domains).

I don't specifically have any answers for what the next layers up will be, though I appreciate this article for trying to explain how algebraic effects work in other languages because that provides ideas from other places of how their primitives get composed.

Re: Algebraic Effects for React Developers

#95

Post by jameshart »

flowerlad wrote: post #45
steve_adams_86 wrote: post #36

Earlier quoted context omitted.

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…

> borrowing from the functional programming paradigm to gain better control over state and corresponding UI behaviors 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.

Are you.... asserting that it's impossible to make a program that handles interactivity... using functional programming?

Re: Algebraic Effects for React Developers

#96

Post by jameshart »

flowerlad wrote: post #43
jameshart wrote: post #34

Earlier quoted context omitted.

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…

> I don’t think I’ve ever seen anybody claim that hooks are ‘functional’ 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/

I'm not sure what the problem is with using functional ideas as a justification? It feels like you're complaining about a sort of cultural appropriation.

Functional ideas are sometimes good, and they should be borrowed and used in nonfunctional contexts. Like continuation-passing-style got lifted and used to inspire promises and async/await. That doesn't mean languages with async/await are functional, or that programming with async/await is taught as functional, it's just the pedigree of the idea.

React hooks lift some ideas from algebraic effects, and embed them in a decidedly nonfunctional, VERY non-pure-functional context. But the pedigree of the idea is still... algebraic effects.

Re: Algebraic Effects for React Developers

#97

Post by mrozbarry »

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've stated several times that hooks are awful, and the general response I get is "oh, you just don't get it," but the way they are implemented is not very functional, but I guess the point is that they are side effects.

In terms of other things, JSX has nothing to do with stateless components, it's just a way to simplify writing `React.createElement(yourElementOrTagName, { ...props }, [ ...children ]);`

And for debugging, the absolute best advice I can give is to build smaller components, and use something like storybook to demo/isolate behaviour and tinker with it.

In general, react is a perfectly fine choice, though. I don't think it's any more strange than angular/vue/hyperapp/etc., but it is certainly lower level, which can feel less intuitive.

Re: Algebraic Effects for React Developers

#98

Post by flowerlad »

jameshart wrote: post #95
flowerlad wrote: post #45

Earlier quoted context omitted.

> borrowing from the functional programming paradigm to gain better control over state and corresponding UI behaviors 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.

Are you.... asserting that it's impossible to make a program that handles interactivity... using functional programming?

I am asserting it is counterproductive. In other words, the code will be convoluted and hard to maintain, which is the opposite of the goal of functional programming.
Post reply on HN