Bear with me a moment as I think this will make sense by the end. Before using component architectures I used MVVM (Model View View Model), which was basically an evolution of MVC.

Within the first couple of years of moving to primarily client-side from the server, it became obvious that MVC was missing a vital thing: the ability to handle state. The earliest client-side frameworks were mostly MVC and they fought with the singleton nature of controllers. They introduced things like $scope, and eventually added new constructs turning MVC into MVC$%#@. This mismatch pretty much was the motivator of the move from Angular.js to Angular 2, Ember 1 to Ember 2 etc.. Basically, the stateless MVC architecture was the wrong one for the client.

Before Components became a thing there was another model though, MVVM, which made View Models instances instead of singletons. This pretty much solved the problem and still keep the separation. However, there was a problem. It was ambiguous whether the View Model should be closer to the View or to the Model. What I mean by that is once you started using the model in multiple places there was a temptation to re-use the View Model as well since there was no necessary tie to the View. This was a pretty bad pattern though since as view models in different locations had new requirements they tended to bloat and it created this second tier of indirection. The way we solved this tie it to the View, it can have re-usability via aggregation on features but not on models. We had landed at the Component model anyway. And really landed at the current Hooks model too back in 2014.

Managing state pollutes everything.

I do think it's good to point out the original React material since I'm not going to lie, I was never sold. I thought it wasn't a realistic expectation. Honestly, I found it infuriating nonsense. It took me years to formulate it properly but something never sat right with me React's launch. I knew in my bones it didn't quite add up.

The declarative view parts weren't that different than their predecessors, they just recognized the separation of view and view model caused in many cases unnecessary complications. And this "Component" model was a good thing as it formalized the solution to what I was talking about above. So the difference wasn't there.

The other big contribution was the Virtual DOM, which as Tom Occhino mention has that benefit in the naive sense. However, they were benchmarking against Angular.js etc... A naive Virtual DOM implementation while more performant than blowing out the DOM each time is still not particularly efficient. What we've seen React do in the past few years is decide they can't just be complacent here anymore.

The initial release didn't provide a real state solution, no handling of Async etc... So even if React wasn't doing it the end-user was. Finding the perfect store technology, the perfect abstraction. And the first couple of years the benchmarks were all geared to cases VDOM libraries benefitted from. Large diffed data snapshots and stock ticker demos.

At a certain point, the team realized that no amount of performance tuning of the library was going to correct the really bad bottlenecks people were creating. Shaving a few kilobytes or shaving a few frames was not going to make a big enough impact. But how could they possibly take control of the state, make the end-user code more understood and optimal? Take a page from reactive systems and give the end-user primitives. Yes, the very same reactive systems they condemned on launch. The ones where you needed to be aware of updates. I'm not saying they saught or even looked at reactive libraries, simply they arrived at a very similar place.

This isn't to say you can't have separate model data. That element hasn't changed but we now declaratively describe our updates instead of act like it will just sort itself. Declarative descriptions don't mean chains of imperative code so they can be reasoned about similar to markup. The original React model was too simple at times. It wasn't a real thing. Ugly shouldComponentUpdate functions, hacked forced updates. They just hid it a bit longer, and no one cared to lift the covers before until the React Team themselves saw these patterns didn't allow for the growth they wanted.

There isn't a templating language that doesn't have some mechanism to handle conditionals or lists. Once you want to reuse markup you have control flow. {#each} v-for, <for>, list.map or whatever. This is just a reality of things. It's just a necessary piece. From a declarative standpoint, an if or for statement are not quite the same as their imperative standpoint. It's more like a flow chart, a circuit. This is not a top to bottom thing but a branch point. I understand in React they are the same things when transpiled, but conceptually in templates that's what they represent.

Suspense is basically an async version of conditionals. Error Boundaries are similar as well. They do have elements conceptually of Context as well but they still ultimately govern what is shown. In fact, there are many reasons you might want the custom ability to control flow. So I see zero contradiction with control flow Components. They define what is visually there. Choose your syntax but this is something all template languages share.

The second category Provider, Context, Query, are all conceptually context-based. These are components that use the hierarchy of the tree to do Dependency Injection. This is more interesting since these could be handled outside of the markup tree, but only reasonably via Composition (or inheritance). And to be fair libraries used to use composed wrappers for this thing, but React decided it was easier to use Components than to introduce a different mechanism. I'm not a huge fan of Context Consumer components like Query but the Provider side which has a hierarchical significance I think it is much easier to visualize this way. We had the wrappers before but this for me (and I guess felt instantly cleaner). I'm not sure if there is anything ambiguous about this.

If anything this plays into the piece-wise localized message the current Docs support. The key is slicing things horizontal instead of vertical. They are all just components each with its own defined purpose. According to the spec JSX is just an XML in JS syntax. I know people explaining things have taken their own liberties in finding ways to easiest explain things, but I don't think there is a contradiction there. If you look at things like Polymer (Google's Web Component framework) they done things arguably more egregious in this area and their components are actual DOM elements.

All this being said you can mostly just not. You can pull your state into top-level global stores, and outside of basic control flows for templating (in what syntax your framework uses) stick to mostly HTML. You can more or less get that sort of model separate feel. It does push the complexity into the store, but something well structured like Redux or State Machines probably match pretty well to this. If you solve state management you remove the need for most of this.

However, there are benefits around modularity to extreme co-location. The ability to look at each part separately is just a first benefit. It also let's different teams easier work in the same code base without stepping on each other's work as much. If done right makes for a different sort of refactor story where you aren't looking across files to change things.

Things have progressed this way deliberately by the framework authors which is why I don't see "freedom without clear direction". It is very intentional where we are at. So what is more interesting to me is what part of this immediately doesn't sit right for you?

What I've picked out here is:

• Need to consider update model
• Code readability at a glance
• Concern for tight coupling

The update model I believe I've addressed above. As for the other 2.

Well, readability at a glance is an interesting one. I'd be on the side that semantically named components that I don't know what they do arguably be an improvement over the other extreme of div soup. If anything I feel I have a better idea what the markup does. However, once you start breaking things small enough the big picture is always harder to see. VDOM update model being tied to Components sort of takes it out of your hands regardless.

Being an API of sorts it does introduce new concepts. I'm not going to pretend I'm onboard with React Server Components as of yet, but it's not off the table. Unless you are talking something like Styled Components there aren't that many intermediate wrappers. Providers generally at App entry and a few boundary components around transition points.

As for tight coupling that's the idea.. wait what? Yes, re-usability is oversold and hasn't really worked well except for the dumbest leaf view components. You can also re-use behaviors, but the combination of domain behaviors and views have this specificity that doesn't often translate. For a while, there was a pattern in React to make everything Smart and Dumb component pairs for re-usability. I'm pretty sure almost 0% of them actually got re-used. Localized coupling is fine as long as it doesn't tie into the whole world. In all cases whether separated or together you need to horizontal slice or you risk too much.

The real value of Components is to toss them out when the time arrives. Set boundary contracts so you can dispose of them with ease. Now I'm not simply supporting <ChartContainer> and <UnconditionalChartContainer>, as that extreme is ridiculous. However, in practice, I can think of so many times that would have saved so much pain.

I think if we take a stance that we are designing this one re-usable super component we can sometimes cause a level of complexity that is hard to unwind. Ironically the work you do to add more complexity to a component tends to need to be undone if you ever split it, returning closer to its initial state. Some more zealous on the React side might say that is a reason to always create new components. But that exacerbates other problems (need for context/prop drilling). I've made it a goal of my frameworks to allow building with re-factorability in mind so component boundaries aren't dictated by the framework. So we are not prematurely creating boundaries (one of the most painful refactoring jobs) nor incurring this refactor cost. See this chain of tweets on the work we are doing with Marko.

Anyway, that is my perspective on this.

I want to share my two cents here (although I was going to write a blog post on this, but the thoughts are too fragmented and not all questions have get a concrete answer, I need sometime to sort out everything) .Some contents may be off-topic but I think they all lead to the conclusion that Component being a visual thing is considered optimal

I'm only going to talk about Components in context of SPA.

While it's never formally documented anywhere that what consists of a Component, it's easy to conclude a subset of specifications:

• State self-contained data
  • All the logic (e.g. event handlers) and reactive container reference could be also considered State (which not change often/stay constant). After all function (closures) are data as well.
• Props data provided by consumers, often referred to as parents.
  • * Some framework makes a distinction of props with events, and they are considered different mechanisms in implementation. But conceptually event is for inversion of control, which could be also achieved by passing callback through props
  • In Angular this is called @Input & @Output. They play the same roles though.
• Declarative Template/View Conceptually a derivation of State and Props. Although the mechanism of rendering is implemented differently in UI frameworks. (which could be said the most significant difference between UI frameworks)
• Name/Identity
  • In Angular and early Vue you specify the selector and register the component so that the template engine can look up
  • Or just utilize the object/function identity (e.g. JSX)
• Fractal (tree) Structure Components can be used inside other components' Template/View. Passing data down through Props.
• Hierarchical Dependency Injection a.k.a. Context. Another approach to transfer data via view hierarchy.

Although there might be more items in addition for a specific UI framework, I think the list above has captured all the important elements of the ever-vague Component _ concept. Notably Fractal Structure makes _Component tend to be scalable(extending feature == adding components) and decomposable (split complex components into small pieces), both features are good signs for complexity management. But wait, decompose by what? scale by what? There seems to be a fallacy that Components can decompose and scale up our applications. However, concretely it's the visual part being decomposed, instead of the application.

Component is you Application should be argued further.

I affirm Component can not be not a visual thing and the reason is simple: a Component can have zero state, no props but it definitely has a template/view, even if it renders nothing. And the fractal structure completely acts on template/view, the visual part, so does the decomposition, with no doubt.

And this makes me interested that, why haven't this misunderstanding/abusing ever cause a problem? Or the problems always exist but never be realized or taken seriously? But anyway, why does it work?.

I suspect there is actually a homomorphism between the application structure (in particular, the data relationships) and the view hierarchy. It's already known view hierarchy is a tree, although I don't know how the application is organized (the module /data dependency), a tree, a semi-lattice, or just a single big dumb POJO (redux's 'interpretation' of Single Source of Truth, I doubt it), as we impose uni-directional data flow (which prevents circular refs), it's not hard to construct a homomorphism - by lifting state up, and as a consequence, props drill down or DI to rescue.

At "worst", you have trivial homomorphism (every elements map to a single unit), just like how you use Redux (connect all components to a single store)

And isomorphism should be really rare (all the Components exactly match a corresponding feature slice of Application, only if your application is really simple, like a Counter), but it's currently somehow assumed to be the truth, so that people end up refactoring, or concluding some practices like Presentational & Container Component, or ask state management tools for help.

This explains why you are always lifting state up (and form props drilling or DI), and why "always place state close to where it's needed" is a bad idea. I know in many times these consequences are acceptable, but what if you treat UI as an afterthought, these problem just never exists. Although there are few, very few materials introducing how it could be applied, and in fact, there haven't had such a well-packaged solution yet. (I see the mobx demo, it's too naive.). I put the reason in the next section.

As for view hierarchical dependency injection, I used to be all-in on that, but just recently I've changed my mind. The issue is, the dependencies of Component should be exposed, just like you have explicit type information on props. Sadly this is impossible and not able to be improved further. For many frameworks it's technically impossible to provide dependency type inferences (unless you hack into editor or IDE). This makes the usage of dependency-consuming Component magical. Sometime the magic worth a lot, it's always a trade-off. But what about the whole dependency injection not acting on view hierarchical at all,
but completely becoming an external mechanism, constructing High Order Component that get dependencies via closure.

You may completely not be able to get the idea from last sentences above and I admit I should show some concrete demo code.

function* Parent() {
    // what could be a injected dependency? 
    // a reactive store, a encapsulated api
    // or anything
    const globalSotre = yield GlobalStore;
    const httpClient = yield HttpClient;
    const parentState = createReactiveState({...});
    const ChildComponent = yield* Child(); 

    // whatever I'm using a react-like stuff for demostration
    // could be light-weight because we don't need a "full" component
    return ()=><>{/* 
        parent view
        have access to childState and injected dependencies
        */}
        <ChildComponent />
    </>
}

// the yields type gives all the dependency type information
// 

function* Child() {
    const idontknow = yield WhatEver;
    const httpClient = yield HttpClient;
    const childState = createReactiveState({...});

    return ()=><>{/* 
        child view
        have access to childState and injected dependencies
    */}</>
}

const ParentComponent = (function(context){
    let g = Parent(), next = null;
    while(true) {
        const ret = g.next(next?context.find(next):undefined);
        if(ret.done) return ret.value;
        next = ret.value;
    }
})({
    find: (token)=>{/* implement your dependency locator */}
});

render(<ParentComponent/>, document.body);

Although the code doesn't work at all (have some significant holes), it demonstrates some ideas:

• use generator to implement dependency injection, and get type inference for dependencies, without aware of view hierarchy
• use reactive state outside component rather than in-component state. you get keep-alive/ off-screen component for free
• dynamic constructed component (HoC) instead of direct referencing/importing. model and view are orchestrated separately (comparing to template be the only truth of composition)
• there are actually two way passing data down from Parent to Child, one is component props, another is Child() call. shouldn't props be designed two parts by default? a model part and a view part...
• the state of Parent and Child are logical at the same level (flatten nested generator call) while they have a view hierarchical order.

I'm working on a library making these ideas more standardized.

Both the application and view structure could be dynamic. In Component you could write conditional or repeated structure, but I have seen few public state management solutions provide such capability.

Some state are long live (esp. global state) but some are transient (local). And not all transient state are UI state. Within Components it's related to reconcile of render process - identifying what's added/removed. Not only the visual elements are added/removed, but also the state, or the Component instances containing the state are constructed/disposed (normally GC takes care of that, but a subscription must be explicit unsubscribed).

I need to mention that the identity of Component is not always the same as the identity of Instance of Component. That's why in some framework you need to specify the key.

By the way recoil & jotai provides atom based API which looks great, until you see atomFamily which suddenly breaks the simplicity - exactly the problem from (subjectively) confused identity. The Atoms have a dynamic structure as well, not because the view is dynamic, but a property inherited from the model.

Now given Both the application and view structure could be dynamic, and we want to separate the two, then where is the reconcile process for application (to be specific, the model, the state regardless of view)? I guess that's one of the reason why component-centric design is hot but UI as an after thought is rarely a easy and convinient practice (you end up using single global store, or create distributed store inside Component which isn't applying the slogan at all).

We are lacking of another abstraction, that provides the dynamicity for application, and probably fractal as well (and DI works on this abstraction instead of view hierarchy), takes the place of Components' role apart from visual stuff.

I used to coin that Component is a one-size-fits-all abstraction, but soon I realize the same reason can be used to blame function/class (and it's in certain degree reasonable? I really desire an explicit distinguishing from pure/side effect functions). One-size-fits-all abstraction not bad though, I prefer primitive abstraction.

Why Component is not a primitive abstraction? Because people are discriminating different Types of Component (not referring to functional/class): like Element / Widgets / Layout / Page etc. Although there is no actual formal specification on this, however, several differences are obvious: you can construct stateful Component with zero props, or pure Component with dozens of configurable props; regardless of state & props, some Components tend to be very stable and re-usable (esp. UI Primitives, Design System) and some are never re-used but volatile. Think of all the variable factor and their possible combinations. All these "minor" details are hidden behind a single word Component.

What if we further constrain the concept of Component? To become a completely visual thing could be a good move. And again we need another abstraction that takes the role of rest.

Ryan wrote a post Components are Pure Overhead on suggesting Components could be completely eliminated on the runtime. I think Components as a mental boundary is still, not optimal.

The Component does have a niche - on encapsulating custom UI (primitive) elements. This kind of Components are usually well-designed, very stable and highly possible being re-used. Most significant point is that they are simple, conceptually simple, visually simple, because they touch no part of your business.

But the rest use cases of Component is not that lovely. Because you start build components for your business goal (the business logic, and the visual layout). These components are rarely reused, and tend to change (high volatility). Now the issue comes: visual decomposition doesn't help you to encapsulate volatility, but make it worse (changes can ripple through props). To solve this, you either try your best not to encapsulate new component (is that really a solution?) or try your best not to use props (all-in DI/Context? or state management with connect HoC). Maybe Components apart from UI Primitives don't need props at all.

Not all the questions/statements I yielded have be answered/proved. (subjectively I think I have already had answers but I feel they are not mature enough yet). The most confusing is that I didn't give any detailed specification of that abstraction. I think I've almost found it, but it need to be simplified and I might realize it has been invented decades ago, just saying

Don't Make Me Think applies for developers just as well as end-users. That's why technologies that feel familiar, like JSX, have generally won.

I argue that this type of mindset is part of the problem.
"Don't make me think" is about site/app design - ensuring that users will arrive at their ultimate objective with a minimal amount of friction. "Don't make me think" in the developer world isn't a is a drive towards nirvana but towards assembly line work (which is easy and mindless and ultimately automated into oblivion).

Being a developer is about solving problems - primarily to solve a domain problem while secondarily resolving any technological challenges that may be relevant in that particular problem environment. So being a developer is very much about thinking. Some tools support that by reducing the tedium that distracts from focusing on the important issues. Other tools restrict thinking because they force decisions that really need to be made explicitly for that particular problem context (which is why some tools are not a good fit for some problems, irrespective of your level of expertise with those tools).

Familiarity may drive popularity but it often does not lead to technical excellence (i.e. popularity is rarely a reflection of quality or relevance). Technical excellence is achieved by focusing on solving the actual underlying problem rather than inventing new ways to more quickly sweep tough decisions under the rug.

But could we at least: name same things the same, and different things different?

The fallacy here is that component as a context free concept actually ever manifested any unambiguous properties. According to the glossary of The Unified Modelling Language User Guide (1999) a component is:

A physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.

Note there isn't even a reference to the granularity of a "component".
What people want from components is the "ease" of replacing an analog-era speedometer in an automotive dashboard (which was installed on an assembly line in the first place) - and perhaps the aftermarket modifiability/customizability that is inherent to that design. Meanwhile a "React Component" is nothing like a "Web Component" - and therefore not interchangeable.

We've moved away from separating the view based on structure (HTML), styling (CSS) and behaviour (JS) - which was a good move.

There are tools that make that choice for you but web browsers still make that separation because it is a foundational aspect of the web's approach to fault tolerance and resilience in the face of The Fallacies of Distributed Computing. Conceptually the component model is attractive because it can limit the the amount of information that you have to "keep in your head" at any one time - but that is simply not the way a browser deals with the assets it processes. The component model is for the benefit of the human designer/developer - not the technology (browser) that consumes it.

The Real Cost of UI Components:

Rich Harris, the author of Svelte, made the claim that “Frameworks aren’t there to organize your code, but to organize your mind”. I feel this way about Components. There are always going to be boundaries and modules to package up to keep code encapsulated and re-usable. Those boundaries are always going to have a cost, so I believe we are best served to optimize for those boundaries rather than introducing our own.
...
I think Components should vanish in the same way as Frameworks.

Going back to the analog speedometer analogy - even if all the parts were made by the same manufacturer some very different technologies were used to manufacture that component. Meanwhile a web browser doesn't deal in "components" as "raw materials" - in order of importance it deals with:

• HTML (What to put on the screen)
• CSS (How it appears on the screen)
• JS (How it reacts in response to interaction)

i.e. there are no runtime benefits to component boundaries in the browser. Ideally the browser should receive in order:

1. All the HTML necessary for the first client render (perhaps asynchronously in parts - Island Architecture).
2. At minimum the CSS to support that first render (but perhaps more).
3. And last the JS necessary to make the render interactive - by hooking into the DOM as it was rendered by the HTML rather than creating it from scratch.

Ultimately this points to tooling where "components" only exist at design time (if at all), not runtime. This requires some kind of design time compiler.

To my knowledge Marko.js is the only stack that is currently heading in that direction. Given their limited resources it makes sense that they stick to an isomorphic solution (JS & node JS). In order to support greater (and more performant) choices on the server side in the long term I would like to see the development of a programming language agnostic design-time templating solution that can transform page (or island) templates to host language functions that given the necessary data will render the resulting HTML near-instantaneously.

In conclusion: "visual components" may not be all they're cracked up to be even if they seem to be the popular choice in web development right now.

Here’s a good illustration of how it can go wrong:

x.com/trashh_dev/status/1719800548...

Where did we all take the wrong turn…?🤔

Case in point:

When reading JSX, I feel confortable to imagine a 1-to-1 match with the UI. I can easily navigate thought the component tree and map with the reality.

sancho.dev/blog/tailwind-and-desig...

My suspicion towards the complexity introduced around where Server Components are executed...:

And now, with three new component types to consider: 'Server Components', 'Client Components' and 'Shared Components', when looking at a component, I will even have to know where it is rendered (since it just might deviate from the convention). (Not to mention knowing if it was serialised properly, or if I was stupid enough to pass an anon function into it, mistakenly thinking it was a client component..). "Was it Client Components that couldn't be passed into Server Components, or was it the other way around, now again?"

...seems to have just been validated:

"While we’re excited for the future of RSC long term, as a critical dependency, it presented a number of challenges that became performance risks for our developers, and bottlenecks for our progress."
...
"We’ve found that keeping a clear separation around where your server is doing the work, and worrying less about how your server and client components might mix together, has resulted in a simpler developer experience that’s less prone to mistakes." -- Shopify Engineering, on 2022-10-31 in What's next for Hydrogen: Data Loading

"an application’s UI as a pure function of application state." - Guillermo Rauch on Pure UI

As opposed to:

An application's UI as functions that control and determine state.
(I'm looking at you, React Router).

Related:

I think this also plays into the question of "app" vs "component"-based mindsets. Is React your actual "app"? Or is it "just" the UI layer, with the real app being the logic and data kept outside the component tree? ...

• Mark Erikson, at twitter.com/acemarke/status/114900...

Great article! @redbar0n

I can't agree more with a lot of the premises here. What is happening today of course happened before. We have seen decades ago how HTML was starting to include presentational markup and I am grateful that CSS was born to impede that. Let me quote Håkon Wium Lie, who developed CSS in 1994:

Determining the right abstraction level is an important part of designing a document format. If the abstraction level is high, both the authoring process and the task of formatting the document become more complex. The author must relate to non-visible abstract concepts. The benefit of a high abstraction level is that the content can be reused in many contexts. For example, a headline can be presented in large letters on printed sheets, and with a louder voice in a text-to-speech system.
[…]
Conversely, a low level of abstraction will make the authoring and formatting process easier (up to a point). Authors can use visually oriented WYSIWYG (What You See Is What You Get) tools, and the browser does not have to perform extensive transformations before presenting the document. The drawback of using presentation-oriented document formats is that the content is not easily reusable in other contexts. For example, it can be difficult to make presentation-oriented documents available on a device with a different screen size, or to a visually impaired person.
[…]
The introduction of presentational tags in HTML was a downwards move on the ladder of abstraction. Several of the new elements (e.g., BLINK) were meaningful only for particular output devices (how is blinking text displayed in a text-to-speech system?). The creators of HTML intended it to be usable in many settings but presentational tags threatened device independence, accessibility and content reuse.

Presentational tags crept into HTML for the same reason that components are acquiring more responsibilities or <Provider>, <Query> components appeared. One, it was possible. Second, it was the path of least resistance. You won't create a new language just to show something red right? By the moment you need to do more things, and a new, targeted language seems better, it is already too late to reverse course. This is the principle of incrementalism. Third, it was easy. Easy drives adoption.

Now because CSS is its own thing, it can be used completely independently of HTML and has been used to style web pages, pdfs, native apps, and more. That is what separation of concerns gives. Mastery of the concern. Reusability in different contexts.

In the same way, most components you see in a webapp cannot be reused because the more they do, the less it is likely that any other parts needs the same behavior. The smaller the component, the less concerns, the more reusable. This applies to any software component, be it React component, web component, activex controls, etc.

Just like CSS captures the styling concern, HTML (mostly) describes content. It does not describe how that content evolves over time in response to events, i.e. the application behavior. To do this you need to describe arbitrary computations, and here a Turing-complete language makes sense to address the general case. In specific cases, a DSL may suffice but that is domain-, application-dependent.

So JSX is that Turing-complete language, one trivial transformation away from JavaScript. It is a syntactic trick that makes things easy and triggered faster adoption of vDOM-based frameworks. The <For> tag is a step further in the syntactic tricks that are designed to make stuff look like HTML. As Håkon Wium Lie said, this is putting things that are at different abstraction levels at the same syntactic level (Determining the right abstraction level is important). It is easier (a low level of abstraction will make the authoring easier), it may also be confusing. <For> does not describe any kind of content, like say <title>. But some folks think that developers in general want to entertain the illusion that they are writing some sort of enhanced HTML, when they are actually writing JavaScript. Template languages do things much better as they have syntactic constructions that clearly differentiate what is HTML, what is data/parameters, and what is control flow.

Anyways, yes to separation of concerns, always. Yes to architecture, modules, and first principles. It is not like we just started to write software. There are good practices that are decades old that we regularly seem to forget.

And now for a completely different take (continuation of the UI as an afterthought theme).

Redux maintainer Mark Erikson observed (2018):

I've noted that React devs can often be classified into two groups: those who see the React tree as their app / have a "component-centric" view, and those who view their state / logic as their app / have an "app-centric" view.

Hypothesis: Visual Components require an "app-centric" view.

Kent C. Dodds: Application State Management with React (2020):

React is a state management library

This is a "component-centric" view. Essentially React is the foundation of the client-side app. This represents the mainstream use of React. Eventually the article gets to using Context for distributing state:

function CountProvider(props) {
  const [count, setCount] = React.useState(0)
  const value = React.useMemo(() => [count, setCount], [count])
  return <CountContext.Provider value={value} {...props} />
}

However Sebastian Markbåge points out:

My personal summary is that new context is ready to be used for low frequency unlikely updates (like locale/theme). It's also good to use it in the same way as old context was used. I.e. for static values and then propagate updates through subscriptions. It's not ready to be used as a replacement for all Flux-like state propagation.

via Why React Context is Not a "State Management" Tool .

State management solutions like Redux and Mobx don't pass state through the Provider (like the above example) but a static value that makes it possible to subscribe to any updates of state. By extension this creates the opportunity to inspect the updated state before modifying React component state which would trigger a re-render. The process of state selection is often less computationally expensive than (unnecessary) re-renders.

At the end Application State management with React does suggest Jotai as a potential separate state management solution (a minimalist alternative to Recoil). However in contrast to Proxy (Mobx/Valtio) or Flux-based (Redux/Zustand) state management solutions, Atomic state management can be simply "sprinkled" in-between components - i.e. React is still the center of the universe.

In my view for React components to become predominantly Visual / Presentation / Dumb components, React's role needs to be constrained to managing the UI and therefore "React state" should only be "UI state".

Application state and the effects that manipulate it need to be at the centre of the client-side application - not the UI and much less the framework that implements the UI. The UI is simply the user's window into application state which may trigger effects that modify application state.

Hypothesis: Hooks favour the "component-centric" view

Hooks have been around for two years yet Mobx React integration still relies on the observer HOC with the <Observer> component being to only other alternative. In fact there used to be a useObserver hook which has been deprecated - though there is a suggested workaround:

function useSelector(select) {
  const [selected, setSelected] = useState(select)    
  useEffect(() => autorun(() => setSelected(select())), [])
  return selected;
}

function myComponent({observableOrder}) {
  const latestPrice = useSelector(() => observableOrder.price)
  <h1>{latestPrice}</h1>
}

Redux on the other hand does offer useSelector right out of the box but Mark Erikson wrote an interesting article contrasting the tradeoffs of HOCs and hooks - in particular:

• HOCs promote writing plain components that receive all data as props, keeping them generic, decoupled, and potentially reusable. The downsides of HOCs are well known: potential name clashes, extra layers in the component tree and DevTools, extremely complex static typing, and edge cases like ref access.
• Hooks shrink the component tree, promote extracting logic as plain functions, are easier to statically type, and are more easily composable. But, hooks usage does lead towards a stronger coupling with dependencies - not just for React-Redux usage, but any usage of context overall.

Elsewhere he notes:

useSelector, on the other hand, is a hook that is called inside of your own function components. Because of that, useSelector has no way of stopping your component from rendering when the parent component renders!

This is a key performance difference between connect and useSelector. With connect, every connected component acts like PureComponent, and thus acts as a firewall to prevent React's default render behavior from cascading down the entire component tree.

So while it's possible to use hooks to integrate React components with the rest of the core application, hooks seem to actually encourage bolting application fragments onto the UI component (making React the core/foundation of the application). In terms of decoupling, HOCs are superior but hooks are more convenient.

Hypothesis: "Component-centric" is the new Active-Record

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

React Component: "A component that wraps part of the visual UI, encapsulates state and effects that interact with that state".

Active Record is a codified feature in Rails but has been maligned in many contexts as an anti-pattern:

Active Record has the primary advantage of simplicity. It’s easy to build Active Records, and they are easy to understand. Their primary problem is that they work well only if the Active Record objects correspond directly to the database tables: an isomorphic schema.
If your business logic is complex, you’ll soon want to use your object’s direct relationships, collections, inheritance, and so forth. These don’t map easily onto Active Record, and adding them piecemeal gets very messy.
That’s what will lead you to use Data Mapper instead.

Patterns of Enterprise Application Architecture, p.161

DataMapper for Rails never really got much traction presumably because it significantly increased the "initial-time-to-success" - ActiveRecord was already there and it was easy to get started. Later the application never got complicated enough to warrant DataMapper or development had already progressed beyond the point-of-no-return to adopt DataMapper so maintenance had to grin-and-bear the consequences.

I believe there is a similar dynamic with "component-centric" client-side applications. Using React for application state management is easy in the beginning which leads to React becoming the backbone of the application. This doesn't pose a problem for relatively small applications. However once the pain of "component-centric" design becomes obvious it likely would take a great deal of effort to pivot to "app-centric" design, leading to the existing approach being pushed beyond acceptable limits.

Other References:

• Hexagonal architecture in JavaScript applications — and how it relates to Flux
• The 5 Types Of React Application State
• No, disabling a button is not app logic
• Redux is half of a pattern (2/2)
• Frontend architecture: Decoupling apps from frameworks (DevFest 2019)
• Jotai vs. Recoil: What are the differences?
• valoo
• unistore