I'm refactoring a large web app with another developer's help. In my mind, the backend is organized like so:
Symfony PHP: controller
PostgreSQL DB: model
Redux.js: model + controller // this is all mildly simplified
I don't think it's particularly helpful to think of the client-side app as just a view of the server-side state anymore.
The client-side is its own MVC application. Strictly, I don't think react-redux is actually MVC. It's considered an alternative to MVC. React is the View in MVC, but also a little bit of the Controller, and redux is an opinionated way of using the Model. You should read more here: http://redux.js.org/docs/introduction/Motivation.html
Maybe another way of thinking about this is that the server has a 'model' and a part of the redux state-tree is actually a view of that 'model' (like a list of todos derived from and kept in sync with a todo table on the server-side).
Parts of the redux state-tree could also have nothing to do with the server-side 'models' and could just be useful for storing client-side state (like the current url/route).
My firm belief is to not worry too much about the terminologies too much and stick to first principles. The server has state, the client-app has state. A part of the client-app's state is derived from and/or synced to the server-side state. The rest of the client-app's state help's generate the UI that the user sees. As the user interacts with the app, code is triggered that manipulates the state. Once you write a simple react-redux app, you'll see where all these pieces go!