Algebraic Effects for React Developers

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 you can hire them knowing they will want to stay React developers etc. Yes all that BS!

Also you might pick React for your own CV!

Let's be honest!!

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 of your stack.

That being said with hooks and providers, it is gaining enough internal tooling to be almost “the whole stack” but still the philosophy remains.

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 that juniors who were mostly exposed to React have a tendency to completely ignore stack traces, and am now wondering if they are just conditioned to them being unhelpful.

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 experience every time to try to maintain the data model and state machine in my head when debugging or introducing changes.

For me the introduction of hooks was amazing as it's allowed us to strip most of the redux state management in favour of managing state with hooks inside of functional components. We still use redux for global application state, but there are also hooks for interacting with that redux state too.

We effectively went from class-based components in react-redux with say 500 LOC in each class, 500 LOC in each action file, 500 LOC in each reducer file, all the way down to about 700 LOC in each functional component file.

I do agree though that debugging sucks. It's incrementally getting better, but it's got a long way to go.

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 reasonably efficient for most practical purposes. The rapid adoption in those early years is testament to how useful that combination of declarative+efficient really was.

However, I feel like as time has passed, the emphasis in the community has shifted towards trying to shove more and more that isn’t view logic into the React/JSX parts of their code, and that has caused all kinds of unnecessary problems.

At first it was as if, just because we had a tidy mechanism to write nested components easily using JSX, every little aspect of application behaviour was now supposed to be implemented as a component and shoved into the tree. This led to patterns like higher order components, and thence to more patterns trying to manage the added complexity introduced by having lots of non-rendering components wrapping everything. By this time, the inmates had taken over the asylum and any pretence of React being used primarily as a clean, declarative UI tool had been all but forgotten.

The idea of managing application state separately and systematically was old long before React came along. Relational databases and ACID transactions had been a cornerstone of software architecture for decades by then, as had the idea of having a separate data model to hold and systematically update application state within desktop software. The early React community was clearly aware of these ideas as well, not just from the “V in MVC” description but also the idea of Flux and before long the Redux ecosystem. And yet, developers still often seemed to keep their application state within their React components instead, which predictably led to all the same problems that had once caused traditional GUIs to move away from retained mode and towards separate state management and immediate mode rendering in the first place. This in turn has led to interest from the React community in ideas like context, and today along with hooks we often see talk of replacing tools like Redux with React Context instead.

It’s not just application state, either. We’ve seen more and more responsibilities pushed into React components over time. It doesn’t seem unusual to have those React components even dealing with communications to transfer state between the browser and the server now, along with all of the awkward mechanics like async fetching from APIs and cache management.

Most recently, the talk is all about how great hooks are, because they let you consolidate or remove of lots of awkward logic that used to be spread through different lifecycle methods in class components. Sometimes, as with this article, the idea gets taken to an extreme. But I can’t help wondering how often anyone stops to ask whether 99% of that logic should ever have been tangled up with the rendering code of the application in the first place. Aren’t we in danger of regressing to big-ball-of-mud antipatterns, just using a big-tree-of-components instead this time around? How do you even test an application properly at scale if you’re forever tangling up your rendering logic, state management, client-server communications and who knows what else, and then obscuring much of it inside React components that end up being tightly coupled because they rely on a certain hierarchy to set everything up just right?

React itself still seems like a useful tool for the same reasons as always, and functional components are a nice incremental improvement on the boilerplate that came with class components in the early days. But the grumpy old man in me can’t help feeling that a lot of the other “progress” in the React ecosystem has been more a series of missteps taken because those who don’t study history are doomed to repeat it. There is still a lot to be said today for using React as a nice, clean, reasonably efficient rendering library for your UI, and for keeping other concerns like state management and network communications separate and using the right tools for each job.

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.

I can't help with the "effect systems" side of this, but I might be able to elucidate some of the recursive functor thing for you.

Suppose you've got a binary tree structure. In something like Haskell, you might model it like so:

    data BinaryTree t where
      InternalNode :: (BinaryTree t, BinaryTree t) -> BinaryTree t
      LeafNode :: t -> BinaryTree t

When I put a bunch of these nodes together, I get a binary tree. But maybe I want to store these nodes in a database, and I need to store them as rows in a table, where a node's children are given by foreign keys into the same table. I could write a whole new type for this...

    data RowNode t where
      InternalRow :: (Integer, Integer) -> RowNode t
      LeafRow :: t -> RowNode t

    data NodeF t child where
      Internal :: (child, child) -> NodeF t child
      Leaf :: t -> NodeF t child
    
    type RowNode t = NodeF t Integer
    
    data BinaryTree t where
      MkBinaryTree :: (NodeF t (BinaryTree t)) -> BinaryTree t

The MkBinaryTree constructor isn't doing anything special. It's just wrapping the given node into a new type, like how pointer indirection is necessary in C++ or Rust to avoid infinite-sized types. Similarly, Haskell doesn't allow recursive type aliases.

That's really the key point behind the recursive functors. We're extracting the "child" type out as a type parameter, and plugging it back in recursively to get our unbounded-depth tree back. Everything after this point is about what free monads add to this, which might be less interesting -- but I've already written it now, so whoops...

Why is NodeF a functor? I can write a function that takes a `NodeF t child` and a function from `child` to `stepchild`, swap the children out using the function, and produce a new `NodeF t stepchild`. That's just "fmap" -- and that's why we stuck an `F` on the name "NodeF", as a kind of Hungarian notation.

    instance Functor (NodeF t) where
      fmap f (Internal x y) = (Internal (f x) (f y)
      fmap f (Leaf t) = (Leaf t)

    -- adapted from https://stackoverflow.com/a/13357359/159876
    data Free f a where
      Pure :: a -> Free f a
      Roll :: (f (Free f a)) -> Free f a

    data FreeNodeF t child where
      Pure :: child -> Free t child
      Roll :: (NodeF t (FreeNodeF t child)) -> FreeNodeF t child

If the `child` is itself a `FreeNodeF t grandchild`, then the whole structure is a `FreeNodeF t (FreeNodeF t grandchild)`, and the canonical thing monads let us do is flatten the nested structure into a `FreeNodeF t grandchild`. In other words, we roll the `Pure` subtree over into the other variant.

The "impure" computation our `FreeNodeF` describes is essentially a branching computation. At each step, we can take a value and replace it with a tree of other values. The next step is performed on each of the values in the new subtree, and so on. At any point, each path can terminate in a final `t` value; but other paths might still keep going.

Essentially, we've structured our computation itself into a binary tree. The upshot is that the free monad lets you structure your computation into any template given by an appropriate functor. The paths through your structure trace the steps over time taken by your program.

Algebraic effects are a structured form of delimited continuations, for people who know about that concept. They give you nearly the full power of monads.

I think the key is that the system lets you specify multiple resumption points, so then the exception handler can make an intelligent decision of how to resume.

This also illustrates how weird it is to call function components pure. They’re not, there as effecful as can be!

Re-frame itself would disagree with you -- although that may be because it does its job well enough that you've not needed to worry about algebraic effects.

> Which brings us to the most important point: re-frame is impressively buzzword compliant. It has reactivity, unidirectional data flow, pristinely pure functions, interceptors, coeffects, conveyor belts, algebraic effects, statechart-friendliness and claims an immaculate hammock conception.

Also, this page of documentation calls out effects and coeffects.

https://day8.github.io/re-frame/EffectfulHandlers/#effects-a...

I'm not quite fluent enough in Clojure to follow the examples, but it does look quite cool.

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 imperative hack that works only if you stay in the strict subset of JavaScript behavior that react expects, but which lets you get the benefits of some algebraic-effect-like contextual handling that would be easily expressed in a functional syntax, but they’re not functional.

Mind you, an OO person might equally say they are an imperative hack to get you the benefits of dependency injection that would be more easily expressed in an OO syntax, but they’re not OO.

What hooks are is more ‘imperative reactive’, I would suggest.