This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-04
Channels
- # architecture (5)
- # aws (11)
- # aws-lambda (1)
- # beginners (108)
- # boot (11)
- # cider (37)
- # clara (19)
- # cljsrn (72)
- # clojure (170)
- # clojure-austin (2)
- # clojure-dev (1)
- # clojure-dusseldorf (2)
- # clojure-italy (1)
- # clojure-spec (41)
- # clojure-uk (24)
- # clojurescript (113)
- # component (2)
- # core-async (29)
- # cursive (9)
- # data-science (5)
- # datomic (72)
- # docs (23)
- # duct (61)
- # editors (1)
- # emacs (1)
- # events (5)
- # fulcro (77)
- # graphql (2)
- # hoplon (4)
- # jobs (3)
- # jobs-discuss (16)
- # leiningen (5)
- # off-topic (94)
- # onyx (37)
- # precept (5)
- # re-frame (17)
- # reagent (11)
- # shadow-cljs (18)
- # spacemacs (107)
- # specter (3)
- # unrepl (64)
- # yada (1)
@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 load
ing 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.
See the docs: http://book.fulcrologic.com/#DataFetch
and also this video: https://youtu.be/mT4jJHf929Q
@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
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
Here's an introduction by the author https://skillsmatter.com/skillscasts/9820-enter-integrant-a-micro-framework-for-data-driven-architecture-with-james-reeves
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
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.
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.
http://book.fulcrologic.com 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)." -- http://fulcro.fulcrologic.com/guide.html#!/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.
Oh damn, awesome!
You make me and @timovanderkamp very happy
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
@roklenarcic Yep…that ok?
it's just a bit ugly so I thought you did it on accident 🙂
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