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

71–80 of 98 posts

Re: Algebraic Effects for React Developers

#71

Post by richeyryan »

Chris_Newton wrote: post #57
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 like JSX a lot. The idea of reusable stateless components is totally on the right track. The latter is what I really liked about the early versions of React, back when it was seen as “the V in MVC”. The basic premise of having a declarative UI, so you only had to define what is rendered in terms of absolute state rather than relative transitions, was a good one. React’s virtual DOM mechanics made working that way r…

I think a lot of what you're saying is very true. Its been said before that the React and SPA community in general has had the pleasure of rediscovering past concepts as the community has evolved. I suspect in a couple of years handling application state in your view layer, even using their native capabilities like Context in React or Vuex in Vue will be viewed as an anti-pattern.

As I said in another comment. Effector is something that interests me as it seems to hit a lot of right ideas in terms of reactivity outside the view layer. It can hook into React with hooks or Vue with the Composition API. Hell its stores just work natively with Svelte.

This brings us onto the most interesting point. Virtual DOM libraries aren't necessarily the only/best solution. Compiled solutions like Svelte and SolidJS are offering alternatives that address some of the size and performance concerns that VDOM libraries raise. If your state management is tied into that whole ecosystem, you have to throw all that away to benefit for advancements in the view layer. This is to say nothing of the fact that even sharing code between React and React Native is difficult to do easily.

Whether Effector is the answer I don't know, but I believe it has the right ideas (it is inspired by the likes of Reframe and Flux). Something else might come along that is similar but presented better. However I could totally see a movement that espouses developing your apps data first and then wiring in your UI layer later. Maybe it would even have a TDD or repl based approach. Unfortunately I think it would ultimately be at odds with the beginner friendly, just get something working perspective that a lot of libraries take. How to bring new starters along so they can follow and understand is a much bigger question

Re: Algebraic Effects for React Developers

#72

Post by revskill »

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…

Agree about the hard to debug problem with React. Especially in SPA routing, normal navigation works fine, but in some cases, SPA navigation breaks the new route just because SPA routing is not stateless somehow.

Re: Algebraic Effects for React Developers

#73

Post by Chris_Newton »

richeyryan wrote: post #71
Chris_Newton wrote: post #57

Earlier quoted context omitted.

I like JSX a lot. The idea of reusable stateless components is totally on the right track. The latter is what I really liked about the early versions of React, back when it was seen as “the V in MVC”. The basic premise of having a declarative UI, so you only had to define what is rendered in terms of absolute state rather than relative transitions, was a good one. React’s virtual DOM mechanics made working that way r…

I think a lot of what you're saying is very true. Its been said before that the React and SPA community in general has had the pleasure of rediscovering past concepts as the community has evolved. I suspect in a couple of years handling application state in your view layer, even using their native capabilities like Context in React or Vuex in Vue will be viewed as an anti-pattern. As I said in another comment. Effect…

This brings us onto the most interesting point. Virtual DOM libraries aren't necessarily the only/best solution.

That is surely true as well. Even a perfect implementation of a VDOM library is necessarily doing a lot of extra work compared to direct DOM updates if you already know exactly what needs changing. For a “typical” SPA, if there is such a thing, React’s virtual DOM system is fast enough to make its declarative UI strategy viable, which is enough to make it widely useful. However, it can still become a bottleneck given sufficiently demanding conditions. React without a lot of help can still choke quite easily if it’s asked to render something like a table with thousands of cells or an intricate SVG diagram that needs to animate smoothly.

Giving React the help it needs typically means bypassing some of the diff logic one way or another, for example by providing sCU in a class-based component or a list of dependencies to hooks. However, these kinds of changes also introduce potential inconsistency between what you’d normally render and what gets rendered with a bypass in place, which creates an opportunity for bugs and seems to be fighting against the whole idea of declaring your UI once and then letting React worry about all the details of maintaining it.

Re: Algebraic Effects for React Developers

#74

Post by Cthulhu_ »

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…

+1 with the stack traces; I long for simple and straightforward, no magic applications.

The front-end ecosystem seems to move to the opposite; multi-stage compilation / transpilation steps even in development mode, with tooling to make it manageable and debuggable (source maps). The development mode of my current application needs to reload 35MB worth of stuff at every refresh.

(should look into whether I can optimize that, idk).

Re: Algebraic Effects for React Developers

#75

Post by btown »

Hooks, and algebraic effects more generally, made a lot more sense to me when I realized they’re really syntactic sugar for a pretty common and useful pattern.

Imagine, for a moment, that every React functional component was passed context as an argument. It’s a black box that you can only interact with through a few public methods - ctx.useState, etc.

For consistency, since we are likely to wrap these in higher order utilities, let’s make them functions not methods: useState(ctx, ...)

Now, it would be annoying to pass ctx around to every prop. So since JS is single-threaded, you could validly use the hack: let’s just store the current value of ctx before calling our component code, then it can be implicit at the call site.

And you might implement this as a decorator (@ annotation) that wraps your component, which you can do in Python. But that’s redundant too since the presence of hooks implies the need for it. So magically imply that wrapper if it’s needed.

That’s it. That’s hooks. It’s the same pattern as “accept a bound function/callback as an argument” except React does the binding for you and places it in the argument list for you. All you need to do is use it.

Re: Algebraic Effects for React Developers

#76

Post by the_other »

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 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 your domain logic into neat bundles, but I find that I miss the lifecycle callbacks of the older class based style.

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.

I’m open to having my mind changed on this. I have spent way more time writing classical React than hooks-based.

Re: Algebraic Effects for React Developers

#77

Post by jiofih »

TrevorLee wrote: post #51
jiofih wrote: post #27

Earlier quoted context omitted.

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.

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.

That’s sourcemaps. For simple errors like you mentioned it might be enough, but your stack is still useless for more complex issues. Usually it’s dominated by hooks / batch rendering code.

Re: Algebraic Effects for React Developers

#78

Post by nkohari »

flowerlad wrote: post #44
nkohari wrote: post #40

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?

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 the abstract concept.

I don't think anyone is suggesting with a straight face that React code is purely functional -- this is JavaScript, after all! However, Hooks are a valuable feature, and if they were inspired by algebraic effects, then so be it.

Re: Algebraic Effects for React Developers

#79

Post by ernst_klim »

whimsicalism wrote: post #54
flowerlad wrote: post #15

Earlier quoted context omitted.

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…

> Effects in OCaml are impure: I didn't think that OCaml had a way of distinguishing functions with side effects... the link you sent seems to describe a prospective extension/system, not a built-in of the language.

> prospective extension/system, not a built-in of the language

Yes, that would be merged into the language as typed algebraic effects branch.

Re: Algebraic Effects for React Developers

#80

Post by nicoburns »

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…

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

Post reply on HN