I want to understand whether or not there is a need for optimistic-ui in 2017 for Meteor.
As we know optimistic-ui, lets us update client-side collections, before we actually receive the changes from the server. I personally don’t use optimistic-ui in most of the projects, because I prefer keeping mutations server-side, and since everything is happening instantly either way I don’t need it.
Now, if I would like an “instant” change, without waiting for the server, I would play with React’s state. And do that, and whenever a new change comes in, that change will be processed.
Any thoughts ? Do you use optimistic-ui ? Is it critical for you ?
Hey @diaconutheodor, Optimistic UI makes sense for collaborative apps mostly (heavy user input and actions), it provides a better UX, the app feels like native, no more delays for simple actions. It’s been working great for us at Planable, I keep sensitive mutations on server only, but stuff like comment input, content changes, content states, I replicate in the browser and got rid of most loading states.
I’m against Optimistic UI. It seems like a good idea from an engineering perspective, but overall, I find it not worth it for a few reasons:
the need to bundle server logic to the client, which exposes that logic and adds weight to the client
could be called unpredictable… in case of Meteor, it only works with methods on the client
Users want real feedback from their products, not fake. In a simplistic context of a chat application, I want to know that if my message or edit shows up in the public feed, that its there for everyone. Usually, I prefer to handle that, and failure scenarios, in a custom way.
@msavin I see your point and I concur. However, you can have 2 separate methods with the same name, not necessarily expose your server side logic. And ofcourse, they get real feedback, because later on it will be patched.
@nickgudumac you are right in the sense that optimistic-ui gives the instant feedback feel and that is great UX. But that can be emulated in other ways. Much easier to do in React than in Blaze that’s for sure, and much easier to just rely on Optimistic-UI it than implement it.
Good point there. My rebuttal would be, then you have to manage updates in two unrelated places. It seems like the right place to manage this kind of stuff is on the UI/data layer.
Not necessarily. Using conditional imports you can separate the “server only” logic so that it is not shipped to the client and at the same time have shared code for the bits that make sense (optimistic-ui updates, validation, etc.).
Using it all the time. I try to stay isomorphic everywhere I can, so I get that for free and I think it’s absolutely amazing. Even the permission model of a very complex app I created is run client and server side. For every react button there is at least two HOC’s: one checks if the button should be hidden because of insufficient rights (calls permission function canUserAddComment for ex), the other binds the onClick to a validated method (postComment). The validated method itself checks and validates the input + runs the canUserAddComment function with additional context. I’m completely aware that the client bundle gives insights into how the inner logic of the app works therefore potentially presenting attack vectors i didn’t think of. And of course it adds weight to the client. All in all I think advantages of isomorphism (and optimistic ui is one of those) still outweigh those minor security and bundle size issues but of course I wish there was an easy way of hiding “isBtnXAvailable” implementation from the client.
of course sometimes there is server-only stuff for various reasons. i call the server side method from inside the isomorphic one in those cases.
We’re using it in most of our Meteor applications. The user wants instant feedback, even if the internet connection is slow. Take a look to WhatsApp, messages are inserted instantly, even if the connection is bad. That has a reason, everything else would feel like a buggy or slow app.
If you want to provide “real feedback”, you can also create server only methods which add a “serverReceived” to a doc so the user is able to see that his action was reflected on the server.
When you use validated methods and keep your code isomorphic you get optimistic ui just by being lazy and not coding everything twice
I really like that feature, but I must admit that there are some problems with it working too well (but at the same time not well enough) sometimes.
I am working on a math practice website that generates math-problems and checks the results. Most of that is done client side and the server is just there to keep scores and to let the teacher watch the results coming in in real time. Even if you loose the connection to the internet altogether you can still keep working without even noticing. When you get connected to the server again your results will get synced with the server (again without you even noticing). Only trouble is: when you close the browser window before you get connected again, everything you did while being disconnected will be lost.
I just ran into that problem two weeks ago and I fixed that by saving all method calls (for that particular method that submits the results of exercises) to local storage, delete the backups in the callbacks from that method and resubmit any backuped submissions that are left local storage when i know that there are no methods cued up for retries.
Would actually be a nice feature (e.g. for validated-method) to just be able to set a flag and have retries persist until next time. That would give you pretty awesome offline-capabilities for ordinary web-apps with just a tiny little persistRetries : true instead of doing a couple of lines of code
And in those cases where you don’t want things to look like they are working when they momentarily aren’t, you can just add a little if Meteor.server in the right place and ruthlessly amputate the part that does that for you for free.
@janmp Did you try GroundDB? The “old” version had an automatic sync feature via localstorage. We’ve used it in a Cordova chat app to sync offline messages.
