Does anyone know David's thinking about doing server push to update local data?
In the case of datomic/datascript, it'd be pretty straightforward to push datoms to a client that are within a user's scope. In the case of user scoped data, it should be possible (although not always desirable) to structure your data so that all data relevant to that user is contained within a single graph (the user node is a edge that transitively connects to all data). This means that is you take the initial set of entity ids relevant to the user, any new datoms with entity ids in the initial set are relevant changes, and can be pushed directly to that particular client. Datoms not in the set can be ignored. I've been thinking about how this can be efficiently translated into triggering the correct rereads in the client. I haven't spent enough time yet with the Om Next internals to fully understand what's going on, but my current understanding of is that queries are registered, and that mutations must return queries as :value which then trigger reads. If you just transact the datoms, you won't get rereads because you're not returning specific query :value to be reread. If you're able register the entities used to produce the result of a query (not sure how to do this unless your queries always return entity ids directly or in some parseable format), then you could do the same entity id set contains? to see if the query needs to be reread. However this will only work if the query is a single graph like the above mentioned user data graph. If you have a query that gets a set of edges, for example, all users in the system, as opposed to all todos of a particular user, then the set of entity ids returned by the query is dynamic, and can't be used as described above. Perhaps you could just override the default behavior for edge queries? On Tue, Oct 27, 2015 at 2:20 PM Alan Moore <kahunamo...@coopsource.org> wrote: > FYI: Om Next has new built-in affordances for using pull syntax to resolve > local/remote datom fetching that plays nicely with local datascript > instances. Nothing in Om Next is Datomic or Datascript specific but there > are working examples of using both including the proverbial TODO app. > > If you can't use Om Next you could do something similar in your own code. > David Nolan has put in a lot of thinking around this and seems to have hit > a sweet spot in this area. Replicating all the features/aspects he has > designed in might be a challenge. > > Alan > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/o0W57ptvPc8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescript@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
