3 ms·
I've built a RethinkDB-Meteor integration using ReQLite and Meteor's stack: (https://github.com/Slava/meteor-rethinkdb https://github.com/Slava/meteor-rethinkdb
by imslavko 11y ago
I've built a RethinkDB-Meteor integration using ReQLite and Meteor's stack: (https://github.com/Slava/meteor-rethinkdb https://github.com/Slava/meteor-rethinkdb).
I see that your TODOs list has "Optimistic UI updates", I worked in this direction and figured there are multiple things blocking such architecture in RethinkDB:
- https://github.com/rethinkdb/rethinkdb/issues/4307 https://github.com/rethinkdb/rethinkdb/issues/4307
- https://github.com/rethinkdb/rethinkdb/issues/2727 https://github.com/rethinkdb/rethinkdb/issues/2727
Something you might want to consider when you decide to implement it.
- mikemintz 11y agoHi Slava! Your project was immensely helpful for me to figure out what's possible. Optimistic updating is definitely the biggest and most challenging feature on my roadmap. I figured I'd save it until last so that by the time I start working on it some of those kinks would be figured out :) but I'm going to take a close look at the blocking issues. Even when those RethinkDB issues get resolved, I still have some conceptual questions understanding how to make arbitrary queries update optimistically. For example, say that I'm subscribed to: r.table('proposals').pluck('name') And I issue the following update: r.table('proposals').filter(r.row('votes').eq(0)).delete() On the client side, because I used the pluck('name') operation in the subscription query, we can't possibly know which rows to optimistically delete since we didn't download the 'votes' field. Do you know how this issue is addressed in meteor? I'm currently thinking I'll have to limit optimistic updating to queries that follow a simple structure, but I'd love a more general solution.