Fork me on GitHub

What's the latest in best practices for integrating with a GraphQL backend? I noticed some for using pathom's experimental graphql connect layer, but that seems to expose a remote built for fulcro 2, while I'm using fulcro 3. Specifically I'm looking to integrate with the Gitlab GraphQL API. Do people recommend just using a client-side pathom parser, along with the edn->graphql converters?


Nice, thank you! So I could use a client-side pathom 3 parser, and its graphql integration wrapped up into a fulcro remote.


Only "downside" would be having two different pathom versions loaded into the client. No harm from a clashing standpoint obviously but just a bit of payload weight. Not too worried about that at this point though.


Upon closer observation, fulcro doesn't appear to directly depend on pathom 2 :thinking_face: Idk why I thought that was the case. It only assumes you can hand it a (fn [eql] eql-response) . So my downside doesn't even apply.


Hm...actually pathom3 appears to have deleted that GraphQL integration. It doesn't exist anymore.


Ah, it's been factored into its own repo:


Thank you!

😀 1

Does anyone have tried to use clerk with Fulcro (to display components)?


Have not tried it yet, but I was reading the overview of clerk and had that exact kind of question…wonder how we’d hook that up?


I’m wondering if clerk support rendering Fulcro component. I don’t know. Do you have tried with ?


so, Fulcro components expect cljs props, not js, so while you can adapt them to work with storybook, they are really meant to exist in the CLJS ecosystem.


this might be stale, but I did have storybook working with fulcro here: (it's a bit messy) mostly just copied the workspaces code


I heard about clerk in a podcast (might have been "defn"?), if I remember correctly they mentioned fulcro briefly. Maybe I can dig it up real quick


Ah I miss-remembered, they where talking about


It seems to me that com.fulcrologic.rad.form/save-as-form mutation has a bug/problem. If i try to introduce an entirely new entity it will not resolve tempids correctly. A call such as

(let [data {:my/id (tempid/tempid)}]
 (form/save-as-form {:root-ident (comp/get-ident MyEntity data) :entity data}))
will only add the entity to state after tempids resolving has been done. This is because it’s done in ok-action. Even if temp ids were correctly resolved, the value would get overwritten by form.cljc:603


(swap! state update-in root-ident merge entity) is basically guaranteed to nuke any resolved tempids


could be…open an issue with a minimal case…is tempid resolution working for you otherwise?


Is there a way to add a post-action to a comp/transact! call without modifying the mutation itself?


the transaction behavior of a mutation is defined within the mutation


You can pass things via the options map after the txn, and those will show up IN the mutation env as ::txn/options (I think that is the key)


so you can pass in a lambda that way


but some mutation’s result/ok/error action will ahve to pull it out and invoke it. Your other option is to redefine how mutations work…see default-result-action…it is configurable


Thanks! Sounds like it's not something encouraged... what would be a good pattern to follow if I want a mutation that does different post-remote action when called by different UI components? Or am I thinking it wrong?


The problem with passing in lambda is that I have to write my own (remote ...) section to get rid of this lambda option before sending it to the wire. Which is a burden on every such mutation.


And I don't think changing default-result-action is something I wanted... I only need this behavior on a few mutations


no no…the options map of the transact! call: (transact! this [(m)] {:f (fn [])})


then in env you’ll see that map under ::txn/options…there’s no wire involved…it is just an open map in which you can pass data on the client side into the machinery


also note that ref is in env, and is the ident of this that was used with transact! (if you used a component’s this)


so, in some cases you can base the behavior on the ref, and the txn options are handy when there is some logic you need to pass to a mutation


That makes more sense, thanks!


@U6SEJ4ZUH I implemented if you're curious. In my situation I've since come to think it's better to just use the standard transaction system instead (`on-result`, etc.), but YMMV


@U49U72C4V Thanks a lot! I think I will go with the standard transaction system for now. Very cool application you wrote there BTW!


thank you 🙂 it's still a mess but I'm glad it seems to have been useful to look at for folks


I'm having trouble including a nested router in a RAD form, where the routing target is a RAD report. I'm getting his with these two errors and can't figure out the cause: When I examine r there, it's a map with only one key, dr/pending-route. And I verified that the ident passed to dr/route-deferred and dr/target-ready are the same. I have made sure to: • compose nested router's initial state + query into parent • use :pre-merge to create edge between parent's data and child router • preserve any existing router state Is there something I'm missing? I guess I will try using a plain defsc as the parent instead of a defsc-form and seeing if that helps, but I'd sure like to understand why I'm having this problem. Update: with a plain defsc it seems to work fine :man-shrugging:


does it work and SHOW an error, or fail?


oooo, actually nesting ANYTHING that isn’t part of the state of the server in a form is not quite right


they are not meant to be composed thta way. Forms have a dynamic ident, so the sub-router would have to be re-embedded every time you go there…initial state won’t do it


so, you’d either have to modify the form state machine to do the right thing to the state of the form as it loads or creates (two different code paths), or compose the form and route next to each other instead of nesting it. It really makes little sense to me to nest a router in a form.


Thank you for the explanation! That makes more sense, and also explains why it works without a hitch when using a plain defsc for it. On the bright side, trying to make this work has given me a lot more time looking at the Fulcro and RAD source 😄 I know it sounds a little strange to include a router in a form. I was trying to stick to just using RAD components as much as possible and wasn't totally sure it was unsupported. My idea to do it traces back to my need to combine forms and reports. The ns in the demo repo does it by putting a form in a report. My use case requires multiple report tabs, so I thought to do the reverse of the demo and include a series of reports in a (read-only, FWIW) form with a tabbed layout to switch between them, using a router. That's how I arrived at this point 🙂 In looking at the source, it looks like defsc-containers almost support forms. I tried to make some modifications there to see if I could do it neatly but it's a little beyond my abilities right now to pull it off in a short enough time. My opinion is that containers are a fitting mechanism to allow users to combine the two main UI constructs of RAD. Perhaps it could be a consideration for the future of the API? Appreciate your input on my problem. I'll push some documentation changes to RAD at some point to include some of this info for posterity.

❤️ 1

Yeah, containers are pretty alpha. Really the model is intended for you to invent your own soln’s when you get to needing more complex things, just using similar (reusable) patterns.


I mean, just having a reusable “save” and some field renderers goes a very long way towards making things much easier.

👍 1