Does a react app really need a software architectural pattern like MVVM or MVC?

I am sure most of you might have seen in some of the Frontend development Job profiles. The recruiter wants you to know whether you have a working experience with MVVM, MVC, or MVP. So let's find out what this means for ReactJS developers.

What is MVVM?

MVVM means Model View ViewModel. It is used to two-way bind data within views. This is usually a client-side implementation (e.g. using Knockout.js).

What is MVC?

MVC stands for Model View Controller. It is a way of separating concerns on the server-side.

Well now let talk about Reactjs. Does ReactJS Really need a software architectural pattern?

React itself is not particularly opinionated about software architecture. It is a library that facilitates the reusable component paradigm alongside guidelines for managing things like state and data sharing (props). At some point, Facebook described this as the V in MVC but have since moved away from that marketing to call it more abstractly A JavaScript library for building user interfaces.

Of course, the typical tooling associated with React apps does lend itself to something of architecture when used together.

A couple of potential ways to think about it:

Simple React apps might be just "VVM" or "VC"

MVC is probably the better-known of the two in the development world. The key conceptual difference between a controller (C) and a view-model (VM) could be boiled down into: a controller can have many diverse responsibilities, like listening for events and routing them in the right direction. It's the glue that facilitates the functionality of an entire application. A view model, on the other hand, is simply responsible for gluing the current state of the data to the model.

So Facebook's original use of "V in MVC" could probably just as easily have been "V in MVVM" - the term controller makes more sense in the backend development world.

Barebones React app, without Redux, that pulls data directly into components (e.g. fetch's in componentDidMount or leveraging GraphQL) with limited data wrangling of any kind could be called a simple "VVM" model.

View-Model (VM): Component-related code that manages simple state, passes data directly onto View, potentially passes data directly back from View

View (V): How the visuals look (JSX, CSS)

Add some complexity, and you could call it "MVVM"/"MVC"

If you toss in Redux, redux-saga, or even start doing crazy things with simple React component state, you're introducing model operations. There're at least two things this Model (M) can represent:

1. Actual business logic for your application
2. Storing and managing complex behavior in your client

Business logic is sometimes undesirable in practice: for example, if you have control over the server, it might be worth keeping all your business logic in one place (on the server) and just feed the UI what it needs to interact with the user. But if you have limited REST endpoints and need to do some wrangling (e.g. in your sagas, or within components), that'll be business logic.

Client behavior management is likely, especially in complex applications where you might be doing things like displaying different things to the user based on their session (e.g. they're an unregistered user vs. user vs. admin). You're probably doing this in any redux store interactions that are contained to use by only the client.

source: StackOverflow