This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-13
Channels
- # adventofcode (51)
- # announcements (1)
- # babashka (7)
- # beginners (45)
- # berlin (2)
- # bristol-clojurians (1)
- # calva (38)
- # cider (2)
- # clara (25)
- # clj-kondo (2)
- # cljs-dev (25)
- # cljsrn (3)
- # clojure (112)
- # clojure-dev (6)
- # clojure-europe (5)
- # clojure-nl (1)
- # clojure-spec (15)
- # clojure-uk (93)
- # clojurescript (29)
- # clojutre (2)
- # core-async (78)
- # cursive (24)
- # datomic (29)
- # figwheel-main (1)
- # fulcro (50)
- # hugsql (1)
- # hyperfiddle (1)
- # luminus (1)
- # malli (26)
- # off-topic (40)
- # portkey (12)
- # reagent (22)
- # ring-swagger (1)
- # shadow-cljs (56)
- # spacemacs (24)
- # tools-deps (68)
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
https://github.com/fulcrologic/fulcro-rad/blob/develop/src/main/com/fulcrologic/rad/pathom.clj#L105
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 toosounds 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 []
...
(ui.r/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?
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.
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
And what are you fixing in 3.0.13? Sorry, I’ve been out of the loop for the past week.
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)
but the fact that things weren’t mapped quite right caused things like pre-merge to misbehave
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 early..like 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.
The book needs more detail on that…it is mentioned in this section: http://book.fulcrologic.com/#_pessimistic_operation