The first problem here is putting a UI widget in charge of fetching data. React was originally designed to be the V in MVC. Had we left it as the V in MVC we'd be loading data in controllers, like we do in every other framework. Having a React component be the model, view and controller is a mistake, and we can still reverse course.
> React was originally designed to be the V in MVC.
React wasn't designed to fit in the MVC model. However, if we are trying to draw an analogy, as far as I can see it most closely resembles the controller. It is where the events are handled to update the "model" (state), which are propagated to the "view" (DOM element). What makes you say V?
"Just the UI: Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project."
How so? Under MVC, V is the visual representation of the model. React does not exist there at all. It relies on the DOM and associated technologies to provide that.
React does give a mechanism to keep the visual representation in sync with the data and it provides a place to handle events that update the data. While it is not designed for the MVC model, so we cannot truly speak to it in MVC terms, the closest analog to those seem to be the M and C.
I'm assuming you had to go back to a commit from 8 years ago because all future commits realized that whoever wrote that React is the V in MVC was confused?
This is much like saying the DOM is not truly part of the view because it doesn't directly represent the pixels that the user sees. Both the vDOM and actual DOM exist entirely to facilitate a particular kind of presentation, and can be logically separated from the model which could in principle be presented in purely audio format or something. If that's not a "view", then what is?
I think the point is React does not provide the DOM, the browser does. Unlike MVC frameworks in languages that do provide their own UI. Smalltalk being the grandfather of that.
Yes but the DOM is the render target for React and hence the V. Just because it's a complicated way to talk to the screen doesn't mean it's not doing that.
Are you saying that you do need to directly specify pixels to count as a View? I don't consider that a useful engineering principle. If not, I can't see how what you said changes anything. I saw their point roughly the same as you did, and I think it's bad.
The div object is where the visual representation is handled. React in this case is only concerned with passing data to it, which is explicitly the model's concern under MVC. Although I suggest that event handling is really why people choose React, and that is the controller's concern according to MVC.
Again, React isn't designed for the MVC model, so we have to really stretch ourselves to find any kind of similarities. But if React was only the V to the greatest extent that we can pervert the meaning of V, what value does it add?
I think what OP and others are talking about when they refer to React as being the view part of model-view-controller is that a server might render a React component in the view layer after the controller has decided what data to collect and which layout to use.
I think something other people sometimes talk about are single-page applications, in which case it's not a single component being rendered but an entire application. At that point MVC was simply disregarded by the developers because React is really just trying to be the V in MVC.
That would be what is known as the template layer, not the view layer. If we're just randomly making up definitions for MVC, then sure, anything goes. But as nobody has provided the the arbitrary definition they just came up with off the top of their head, surely we're sticking with the standard Smalltalk usage?
> That’s a link to a route handler (controller) that makes a graphql call (model) and then explicitly updates the DOM with renderComponent (view).
See, we're already not talking about MVC. Under MVC, the model updates the view. But, as you say, in your code the "controller" does the updating. Maybe you could argue that React is serving the role of the model here by actually being the place where the DOM gets updated, but, ultimately, we're always going to struggle with finding such analogies when React isn't designed for the MVC model.
Right, but the model does know everything about signalling change. Under MVC, the model is responsible for updating the view through the passage of messages.
Which is essentially one major part of what React tries to offer. Granted, in an ugly way as it has to deal with the harsh limitations of Javascript instead of having the power of Smalltalk to work with, but such is life.
> React was originally designed to be the V in MVC.
So much this. As we built more sophisticated apps using React we were constantly frustrated with how much code was ending up in the views, and how difficult controller frameworks were to work with (looking at you Redux). So we built our own mini-framework that explicitly separates the view from the controller. Seems like a simply change but it is amazing how much more productive it makes developers, especially with large complex applications that need refactoring as they evolve.
Unfortunately our skills are in writing code, not marketing, so we don't have a fancy website like most frameworks. But the details are here: https://github.com/aha-app/mvc
That’s why I think the most sane way to use React (or Vue) nowadays is through Inertia.js.
Have a proper backend doing all the backend stuff and just render page components as if they where just the views of the framework.
All this server components nonsense is solving a problem that maybe Facebook has but almost no one else does. But people think they do, so a lot of complexity is added for no real reason.
Caleesi voice: React wasn’t invented to stop the wheel of MVC, it was invented to break the wheel
And I think life is better without the V-C distinction. Models ofc still exist but the field has gotten more fine grained for the term to still cary meaning
Going to assume you're talking frontend? Otherwise you'd be claiming most Spring, Django, Rails, Angular, <enter common backend framework> codebases are a nightmare to work in. While there are many good application architectures that don't fit into the MVC pattern (or introduce additional layers, e.g. - auth), separating DB ops (M) from business logic (C) and endpoint handlers (V) has always been rather maintainable/testable in my experience.
Yeah, MVC (and MVVM for that matter), seem like architectural approaches that are great in theory, but with the reality of constraints, requirements, timelines, and ultimately many engineers' misunderstanding of things (frankly I'm probably included in that group as well), it just leads to a mess of interdependency and tight coupling among functionalities.
Now granted, this is pretty much a given for any architecture (nothing is perfect): so maybe my expectations of what things should be needs to be reeled in a bit.
> it just leads to a mess of interdependency and tight coupling among functionalities
Disagree with that. Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. That's no accident. MVC works very well.
