I sometimes wonder what people are using React for, that they wouldn’t know this or have figured it out along the way. Let me kind of explain, as best I can, without code.
We have a complex software product, an integrated compliance and risk management system with embedded workflow, automatic highlighting of potential risks due to non-compliance, plans of actions (aka risk management plans), RBAC, ABAC (used to control different things), etc.
The backend does most of the work. What gets presented at the frontend can be complex.
The React component model gives us an almost functional DSL that we use for compact, highly expressive tooling that allows us to integrate common look and feel, table exports, etc., across some really complex data.
We started before Hooks were widely available or widely known, and, we started with class-based components, because we realized pretty quickly we were going to have to do some funky state management, especially where workflow was involved (we want a common look and feel across processes and tasks, so workflow tasks and processes get wrapped in higher level components that call back to other high level components; the forms can have dozens or hundreds of variables, some interdependent, so state has to be communicated up for validation; React handles sending it down).
Our key state management function is a custom signal handler that gets passed as a prop to all sub components, then, via a common wrapper, back up to the high level components that group everything for display and consistency purposes.
As we refined this handler (and a few others), we moved from class-based to functional components.
The functional components are simpler than the class-based components they replaced, with much of the complexity located in one place, the handler.
Our handler allows us to pass state up “just far enough”, and React handles updating all affected components.
Performance is fantastic, validation is easy(ish; it takes some staring to grok how it hangs together), and debugging (once one has grokked, is straightforward(ish; there are edge cases that cause pause, until the “oh, yeah, that” moment).
That functional DSL has allowed us to build several suited-for-purpose DSLs, e.g., our workflow system, which, while not no code, is low code (configuration as code more than anything else).
If we didn’t understand the React state management model, none of this would have been possible.
So I ask, in naïveté, what are people building that they didn’t need to know that?
(We are likely to move to Hooks anytime soon, because we’ve already solved the problem they were introduced for, and without having to rewrite much. Hooks look like we would have to make wholesale changes, in which we see little value, at least right now, OMMV in the future).
> I sometimes wonder what people are using React for, that they wouldn’t know this or have figured it out along the way.
The article is for beginners (the article itself says its intended audience beginner-intermediate, but I'd say it leans very much towards beginner). Thus this is precisely an example of how people who use React would learn this. It would be odd to comment on every explanation of a concept that everyone would have already learned that concept.
Ah, OK, fair enough. For an article intended for beginners, well, it made think of those recipe sites that bury the details after autobiographical recollection.
It could have been ever so much shorter and clearer. But I’ve realized I really am becoming a get offa my lawn type as my 60s near.
You can get away with a lack of understanding about these things and still create beautiful products. For an example just look at Josh’s website. Beautiful react and design execution without knowing these details about rerendering.
Several things can happen when you don't understand this re-render process exactly right, among them:
- slow UIs which re-render too much. For instance, re-render of a big chunk of the component tree for each key press because you somehow found it was a good idea to pass the new value all the way up to the root of the component tree without realizing that it will re-render everything (because React will only re-render what actually changes, right?). Or, if you understand it, trusting too much the browser on its ability to run this fast. Of course, if your workstation is quite beefy and you work with small data just to test if it works during development, and are used to slowness from your OS, you may not notice the issue at all until a user with a regular computer attempts to write a bigger text than what you ever tested on your beefy machine. And of course React pushes for managed components; performance, memory usage and GC pressure be damned.
- "a second ago" "helpfully human-friendly" indicators that stay "a second ago" forever, because nothing ensures a re-render when necessary, or because the wrong value is passed / stored.
- jumps and erratic scroll behavior (on unsuspected/non-ununderstood so seemingly random re-renders), because you are building the UI declaratively but some stuff actually need procedural solutions, and doing this in React can be difficult, and you end up with difficult to understand buggy workarounds. Think adding a new blog post at the top of a blog post list that the user is currently reading, or a new message that gets added at the bottom of a message list. Yes, I know, CSS anchors are supposed to solve this, but no, you can't always use that, by the way they are still unsupported by Safari. The fact that everything is asynchronous does not help at all by the way, you can't just position things right after you add them to the DOM and right before the next visible paint like you could with vanilla JS.
I'm not making these things out off my ass.
React is sold as something that makes the lives of frontend developers easier, and many frontend developers find it compelling because of this, but in reality it's way more complex and add way more complexity than probably many people suspect / notice. Especially if you add Redux, which is surprisingly action-oriented in this declarative world - quite jarring, and also quite complicated to understand (just let me increment this counter or add this element to this list already, I don't want to deal with these freaking "reducers"! Why can't I deal with these values like in the rest of the React app, by using some kind of setState function?). Svelte got this right. The store is reactive and not action-based, very easy to understand. Also, why such an essential feature isn't provided by React itself?
React is cute and give the impression to help manage complex UIs for which vanilla JS would supposedly be a mess, but if it is not perfectly mastered, I'm yet to be convinced that this is true. You need to have a really good intuition on how React works to design a complex UI with it, probably to the point to be able to write a small prototype of React.
The reality is that React is hard to understand, but it's easy to not notice this.
Sound pretty interesting! We’ve also implemented a DSL on top of React, see Lowdefy [0]
We’ve taken a different approach, we’ve written a pure js engine which computes and manages state based on operator used to express logic, and then have a recursive render loop in react which provives engine with update hooks to it uses to rerender components when it should. That way we can very handle complex state logic and then update with ease all without dealing with passing state up and down.
We still have a few ideas on how to further optimize which will be built in future versions. But already we, and the OS community are building some advanced apps using Lowdefy
I like the sounds of that. Every now and again we look at alternatives to our implementation: it works, so we don’t want to break it, but hic sunt draconis and caveat programmator.
You could have achieved the same thing with Mobx stores without having to pass a handler around everywhere. Although it sounds you're using context-dependent state that don't need to exist globally. Well, it would still work and you'd only need to know a couple of Mobx pitfalls in order to make it render efficiently. So no, you don't need to understand React state management model completely in order to build working apps.
We have a complex software product, an integrated compliance and risk management system with embedded workflow, automatic highlighting of potential risks due to non-compliance, plans of actions (aka risk management plans), RBAC, ABAC (used to control different things), etc.
The backend does most of the work. What gets presented at the frontend can be complex.
The React component model gives us an almost functional DSL that we use for compact, highly expressive tooling that allows us to integrate common look and feel, table exports, etc., across some really complex data.
We started before Hooks were widely available or widely known, and, we started with class-based components, because we realized pretty quickly we were going to have to do some funky state management, especially where workflow was involved (we want a common look and feel across processes and tasks, so workflow tasks and processes get wrapped in higher level components that call back to other high level components; the forms can have dozens or hundreds of variables, some interdependent, so state has to be communicated up for validation; React handles sending it down).
Our key state management function is a custom signal handler that gets passed as a prop to all sub components, then, via a common wrapper, back up to the high level components that group everything for display and consistency purposes.
As we refined this handler (and a few others), we moved from class-based to functional components.
The functional components are simpler than the class-based components they replaced, with much of the complexity located in one place, the handler.
Our handler allows us to pass state up “just far enough”, and React handles updating all affected components.
Performance is fantastic, validation is easy(ish; it takes some staring to grok how it hangs together), and debugging (once one has grokked, is straightforward(ish; there are edge cases that cause pause, until the “oh, yeah, that” moment).
That functional DSL has allowed us to build several suited-for-purpose DSLs, e.g., our workflow system, which, while not no code, is low code (configuration as code more than anything else).
If we didn’t understand the React state management model, none of this would have been possible.
So I ask, in naïveté, what are people building that they didn’t need to know that?
(We are likely to move to Hooks anytime soon, because we’ve already solved the problem they were introduced for, and without having to rewrite much. Hooks look like we would have to make wholesale changes, in which we see little value, at least right now, OMMV in the future).