Fork me on GitHub
#om
<
2017-05-23
>
dvingo00:05:01

@danieleneal i was looking into the redux extension and it should be possible to integrate cljs data into that

danielneal08:05:57

dvingo: ooh interesting

dvingo00:05:20

@sova did you figure out your problem?

dvingo00:05:05

(def sample-data
  {
   :blog/posts [[:blog/by-id 1]]
   :blog/by-id
   {1 {:blog/id       1
       :blog/title    "Blog post one"
       :blog/comments [[:comment/by-id 1] [:comment/by-id 2]]}}
   :comment/by-id
   {1 {:comment/id       1
       :comment/text     "Hello comment one"
       :comment/comments [[:comment/by-id 4] [:comment/by-id 3]]}
    2 {:comment/id       2
       :comment/text     "comment two"}
    3 {:comment/id       3
       :comment/text     "Hello comment threeee"}
    4 {:comment/id       4
       :comment/text     "Hello comment four"}}
   })

dvingo00:05:50

something like that will work, then you can make recursive queries for comments. to insert a new comment you can insert into the comment/by-id table and the ref to the new comment under an existing comment

danielneal08:05:40

[newbie question] If you want to compose om.next views at the root, but there is no corresponding server side/data query, what do you do?

danielneal09:05:14

I was thinking I should do a union query, but because there is no server union query for the views, it doesn't work

danielstockton12:05:52

I started experimenting with translating Om queries into 'equivalent' GraphQL queries, if anyone is interested: https://github.com/danielstockton/omql/blob/master/src/omql/core.cljc

danielstockton12:05:13

Relay style pagination, very early stages.

danielstockton12:05:23

I guess lots of people will want to maintain a GraphQL API (popularity + familiarity) and I want to allow a smoothish integration with om on the client side, instead of forcing people to maintain two APIs.

danielneal13:05:25

danielstockton: mmm cool! Yeah this is what I'd like to do to too - use om next on the client, but graphql on the server because of popularity and familiarity (and tooling!). My attempt is at https://gist.github.com/danielneal/ae3a1b6ddfc52393dd18c859464a6ec3

danielneal13:05:38

I'm still getting my head round om next on the client though

danielstockton13:05:55

Oh nice, I like how you avoided string concatenation until the very end. I also decided to re-implement my own query->ast in spec unnecessarily, I just felt like playing with spec a bit. Looks like you got further than me, did you hit any challenges that didn't translate very well?

danielneal14:05:43

haha not sure if I got any further, think we just focused on on different bits - I don't have any stuff on fragments or pagination yet... but I have a feeling that the approach should be possible - so long as you stick to a subset of the compatible bits of om.next/graphql

danielstockton14:05:09

Yeah, it's about finding that subset.

danielneal14:05:27

and hoping that it's enough to work with 🙏

danielneal14:05:52

have you used om.next much?

danielneal14:05:08

I'm just trying it out to see if it will be a better fit than reframe

danielneal14:05:18

we've got a graphql server

danielstockton14:05:07

Using it more and more but I don't have experience with reframe.

danielstockton14:05:06

I just felt like I got what om was trying to do, straight away. In general I've found it pretty straightforward. I've written a custom parser on the backend with python/transit but I'm looking to see if I can transition to GraphQL.

danielstockton14:05:19

It's a legacy application, if I could start again I'd pick Clojure on the backend too.

danielneal15:05:23

nice! I feel like I get om on a conceptual level but still got some questions when I try to implement it

danielneal15:05:03

at the moment trying to figure out how to have a ui only way of to compose components together that doesn't affect the server

danielneal15:05:46

basically I was building Search directly in the AppRoot component, but then decided I wanted to name the component Search and reference it from AppRoot

danielneal15:05:53

and that is proving harder than I thought

danielneal15:05:05

think I may have missed a trick

danielstockton10:05:45

You might be interested in these read helpers:

(defmulti read om/dispatch)
(defmulti mutate om/dispatch)

(defn read-join [{:keys [parser query target ast] :as env}]
  (let [ret (parser env query target)]
    (if target
      (when (seq ret)
        {target (assoc ast :query ret)})
      {:value ret})))

(defn read-union [{:keys [query] :as env} union-key]
  (let [union-query (cond-> query (map? query) (get union-key))]
    (read-join (assoc env :query union-query))))

(defmethod read :default
  [{:keys [ast state] :as env} key params]
  (let [st @state
        ns (namespace key)]
    (condp = ns
      "join" (read-join env)
      {:value (get st key)})))

danielstockton10:05:54

It allows queries like [{:join/child (om/get-query Child)}] and you can write the Child query as though it were part of the root query.

danielstockton10:05:14

It calls the parser recursively, there is some more explanation here: https://awkay.github.io/om-tutorial/#!/om_tutorial.E_State_Reads_and_Parsing

stijn12:05:33

that's very useful

stijn12:05:54

my idea to solving this problem had been from the server side, generate both APIs from a common schema

stijn12:05:10

but that's quite a lot more work I think

danielstockton12:05:44

I think that approach would be better but yeah... There are already GraphQL frameworks in all the major languages, my idea was to hook into those with minimal effort.

peeja16:05:25

@anmonteiro It looks like Compassus's root component's query doesn't pick up new queries from the route components that have been hot-loaded (using ^:once). Which makes sense, given how it works. Do you know a way to get it to do that?

peeja16:05:55

Specifically, I'm trying to get changes to queries to take effect when Figwheel loads changes

anmonteiro16:05:02

@peeja oh hrm makes sense

peeja16:05:24

I'm not sure what would be best to trigger rebuilding the query…

anmonteiro16:05:40

I would have to think

anmonteiro16:05:51

patching the root class seems ugly

peeja16:05:12

Does it? That's what Om itself does.

anmonteiro16:05:21

I suppose you could patch the root class on figwheel’s reload hook

anmonteiro16:05:26

not sure if that would be enough

peeja18:05:01

@anmonteiro "you could" meaning I can do that today from the reload hook, or meaning Compassus could be changed to allow that?

anmonteiro18:05:26

meaning Compassus shouldn’t need to be changed, and you could do it today

peeja18:05:39

Oh, sweet. How can I patch the root class?

anmonteiro18:05:40

let me know if you think otherwise!

peeja18:05:51

Isn't that hard to get at?

anmonteiro18:05:04

you have the root class in the compassus application

anmonteiro18:05:15

(compassus.core/root-class app)

peeja18:05:27

I guess I really mean: how would I recalculate what I need to patch it?

peeja18:05:37

Doesn't that only happen when a new one is built?

anmonteiro18:05:07

I suppose we could create a compassus.dev namespace or something that you require with :preloads

anmonteiro18:05:18

where we’d do that for you

anmonteiro18:05:21

feel free to open an issue!

anmonteiro18:05:34

does that sound good?

peeja18:05:58

Oh, could I make a new one and swap it out of the Application's :root-class?

peeja18:05:22

Oh, I guess Om still has the old one

anmonteiro18:05:35

I think the problem is that React reuses instances

peeja18:05:44

Ah, yeah, that makes sense

anmonteiro18:05:50

I would have to think more about it

peeja18:05:50

Alright, I'll open an issue

anmonteiro18:05:03

let me know if you have any ideas too