Optimistic updates about horizon

[marshall007]

@dalanmiller correct me if I'm wrong, but it seems like this could be accomplished simply by merging the response from collection.store(...) into the original object?

var todo = {
  task: "babelify everything",
  completed: false
};

todos.store(todo).then((result) => {
  Object.assign(todo, result);
  console.log(todo.id) // -> <uuid_from_server>
})

Given that this is so easy to implement in user-land, I kinda don't think we shouldn't do it by default. Especially since it relies on the assumption that people aren't reusing the object they originally passed in for other purposes.

That said, in framework-specific wrappers like for Angular or React, it probably does make sense. I just don't think we should in the core Fusion client.

[coffeemug]

I think the real problem with generating the ID on the server is that it makes optimistic updates really hard (though I'm not 100% sure if there might be an easy way around this).

[dalanmiller]

Can you elucidate that @coffeemug ?

[deontologician]

If the id is created on the server, you have to wait for the round trip in order to find out what the id was, or you have to be able to predict what the id will be (maybe a hash of some information the client has... some other hare-brained scheme)

[dalanmiller]

Ahh sorry, I read @coffeemug's comment backwards before ingesting caffeine, I read creating ids on the client.

But if we do have a means of creating an id on the client with a wide enough key space that collisions aren't a realistic problem, this wouldn't be such an issue right? This is what I've been doing in the quick examples I created under the /examples dir using a javascript UUID generator snippet I found in the React docs.

[deontologician]

I agree, client UUIDs shouldn't be a problem, and it is the easiest way to allow optimistic updates

[deontologician]

We could codify this when we implement #52, we either use the id that the user created or we generate a new one client-side when creating a new document. Something like:

var myDoc = {foo: bar, id: 123}
var myDoc2 = {foo: 'bar'}
fusion.createAndKeepUpdated(myDoc) // id: 123 inserted
fusion.createAndKeepUpdated(myDoc2) // client-side uuid generated

(totally bogus hypothetical api notwithstanding)

[dalanmiller]

That's a good point @deontologician. What if I want to "insert and attach` versus just sync between db and view which is the functionality suggested in #52.

// Insert a document and keep it updated
d = {id: 1, text: "Hello"};
collection.insert(d).attach(); // Modifications on the server come back and update `d` 

// versus

d = {id: 1, text: "Hello"};
collection.insert(d);
collection.find(d).subscribe().attach(d);

[deontologician]

Originally posted by @danielcompton in issue #42

Firebase, Relay, and Meteor have built in latency compensation in their client side libraries. Updates are optimistically applied, and then 'committed' client-side once the confirmation comes back from the server.

As we discovered in our RethinkDB websockets project (pre-fusion), the richer your query model, the more difficult latency compensation is. We were running full REQL queries on the client, it is very difficult to simulate updates without something like Reqlite. Firebase has the easiest time of it because their query model is so impoverished.

Related links:

http://info.meteor.com/blog/optimistic-ui-with-meteor-latency-compensation
https://github.com/neumino/reqlite
https://facebook.github.io/relay/docs/guides-mutations.html#optimistic-updates
https://www.firebase.com/docs/web/guide/offline-capabilities.html

[deontologician]

For email people: title changed from "Document state boomerang? (Optimistic updates)" to "Optimistic updates"

[segphault]

I built a simple example of an app with optimistic updates using Horizon and FreezerJS: https://github.com/segphault/rethinkdb-optimistic-demo/blob/horizon/client/tundra.js

I needed to set the id for new objects on the client side, as expected. I used a simple third-party uuid library from npm for that.

[dalanmiller]

Are we still down for adding horizon.uuid() to the client API?

[deontologician]

I don't think this by itself solves optimistic updates quite yet, at least with the default .watch({ rawChanges: false }) setting. Once we have document versioning and timestamps in changefeeds, we should be able to cook something up.

I am ambivalent about putting .uuid() in. Essentially we'll just be re-exporting a dependency, so I don't know if there's any good reason to put it into the Horizon object. Though I don't have a strong opinion