Fork me on GitHub

@roklenarcic is that not clear in the docs?


lazily-loaded and fetch-stte should probably not be used. Use the new marker support instead.


I'm trying to parameterize a property with [(:prop {:x 1})]but fulcro-sql throws exception Graph query failed: java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast to clojure.lang.Named


has that been implemented in fulcro-sql or was I doing it wrong?


also, the syntax for easy filters in fulcro-sql is {:table/column {:op value}}, which looks like a join. I just think a list like parameterized property should look better. Opinion?


hey all, struggling to figure out how to reconcile joining the queries of child components with how that data gets forwarded to a remote/server. let’s say I have a root component which has a child component navbar. the query for root might look something like:

[:ui/react-key :some-prop {:navbar (prim/get-query Navbar)}]
let’s assume the query in Navbar has some data that needs to be resolved server-side. in the started-callback of my client, I’m loading the query pulled from Root, which sends the whole query over to the remote. what I’m struggling with is how to separate the ui concern (that the root joins the navbar query into its own with the navbar keyword) from the server concern (that it feels weird to write a server-side parser for a ui-related key, i.e. navbar). obviously, we need to resolve whatever data the Navbar component needs from the remote, but I’m struggling with how to elegantly separate the requested data from the ui-specific location of that data. am I thinking about this wrong? how do people handle cases like this in their server parsers?


@myguidingstar Parameter parsing has not been implemented in fulcro-sql. You’re probably right on the syntax. The library is very early in its life. At the moment it is really raw and could use some contributors 🙂


@mss Load is not intended to use your entire root query…that would mean you’d have to do exactly what you’re saying: parse the UI query on the server!


What you want to do is queue up loads for the entities/components that have server data. This eliminates the complexity of process-roots etc that Om Next had.


If there are UI-specific things in a component, then use the ui namespace for those props and load will elide them from the query to the server.


Thanks, really appreciate the clarification!


@tony.kay fyi I'm trying to use Fulcro with James Reeves' Duct application/configuration framework


I've made fulcro-server and fulcro-sql work with Duct


interesting. let me know how that goes 🙂


Basically, Duct is Component but improved


The combination of Fulcro and Duct should be amazing


I'm working on the cljs part of the combination


but I hope you give Duct a try


kinda short on time personally, but would love to see what you end up with


cool, thanks


Given Fulcro's size, I'm sure it will benefit from Duct modularity


There’s actually not that many components…Fulcro’s really not as big as you think, I think


The server has, like 3 components.


Okay, fulcro is not, but fulcro-template is 😛


the template has a decent amount of code…but still not many actual components, does it?


I’d be open to a contribution to the lein template (as an option) that would emit a server that uses Duct. The rolling your own server part of the book would make it easy to build such a thing.


but of course it’d have to have all the features: start/stop/refresh server code.


If there’s an easy way to add Duct-like support to fulcro-sql without forcing a dependency on the users, then I’d be open to that as well


indeed, I was reading that part for the combination


same goes in Fulcro. I’m trying not to cause dependency hell for people, but options are nice. The lein template seems a nice place to give that.


I’ve had similar requests for “mount”


+1 on Duct.

tony.kay08:01:20 updated. Thanks to @fatihict for doing a lot of proofreading and submitting a huge list of things to fix.


is it normal that the (remote [env] ....) s-expr in defmutation gets called twice in a mutation?


I was debugging some issue and I was surprised to see that is gets called twice, once with :target nil and once with :target :remote.


Fulcro developer guide on mutations: "Specifically all mutate functions must themselves be side-effect free. This is because they can be called any number of times (to gather up what should happen locally vs. remotely)." --!/fulcro_devguide.G_Mutation


looks correct to me, maybe change any to multiple. A confusion that might raise is between calling the multi-method vs calling the action. The action will be called only once, but your mutation multi-method will be called N number of times (N = number of remotes + 1)


So if I have (remote [env] ...) and (rest-remote [env]), they will both be called three times with :target parameter null, :remote, :rest-remote?


the remotes are setup by the network property when you start a fulcro app, by default it will only call 2 times (one for :remote and another for :action), you have to add extra network remotes to call the other ones (like :rest-remote)


I know that. I assume that it will call each remote s-expr once for each remote I have defined + null.


Yes, that’s correct. If you use the multimethod directly, then you could use a case on target from the env to cause only one code path to execute per call if that is something you need. target is set to nil for local, and each remote in sequence.


@roklenarcic sure, I only said that so it's clear that if you just add the methods on your multi-method it doesn't mean they will be called automatically, there is the network step also involved, but I guess you already knew that 🙂


@tony.kay what's the reason for that? Seems wasteful to run ast transformations that are defined in s-expr multiple times with different :target, since each s-expr defines behaviour per each remote already.


@roklenarcic It's legacy behavior from Om Next, and is necessary to maintain backward compat since you could have written mutations to depend on target being set. Only way to see each target is to run it for each target.


Yes, that’s correct. If you use the multimethod directly, then you could use a case on target from the env to cause only one code path to execute per call if that is something you need. target is set to nil for local, and each remote in sequence.


2.0.1 on clojars. Fixes a bug in transact follow-on reads


this was the problem with form root key


Oh damn, awesome!


You make me and @timovanderkamp very happy


also updated 2.1.0-SNAPSHOT with the patch


will lein pick up new snapshot automatically? never worked with snapshots before


It will check for a newer version


good to hear it's fixed. I ran into the bug via some unrelated behaviour and I was going mad trying to debug it.


We are sometimes wrapping stuff in third party stuff, so we were thinking that was the problem


Yeah, turned out that when I added the declared refresh to mutations I accidentally forgot to combine back in the literal follow on reads.


tony you seem to have merged my repro case into codebase


so, no follow-on reads were working right. Not sure how it got missed for so long


it's just a bit ugly so I thought you did it on accident 🙂


the cards build is for things that are nice to manually check on releases


If I add sufficient automated tests (which I should, but primitives is a lot of inherited code) then I might remove it from cards.


@mitchelkuijpers I had to run lein -U deps to refresh snapshot


-U flag being the relevant part here


Aah ok, maybe it only checks once a day or something like that, thnx!


lein uses maven local repo, so same rules apply, even the switch is the same as maven's forced update switch


it always updates here, except when it gets broken, but to me this only happen like once in a couple months


must be my local m2 repo settings then


I work with a lot of snapshots in my java consultancy


and building a project composed of snapshots when each time it would look for updated versions would be too slow