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.

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 can treat React as a black box, knowing that if there's a problem in my UI, it's because of either the logic in my components, or the data those components are using for display. (Then there's things like being able to arbitrarily compose child components together and pass them props, vs randomly trying to attach subviews or something via umpteen different plugins.)

I'll agree that seeing a stack trace with React library code isn't typically helpful. But, the error messages are usually sufficient to tell me what kind of an issue is going on, and point me to the right component or part of the tree to start debugging the real issue.

Somewhat related to this, I put together an extensive post earlier this year called "A (Mostly) Complete Guide to React Rendering Behavior" [0] that digs into detail on how React's rendering actually works, as I've found that a lot of people seemed to be missing how some of the pieces of rendering fit together:

[0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

ftfy

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 weird hybrids like useState, which combines storing a value with telling the component to rerender when the value changes. So you sometimes have to jump through hoops to get the behavior you want. (Well, useRef sort of does (2), except it constructs the object itself.)

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.

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.

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.

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

Well the alternative to hooks is componentDidMount, componentDidUpdate, etc. It's a lot easier to sync state and UI when the logic for doing so can be put in one place.

The debugging story isn’t great if you expect to be able to use breakpoints.

It’s all about putting console.log wherever really.

The beauty comes in the speed of coding, I can move so fast that I always build a mock version of my api layer and can have the entire UI done rapidly.

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

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.

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, as well as using simpler patterns like structuring Redux logic as single-file "slices". See the new "Redux Essentials" [1] and "Redux Fundamentals" tutorials [2] for examples.

[0] https://redux-toolkit.js.org

[1] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[2] https://redux.js.org/tutorials/fundamentals/part-1-overview

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

I know exactly what they do, and usually help co-workers with weird edge cases, but I still have a feeling that we could do better.

Anyway wanted to mention that since redux is so ridiculously tiny, its simple to actually nest it. Components can have local state, and only transmit global state on business related changes.

Now with hooks and useState thats a bit more ergonomic, but you could do that way before hooks were introduced.

Something I'm looking at right now is Effector. It encourages many smaller stores and allows for handling of effects quite easily. The smaller individual stores avoid the performance issues that people bring up often with Redux and I feel the API is more fluent, avoiding some of those boilerplate concerns, some of which are admittedly addressed by Redux Toolkit.

I'm not sure how my time with Effector is going to play out but I suspect it is at least the right idea. I wouldn't be surprised if a similar library came out that was embraced more by the community

I stopped writing React around the time Hooks came out, but I used to use a similar pattern with higher order components. In particular, I preferred HOC for forms. From what you're saying it sounds like hooks replaced a lot of that HOC functionality. Are HOC still used at all?

HOC are the more lispy/dynamic way of doing it I would say and in Clojurescript using Reagent it has always been common to use that general pattern I feel.

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

Yeah sure. You choose the right tool because it it the right tool.

>"The second is to do with the JS tech battlefield - you pick React because it won the front-end popularity fight"

If we always pick "most popular" there will be only one left.

>"you can hire React developers, and you can hire them knowing they will want to stay React developers etc."

I guess some big companies might hire narrow scope developers (and throw those away when they the size of tool they were using changed from 9mm to 10mm). Me being more down to Earth I prefer to look at the resume and list of accomplished projects and hire persons who are creative and do not get fixated on a single thing.

>"Also you might pick React for your own CV!"

Sorry, no ;) I pick projects for money and being interesting. Using XYZ language/framework does not come as a reason into that picture for me.

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.

This is a general debugability problem that all runtimes have-you now need an understanding of how React’s implementation works to map the runtime’s state to what you’re attempting to do.

I very rarely run into a case where that occurs, and almost never that doesn't involve ignoring one of the ESLint warnings that CRA sets up in its default settings.

Now, getting the stack trace to only point you to some part of a component library's code seems more common.

Usually it’s always the same error anyways. Something is undefined or typed wrong.

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 just don't upgrade things in the ecosystem unless I absolutely have to, because debugging the tooling is a massive pain.

This is also why it's very unhelpful to say that it works. Yes, it usually does, but not always and failing to understand that comes across as somewhat antagonistic.

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.

The stack traces are truly and utterly useless. One cannot see what triggered a rerender or other reactive action.

And a rerender can be triggered between two lines of synhronous code, magically, thanks to es6 proxies. What have I done???

All you need is a simple layer to make your typed api calls.

export const ApiService = {

  return {
    getSomeStuff: async () => ...,
    postSomething: ...,
    etc,
  };
}

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.

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.

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

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.

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.