Fork me on GitHub

What is the fulcro way to add filtering parameters to a query? Want to issue a query with filter params like date range, etc.


(df/load … {:params {:start a :end b}}), then add a pathom plugin that puts the entry point prams into env so all resolvers can see them


that is a “wrap parser plugin” that will merge all top-level params into :query-params and put it in env


namespace your keywords if you think you might have multiple queries merged into one network request that have competing params


got it @tony.kay <> will give this a go .. thanks for tip


@dansudol I’m currently doing this inside my resolvers that take params

(let [params (-> env :ast :params)] ,,,)
but the plugin sounds like a good way to go too


sounds good @thosmos .. will try both


The plugin makes it so you can see them all the way through the graph of resolvers, and not just the entry point one


often you want to control something a layer or two down, but params only attach to the entry-point node


makes sense .. got it


3.0.13 breaks mutation returns that rewrite the AST (i.e. UISM remote mutation return values). Please stay with .12 until I fix that (shortly)


quick question, with the new ‘mutations everywere’ capability, just wanted a sanity check on something. in 2.x we had the initialization callbacks to init time stuff which is where I was handling things like seeing if the user had a valid Auth0 session. I’ve done this in some 3.0 code by just adding my check-session call to the end of the example init call. It calls the auth0 api, then either sets the session info or clears it via a mutation. Is this ‘ok’ at that place in the code?

(defn ^:export init []
(app/mount! SPA root/Root "app" {:initialize-state? false})
(auth/check-session SPA)


In F3, during loads it automatically elides all :ui namespaces keys and the form state stuff, which is great. I was wondering - why not elide the dynamic router keys? Was there a particular reason?


3.0.14-SNAPSHOT is on clojars…doing more rigorous testing now


@mdhaney no, that feature just wasn’t made “wide” enough


it is configurable, and F2 only removed :ui . It should really remove form config joins, ui, routing keys.


If I added it, would you take a PR? I’m in a situation where it would be pretty useful.


I would take a PR that covered all of the ones that are missing, but that would require you to review all current std features and see what to include


Wait, where is it configurable? I was looking for it in the docs last night but couldn’t find it.


fulcro-app The :global-eql-transform


Ah, great. I’ll look into that. I knew I saw you say it was configurable before, but couldn’t find it in the docs.


That affects the query just before network transmission, but leaves the query alone through the rest of the stack


that’s part of what we’re fixing with 3.0.13+….it wasn’t quite at the right spot before


Does it work for mutation joins as well?


it is at the networking layer, so yes, it should


That’s what I thought. Thanks!


And what are you fixing in 3.0.13? Sorry, I’ve been out of the loop for the past week.


The fix to the eql transform stuff didn’t thread things through quite well enough


so .13 uses the wrong tx for merge IF you returned an alt AST from a mutation (which things like load and uism/trigger-remote-mutation! do)


Ah, ok. So I should use the 3.0.14 snapshot if I’m going to try this, I suppose.


but the fact that things weren’t mapped quite right caused things like pre-merge to misbehave


it’s kind of a stack of issues when the middle tx processing isn’t perfect 😜


Domino effect. Gotcha.


I’m concerned that I’m going to break mark/sweep next 😞


Is there a deep reason why simple props with nil values are marked missing in mark-missing fn? That’s kinda a philosophical question of nil punning, but this way I can’t initialize incoming data-tree in pre-merge with nils. Could go with a custom keyword, of course, but that would require more ui-related work.


Also, I wonder what was the reason to check actually missing fields in fs/no-spec-or-valid?. This way all the user fields specs conforms against nils, which seem to complect the properties of the field itself with the :req semantics of its parent spec.


It’s ok for me to monkey-patch, I’m just sure there’re good reasons for such decisions, so insights would be of great value.


OK, I think I got it. Version 3.0.15 of Fulcro on clojars. This should fix standing issues in Fulcro 3.x with pre-merge, eql-transforms, etc. 3.0.13 didn’t quite go far enough


@fjolne.yngling mark missing was a very early add to Fulcro…very 3 years ago. The central idea is only that “if you ask for something and don’t get it, you should remove it”. I don’t remember if/how/when we might have discussed nil punning.


On form state: Not sure I understand your question…why would you ever want it to try to validate the spec if the spec isn’t in the registry? That would just throw an exception.


oh…I think I see your question: your asking why are nils checked in form state spec validator? Because they may or may not be valid values according to your spec? Perhaps you’re seeing something I am not.


Oh, I see…you mean for nested forms? I just didn’t consider that when writing it however long ago that was. I honestly don’t use specs in form validation…I wrote that code more as a demo of how you could do it.


One more note: The internal logic for dealing with how merge works is pluggable. You can override default-result-action and internal-load with your own versions (that can be simple customizations of the built-in ones). No need to monkey-patch.


That will affect loads and mutations system wide.


The book needs more detail on that…it is mentioned in this section:


but if you use the source, it is quite easy