Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"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."

Source: https://github.com/facebook/react/tree/015833e5942ce55cf31ae...

React is good at V, it is not good at M or C.



> React is good at V

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.


> V is the visual representation of the model. React does not exist there at all.

Disagree. That's where React exists. Whether you specify V using turtle graphics style API, or DOM style markup, it is all still V.


Consider the React function:

    function Hello() {
        return <div>Hello</div>
    }
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?


> what value does it add?

Efficient updates.


Updates are the job of the model under MVC. Are you trying to imply that React is meant to serve the M, or are you trying to avoid the question?


I think they meant "efficient updates [of the DOM]".


I use React like the V in MVC for my homemade framework:

https://github.com/williamcotton/williamcotton.com/blob/3719...

That’s a link to a route handler (controller) that makes a graphql call (model) and then explicitly updates the DOM with renderComponent (view).

FWIW, that code runs both client-side and server-side and it is written in F# that compiles to both environments.


> 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.


So then you probably, unlike most, don’t consider something like Rails to be MVC?


> Under MVC, the model updates the view.

Nope. Under MVC, models knows nothing about view.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: