Clojurians Log v2

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

https://github.com/zalmoxisus/redux-devtools-extension

https://github.com/zalmoxisus/redux-devtools-extension/blob/master/docs/Integrations.md

apparently already some work on it too: http://gitlab.xet.ru:9999/publicpr/clojurescript-redux/tree/master#dev-setup

@sova did you figure out your problem?

(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"}}
   })

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

[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?

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

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

Relay style pagination, very early stages.

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.

that's very useful

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

but that's quite a lot more work I think

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.

true

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

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

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?

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

Yeah, it's about finding that subset.

and hoping that it's enough to work with 🙏

have you used om.next much?

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

we've got a graphql server

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

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.

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

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

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

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

and that is proving harder than I thought

think I may have missed a trick

@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?

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

@peeja oh hrm makes sense

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

I would have to think

patching the root class seems ugly

Does it? That's what Om itself does.

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

not sure if that would be enough

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

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

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

let me know if you think otherwise!

Isn't that hard to get at?

you have the root class in the compassus application

(compassus.core/root-class app)

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

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

hrm

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

where we’d do that for you

feel free to open an issue!

does that sound good?

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

Oh, I guess Om still has the old one

I think the problem is that React reuses instances

Ah, yeah, that makes sense

I would have to think more about it

Alright, I'll open an issue

Thanks!

great

let me know if you have any ideas too