3 ms·

I strongly believe that you are used to thinking in the MVC way of thinking. Redux (and alternatives) are not the classical MVC structure and it takes some time

I strongly believe that you are used to thinking in the MVC way of thinking. Redux (and alternatives) are not the classical MVC structure and it takes some time to get used to it. In a backend environment, a controller might call a Model's function, take some data and return them back. In a frontend app, especially in the componentized world of React, things are quite different because you don't have controllers, your components are deep nested in your app's tree, they may query an API to get data or they may query the local cache. A simple model per component/multiple components approach won't work. Once you get used to it, you will actually see that it's even more flexible and easy to write applications and can even benefit your backend code as well. E.g., I have stopped creating models on my backend code and instead, I am writing modules that may query a table, or two tables or talk to another API. I am using them whenever it makes sense to, not just the controllers. My background is from creating both backend and frontend apps and I hope the above to holds true since I've been there but let me know if I am wrong here.

vog 9y ago
To add to this: The client model is different from the server model! Of course, it is not totally different, but different enough to warrant separate treatment, and the most differences are fundamental, not just differences in detail. The client model is mostly hierarchical, not a cross-connected graph, so it contains multiple "tree-ifications" of the server model. Also, most parts of the tree have much fewer fields, as not all data fields are meant to show up in the client. And that set of fields might be different in different corners of the client. One server model class might have multiple vastly different representations in the client model, depending on the corner of the user interface. On top of all that, the client model contains transitional information about the state of the user interface that is not represented in the server model at all, such as which item in a list is selected, which part of a map is shown, which parts of a document are folded or opened, and so on. Finally, the client model operates mostly in an "open world" fashion, while the server model is a "closed world". I'm using these terms in the meaning of Prolog terminology. That is, the client must always assume that on server side, there are more records that it currently has, and that each record may have more fields on server side than the client is aware of. So with very few exceptions, the client should always perform minimal changes (insert/update/delete), not bulk changes. And after reach change, it should retrieve a fresh state from the server, because another client might have changed something as well, and because the server might have decided to perform some other changes (update calculated/cached fields) as well. The server, on the other side, usually has the whole database at its fingertips, so it can safely perform large-scale changes, not just minimal changes.

vog 9y ago

To add to this: The client model is different from the server model! Of course, it is not totally different, but different enough to warrant separate treatment, and the most differences are fundamental, not just differences in detail. The client model is mostly hierarchical, not a cross-connected graph, so it contains multiple "tree-ifications" of the server model. Also, most parts of the tree have much fewer fields, as not all data fields are meant to show up in the client. And that set of fields might be different in different corners of the client. One server model class might have multiple vastly different representations in the client model, depending on the corner of the user interface. On top of all that, the client model contains transitional information about the state of the user interface that is not represented in the server model at all, such as which item in a list is selected, which part of a map is shown, which parts of a document are folded or opened, and so on. Finally, the client model operates mostly in an "open world" fashion, while the server model is a "closed world". I'm using these terms in the meaning of Prolog terminology. That is, the client must always assume that on server side, there are more records that it currently has, and that each record may have more fields on server side than the client is aware of. So with very few exceptions, the client should always perform minimal changes (insert/update/delete), not bulk changes. And after reach change, it should retrieve a fresh state from the server, because another client might have changed something as well, and because the server might have decided to perform some other changes (update calculated/cached fields) as well. The server, on the other side, usually has the whole database at its fingertips, so it can safely perform large-scale changes, not just minimal changes.