[bigyikes]

The author discusses the sequential leaps towards functional programming: from mixins, to HOCs, to render props, and finally to hooks.

I’m very comfortable with hooks, but I’m not much of a functional programmer beyond that. So my question is: what is the next step in this progression? What is after hooks?

[hombre_fatal]

I don't think anyone knows, hence all the experimentation going on in the space.

There are already pretty good ways to manage state to choose from, from mobx/reagent-style of mutating a store and things just re-render automatically, to observables/swiftui's compose reactivity, to other flavors of reactivity like Elm.

They all are better to work with than what I was doing not long ago with uikit/backbonejs/whatever. It's never obvious when you're taking on the right trade-off between boilerplate and reactive magic, though. But times are pretty good these days for building a rich UI.

[westoncb]

> from mixins, to HOCs, to render props, and finally to hooks.

While each item in the series is "more functional" in some sense, the progression itself is not something reflective of some kind of standard progression of concepts or techniques within functional programming.

I'd say mixins have nothing to do with it; HOCs do in the sense that they're similar to higher-order functions (I suppose they literally are if the component is a function component); render props is pretty much purely a React concept to my knowledge, hooks I've heard described as "similar to" algebraic effects (this seems like an accessible article for more info: https://overreacted.io/algebraic-effects-for-the-rest-of-us/).

So I don't think there is any logical next step. To me it just feels like a series of individually thought out refactors, each leaving us with a system that's a bit more clean and compact than the last.

More broadly speaking though, I think any significant such changes will have the property of reducing impedance mismatch between React and some Platonic ideal of functional reactive programming (applied to html/css generation).

[deckard1]

> I've heard described as "similar to" algebraic effects

I wonder if there is an equivalent of the Turing tarpit, but for languages that aspire to confuse with ever-increasing relationships to tangentially-related mathematical concepts. The Church tarpit? Or would that be the Lambda tarpit...

It sounds like continuations to me. Or Common Lisp conditions/restarts. But that would be an implementation detail when talking about React hooks. And if I'm brutally honest, that all sounds like a retroactive analogy to move hooks into the territory of functional purity or relevance to FP. Better than having people realize it's all a pile of ad hoc design choices on top of JavaScript.

> So I don't think there is any logical next step.

We're already transpiling everywhere. Just get rid of JavaScript! Svelte did it. TypeScript did it. Instead of brutalizing functions, React could instead be forging a new path in language design.

[eyelidlessness]

I would highly recommend learning Clojure. Hooks will feel familiar to reference types and the rest is a really good introduction to FP without being absolutist about it.

[eru]

You can have a look at functional reactive programming for ideas.

The article even links to more material about FRP.

[jitl]

FRP systems like RXJava, Combine, etc to me seems like an enormous and extremely convoluted kitchen sink of abstractions that I’d much prefer to avoid dealing with. From the outside it looks like a Turing tar-pit dressed up with fancy suspenders and a top-hat. It does not feel declarative to me; instead of declaring that function X needs data Y (and should recompute whoever Y changes), I instead need to set up a pipeline of steps as crazy as a make file that hopefully output Y at the right time. ??? Maybe I’m just looking at bad examples, but it really seems like plumbing a Good Compiler should do for me. At least Jetpack Compose is throwing the Android developers a rope out.

[christophilus]

Same. Every Rx codebase I’ve seen has been nightmarish to contemplate. I’d rather program in brainfuck.

[eru]

I don't think RXJava has the 'F' component of Functional Reactive Programming?

I've worked with some rather nice FRP-like systems in Haskell. I doubt you could make this work in Java without losing your mind?