31–40 of 46 posts
Earlier quoted context omitted.
Not sure I'm following your exact setup... But you could of course just make a model for your form and _not_ your customer. Without seeing your full setup, it's hard for me to say for sure!
@IgorPartola, it sounds like this may not be the right fit for your setup
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…
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, you…
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.
Earlier quoted context omitted.
Not sure I'm following your exact setup... But you could of course just make a model for your form and _not_ your customer. Without seeing your full setup, it's hard for me to say for sure!
In my apps customer will be a global via VueX. If I go to the Edit Customer view, change customer.name, but don’t save, the change will be visible throughout the rest of the app: the customer list, all the other views where the customer’s name is displayed. It would be a bug to show unsaved data anywhere but in the edit view. And if I go to the edit view, make changes, then exit without saving, then go back, the view…
This is business logic and it's dependent of the UI. If you have a Save button but the user doens't save and leaves the page, on change route you reset the model. If it doesn't have an explicit button, on change route you save the model. It has nothing to do with the framework.
If you mean the library doesn't have a way to reset the model to its original state, it doesn't take too long to implement, just call fetch as the author says or when you load the original model store a copy somewhere, even inside the model itself.
@author: please take a look at http://feathersjs.com - your work is very interesting, but you should make it a layer on top of a modular backend service and feathers would be a good choice, but maybe people would like to use phoenix or other backends on the server. Also you may be interested in http://derbyjs.com/ and do some research about operational transformations. Ah, and please do not forget that in a real app…
Another interesting read for anyone designing CRUD software in 2017: https://ipfs.io/blog/30-js-ipfs-crdts.md
Earlier quoted context omitted.
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.
Ecto is really interesting, but it's not an actual ORM[0], Elixir doesn't deal with objects, there's a free book on ecto that's pretty interesting: [0] http://pages.plataformatec.com.br/ebook-whats-new-in-ecto-2-...
Earlier quoted context omitted.
In my apps customer will be a global via VueX. If I go to the Edit Customer view, change customer.name, but don’t save, the change will be visible throughout the rest of the app: the customer list, all the other views where the customer’s name is displayed. It would be a bug to show unsaved data anywhere but in the edit view. And if I go to the edit view, make changes, then exit without saving, then go back, the view…
> And if I go to the edit view, make changes, then exit without saving, then go back, the view should be reset. This is business logic and it's dependent of the UI. If you have a Save button but the user doens't save and leaves the page, on change route you reset the model. If it doesn't have an explicit button, on change route you save the model. It has nothing to do with the framework. If you mean the library doesn…
Calling fetch all the time because the user navigated away doesn’t make sense performance wise.
Think about it. If Django/RoR had their ORM make all modal instances global singletons and any view there could modify the properties of the model, but for persistence still had to save them to the DB, would you want all of your views to have to roll their own reset code? Would you trust such code? No. That would be nuts. So why is that ok on the client side? Local state is ok for emphemeral data. Use it instead of modifying global state with data that is not ready to be committed.
Hey, this seems cool but I don't really know why... New to vue.js and maybe I'm doing things... Wrong? But I don't think I need this. My approach is very angularJs-esque but I have a root component 'main.vue' which basically acts as my index.html. When I want to send a REST call I've got a method setup which handles GET calls and another for POST calls... I use them how you would call an angular service, and it works…
> Can you explain why I'm stupid and everything I've done is wrong? Haha I cannot, because you probably aren't stupid and haven't done everything wrong. The thing I like about this approach is that it removes the need for manually: 1) writing `saveCustomer` or `getCustomer` methods on my vue instance 2) tracking validation errors for each model. So if there's a collection of models on the page, I can super easily sho…
To answer your questions, if http call fails I'm currently handling it in a .Catch. I haven't done much specific error handling yet, was probably going to do a bunch of if statements to figure out the nature of the error and then output relevant messages to toast.
For the loading indicator(s) I was planning on using just one, globally, like YouTube does - their slim red line that runs a long the top of the viewport?
I'll definitely look more into your library but I'm hesitant to bulk up my app unless something provides critical functionality. Using Quasar framework right now and already a little conserned with load times and bulk. Although I haven't built for production yet with full minification, etc.
Thanks for your time in responding to my stupid questions!
Nice. Will give it a whirl in my next project. Question for the author: is this "production-ready", or is it a toy project? If I start using this, do I have to worry about you abandoning the project six months down the line as you become interested in other things? That in my mind is the biggest issue with open-source in general: people release stuff into the wild but don't follow through.
This free software comes with no guarantees either explicit or implied.
That being said, I use it all the time so I plan on maintaining it. You are also welcome to contribute if you find something that needs fixing
@author: please take a look at http://feathersjs.com - your work is very interesting, but you should make it a layer on top of a modular backend service and feathers would be a good choice, but maybe people would like to use phoenix or other backends on the server. Also you may be interested in http://derbyjs.com/ and do some research about operational transformations. Ah, and please do not forget that in a real app…
Ah the legacy of Rails. Active Record anti-patterns for everything.
Thanks for checking it out! I put a lot of work into it so it's nice to know you looked at it.