# Scaling Reactivity

I was scrolling X and I saw this comment from someone I know to be a fan of fine-grained reactivity so I wanted to take some time to write my thoughts.

> The component based reactivity is annoying, but actually saves you from so many footguns
>Signals are the objective "correct" solution, but they require a really good engineer to manage + understand + architect and can blow up in your face hard if used incorrectly

I want to focus in on this comment because I've thought a lot about this over the years.

## Personal Experience

I admit my experience is biased. My longest period of building production applications on teams was one that was built on reactive foundations, predating React. We had a strong culture there, and while it took a little bit of people getting used to the difference at first, it wasn't a problem. In fact we hired a lot of College grads because of proximity to UBC, and this was a time period where the majority of grads didn't really learn React in school.

We also used React Native for mobile. I spent a lot of time in there working on performance. Now part of that was because React Native at the time was only just figuring out how to offload certain things back to the native level(like animations). But overall the experience was pretty good.

Funnily enough because of the size of the team and the availability of solutions in 2018 we decided that on our big rewrite we would use React. I was no longer in the trenches as I'd moved on to management by that time. We had also hired on some newer devs. And at first, it was going really good. The team basically built out the whole UI in record time. But then features started stalling and I asked what was going on.

I took a look at the codebase myself and through in a few console.logs and I was surprised. The team had done some pretty poor stuff that carried two characteristics. Errors were getting suppressed and no one realized it and components were getting re-render sometimes a dozen+ times on a single interaction.

Now I blame this for the team having a lack of React expertise. This was definitely a skill issue. Combine senior devs without much React experience with juniors who had no clue and this is what you end up with. The seniors assumed you could wire stuff up and React would do reasonable things. And the juniors had no clue what was going on and only were worried if things appeared to work properly.

I told them that while they didn't need to through the UI.. they should basically start over doing a sweep modularly to fix each part of the app until things ran as expected. This took a while, but after a few weeks things were at a much better place. And ironically more aligned with my estimates of how long the features would take.

Common things experience showed me:
1. Most developers are more used to imperative thinking rather than declarative. You can vet this yourself if you have college engineering background. How many people truly excelled at FPGA programming vs typical C style programming. If you asked someone to make the game Pong in each which would they find easier.

2. People gravitate towards solutions that make it easiest to see positive feedback earliest even if the overall cost will be much greater on them.

3. Wrong assumptions hurt us regardless of the direction it is. Whether that is experienced devs treating React as if it is Knockout.js or vice versa. Familiarity plays a bigger role on preset biases than anything else.

## Technical

### React

Let's talk a bit about the difference in architecture here. All reactivity systems involve propagating updates from the point of change to the outputs. So there is a simplification that comes with saying Reactivity === UI. That's the React model. The UI representation is also data. While in the components there is no boundary to the reactivity.

So you can trust that when something above invalidates everything below is re-examined including all the UI. No one can argue the simplicity of the model. This is the premise React is built on. Generally, this would be prohibitive from a performance standpoint but they developed a solution, the Virtual DOM to address that.

So if we stop right there. The statement above is correct. There are less footguns because there is less room for things to get out of sync.

Unfortunately for everyone the idealistic thinking versus the reality doen't match. The performance isn't good enough. Otherwise people wouldn't `useMemo` or `React.memo` or `useCallback` or there would be no React Compiler.

But an even simpler way to think about this is in a model where everything has the potential of re-rendering (and you are ok with that) you need to be ok with keeping the temporal impact of changes in your head. Like if some upstream change causes the component to run a dozen times, if you are trying debug what is wrong with your component you have be able to either ignore the times you don't care about or find ways to explain them.

Of course we can fix the re-renders. And then the lower components can function more logically. But this introduces two concerns. First now you have to look upwards. You can't manage your component in isolation. Secondly the solution is often one of two patterns:

1. Structurally hoist things up so that the data dependency is more direct.
2. Add memoization to stop propagation.

Dan Abramov's amazing article [Before you Memo](https://overreacted.io/before-you-memo/) goes over this in depth. The first solution sometimes is hard because of UI structure constraints. I view it as a workaround in a sense as it acknowledges that the UI structure isn't always the best representation of the data structure.

But the second solution, the more common one, introduces a whole new layer of complexity. And this is the complexity that React Hooks put forefront. This has a few reprocussions. Once we start memoizing we need to keep memoizing to ensure stability. And it is now possible that changes don't reach us for reasons that we are unaware of above our scope.

There is no actual problem with any of this. But it should be an acknowledgement that we have lost some of our ability to locally reason. We are largely at the mercy of our parents.

### Signals

How does this compare to Signals Reactivity? Really its the same problem just upside down. In the same way React Hooks made us painfully aware of memoization, Signals make us painfully aware of reactive propagation.

The same poster also posted:

> Signals are wires, you can send them all over the place and end up constantly re-running some derived state 5 components over if ur not careful. Signals are hard to keep track of, components arn't

Which starts as I think pretty accurate. Like in the same way you have a responsibility with memoization you do so with how signal propagation works. Signals are automatically memoized generally so you'd think this less of a problem, but it is still there.

So funnilly enough when debugging the story is actually really similar just starts from the opposite end. Is this intuitive? Maybe not based on your prior experiences. But is this any more complicated. No.

The problem is basically the same but it manifests itself a bit differently. Since signals are automatically memoized you usually are less likely to have to run-off re-renders but the opposite. Things just not updating when you expect. This lends to a much likely break early model, whereas React will let you go farther and then you only realize the mess when performance hits you.

I wouldn't want to be debugging any system with these sorts of issues, but one is more likely to not get yourself in bigger trouble by not letting you delay handling or noticing the issues.

Localization of thinking is present in both models and compromised similarly when it comes to performance. I recommend reading my article [Thinking Locally with Signals](https://dev.to/this-is-learning/thinking-locally-with-signals-3b7h) to see the parallels here.

## Takeaways

1. Theoretical models diverge from idealistic models in practice.
2. Preset experience has a bigger impact here than technical consideration.
3. Skill level bars are often set at the point of entry rather than looking at things holistically. Easier to get started is a decent metric but it doesn't tell the whole story.

So what does this have to do with skill and scalability. While there are some intrinsic qualities here, especially noticeable at the surface the overall picture does not suggest the same.

It is possible to abuse any pattern. I'd argue easier to abuse ones that are more permissive upfront. My experience tells me that when thinking of scaling we should be thinking a bit longer term, which suggests different things should be valued. But I recognize everyones experiences and requirements differ.