This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-17
Channels
- # alda (5)
- # bangalore-clj (1)
- # beginners (9)
- # bigdata (1)
- # boot (51)
- # carry (1)
- # cider (9)
- # cljs-dev (22)
- # clojars (39)
- # clojure (118)
- # clojure-brasil (1)
- # clojure-czech (8)
- # clojure-france (2)
- # clojure-italy (5)
- # clojure-korea (9)
- # clojure-russia (9)
- # clojure-spec (17)
- # clojure-uk (42)
- # clojurescript (48)
- # core-async (1)
- # emacs (3)
- # figwheel (1)
- # funcool (3)
- # hoplon (39)
- # klipse (51)
- # lein-figwheel (4)
- # leiningen (2)
- # luminus (5)
- # off-topic (245)
- # om (18)
- # onyx (19)
- # parinfer (1)
- # pedestal (18)
- # re-frame (47)
- # reagent (19)
- # ring-swagger (1)
- # specter (18)
- # untangled (93)
- # vim (8)
- # yada (56)
how does om.next deal with minimizing the load of network requests (ex: less requests, less data - fetch only what you need) if it doesn't have a server side story like facebook's relay/graphql, where graphql is the server and relay the client?
@lockdown: glad you're interested in Om Next! It does provide a server-side story. The Om Next parser (think a function of query->data) runs both on client and server
That's how we can minimize payloads according to specific clients
Minimizing requests works through having queries in UI components: because queries have to compose in the Component tree just like components do, we can grab the whole query for an app and send it to the server in 1 batched request
Hope the above helps, happy to clarify any other questions!
thanks, don't really know much about om, was just skimming through it, definitely want to start playing with it.
so queries are not coupled to the server right? you can add new fields to your api(the server) and existing client queries should just still work?
exactly
and the opposite is also true, you can add extra keys to your client and you don’t need to change the backend
(with the gotcha that it knows how to serve them in the first place)
Any advice to figure out what queries are taking long? I’m getting messages like [676.720s] [om.next] [object Object] query took 37 msecs
And I’m not sure what to do with them
Hmm… If I don’t use any side-effect producing functions like set-query! etc, and return modified AST from a reader, will this reader be hit with the returned AST on next local read, or it’s always produced from components static query?
@alex-glv the static query
Thanks. I am observing the situation where I get different query in AST on one of the reads, I am not sure how I get that. Incidentally this AST is what I return in prev queries, but maybe it’s one of my read keys I pass after mutation
If I (mutate!), then should I pass the full query to be updated after the mutation? What I am doing is basically (om/get-query component) after I mutate smt, say change the route
@anmonteiro regarding the question last week, you can transact! + force w/o a mutation. It works, swell!
hah, awesome! I’ll be using + recommending that trick 🙂