I'm usually a Django backend developer doing the whole server-rendered static html type sites, but I've attempted to venture into the world of single page apps a few times. The thing that always tripped me up was figuring out the frontend model layer. Nothing I've used, whether Redux or Vuex or Mobx or whatever else seemed as elegant and simple as say the Django ORM is on the backend. There were always missing pieces that I couldn't quite get working cleanly, like validation, or loading indicators, etc.
This looks like it has the potential to be what I was hoping someone would make. Looks excellent so far, thanks for sharing!
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.
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.
Thanks for saying that. It sounds like you and I are quite similar. I've never built a full SPA because I it's _so_ much easier and faster for me to build "traditional" apps. Since discovering Vue.js I've started wading further and further into sprinkling JS components onto the page.
Vuex, Redux, etc just don't make sense in my brain, so I've never used them. I built this because I wanted something simple to interact with my Laravel backends. Most of what I do is CRUDdy, and this is super helpful for that.
You might wanna look into EmberCLI. It's not as trendy or popular as Vue or React (rendering speed is a big reason), but it might be what you're looking for.
Might be the first time I've seen the words "elegant", "simple" and "Django's ORM" in the same sentence. You could say it's easy to get started with, or do simple queries, but it's definitely not simple nor elegant.
Haha, to each their own. There is such a thing as the object-relational impedance mismatch for a reason. I'm currently learning Elixir and Phoenix and it's ORM Ecto has some really interesting ideas. Functional programming seems to map to relational databases better than object oriented does.
Oh, I guess that's true in the sense that it doesn't map to objects but it accomplishes the same goal in a functional style. Maybe call it a Struct-Relational Mapper.
This looks like it has the potential to be what I was hoping someone would make. Looks excellent so far, thanks for sharing!