Why isn't React considered MVC?

React is neither MVC or notMVC. It's a library to render the View (with a lots of cool stuff, but still). You can use either MVC patterns, or Flux/Redux, or whatever.

The difference between MVC and Flux is that latest implements unidirectional data flow. So your data can move only one direction. Action -> Middleware -> Store -> View. MVC is bidirectional; you can change Model from View and from Controller.

React isn't considered MVC because it doesn't map very well with how MVC has been conceived and used on the back-end. React is a rendering library and ideally just takes care of the View layer. It doesn't have a central Controller as an orchestrator/router as MVC architectures on the back-end typically have come to have.

That said, you could say that React actually is MVC in some sense (closer to the original meaning of MVC).

React is slicing the MVC vertically (by concern), instead of horizontally (by technology) which was what people had come to do with the MVC pattern. MVC had become a layered architecture with the Views as a thin layer on top. (Although not originally meant as such*).

You could say Components in React started out as small vertically-sliced encapsulated MVC's: containing both state (model), rendering (view), and control-flow logic (a localised mini-controller).

Currently, Components (in front-end libraries like React and SolidJS) mix rendering with rendering logic. Components range from entirely View-oriented, to entirely Control-oriented. This can cause conceptual confusion.

But most components are somewhere in between; having a bit of both rendering output and control-flow-logic.

So currently, React Components have become more of a vertically sliced ViewController, where the Model bit is contained somewhere else. E.g. in state handling libraries like the centralised Redux, or in separate/orthogonal Recoil stores. Or merely pseudo-contained in the Component with hooks like useState (whereas in reality contained by React).

So, Components can currently be seen as ViewControllers.

It's interesting to see the similarity of React Components with iOS' UIViewControllers**. Maybe this mental model from native iOS development influenced the creation of Components, considering Facebook with the React + React Native combo intended to have the same framework and mental model for working with pure Native and the Web.

'A View Controller (VC) manages views and helps in making the application’s UI. It coordinates with model objects and other controller objects. It is known for playing the role for both view objects and controller objects. Each VC displays its own views for the app content.' - iOS ViewController lifecycle

If you need further convincing, just read Apple's documentation of ViewControllers in Swift, and imagine they are talking about a React Component. There is virtually no resistance (cognitive dissonance).

Update: These days, with a lot of component logic extracted into Hooks, you could see Components more as mere Views, and Hooks as Controllers. As ryanflorence and swizecteller have noted.

* It's interesting to note that front-end programming (React) is still wrestling with implementing MVC as it was originally concieved by Trygve Reenskaug back in 1979, who already implemented it with Smalltalk. It was implemented as slicing up the interface/screen into a myriad of tiny atoms/components which each follow a MVC pattern: See "Every little widget on the screen had its own Model, Controller and View." at MVC is not an Architecture. Although this approach has some drawbacks, especially related to syncing state changes, as noted at the section starting with "Sometimes MVC is applied at the individual widget level ..." in this excellent and visual MVC explainer article. In React, syncing state was/is handled through 'prop drilling' (which becomes its own problem, solved by or centralized state libraries like Redux) combined with the one-way data flow of the Flux architecture.

** It should be noted that the iOS ViewController - just as a Controller in an MVC pattern on the backend - might have more wide-reachingconcerns (like cross-component-communication, less encapsulation) than a controller in the sense that a React Component is a ViewController. Since React Components are a part of the JSX/DOM hierarchy and Flux architecture of React. There are probably a few different definitions about what a "Controller" actually means. But for my intents and purposes I treat it as a center for control-flow logic (be it used for simply view rendering, or, as in the backend case, also for routing and model orchestration).

I felt the accepted answer is a bit incomplete, so just wanted to add the three main points (when flux/redux is used to illustrate the answer).

From here: https://medium.com/createdd-notes/understanding-mvc-architecture-with-react-6cd38e91fefd

• The flow of processing is unidirectional instead of bidirectional

• stores are able to store any application related state, whereas the model in MVC was designed to store single objects

• the initiating point Dispatcher makes debugging much easier