This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-25
Channels
- # announcements (9)
- # babashka (38)
- # beginners (41)
- # biff (1)
- # clojure (19)
- # clojure-europe (7)
- # clojure-uk (2)
- # clojurescript (3)
- # code-reviews (30)
- # conjure (4)
- # cursive (8)
- # datomic (32)
- # docker (2)
- # emacs (7)
- # etaoin (2)
- # fulcro (37)
- # graphql (2)
- # jobs (1)
- # jobs-discuss (8)
- # leiningen (10)
- # lsp (36)
- # meander (4)
- # missionary (4)
- # nbb (12)
- # off-topic (1)
- # other-languages (10)
- # pathom (11)
- # re-frame (5)
- # reitit (4)
- # remote-jobs (3)
- # shadow-cljs (13)
- # sql (1)
- # tools-build (4)
- # tools-deps (31)
- # xtdb (2)
in a rad report I have a custom datetime formater. I works, but I think that it creates way to many formatters.
ro/column-formatters {ev/ts (fn [report-instance value row-props attribute] ((date-time/formatter "yyyy.MM.dd
In all my attempts to cache the formatter: (def dfrm (date-time/formatter "yyyy.MM.dd
the result is always in the wrong timezone
You have to create the formatter in the context of a time zone, so a top-level def isn’t going to work. Use memoize if you’re woried about it…but be careful that dt/with-timezone is in effect when the calls happen
I will try to do something, but this is just an optimization based on gut feeling, as you noticed - probably false alarm. On other thread I am deeper in trouble, links between controls are eating my days.
Hello, it seems that calling (parser env <eql>)
within a resolver leads to undefined behavior in pathom3 fulcro. The query doesn’t resolve to the target attributes, whereas the exact same query resolves well in the repl.
To demonstrate it: Given this resolver:
(pco/defresolver stakes [{:keys [parser query-params] :as env} {:account/keys [id]}]
{:account/stakes
(-> env
(parser
[{[:account/id id]
[:account/vault?]}])
(get [:account/id id]))})
And this query:
(parser
{:com.wsscode.pathom3.error/lenient-mode? false}
[{[:account/id "EJ2NCAPPk6WSpuv7bwvHAK8sVGV4htZFir242pVCzUEb"]
[:account/stakes]}])
I get this response:
{[:account/id "EJ2NCAPPk6WSpuv7bwvHAK8sVGV4htZFir242pVCzUEb"]
#:account{:stakes {}}}
Whereas
(parser
{:com.wsscode.pathom3.error/lenient-mode? false}
[{[:account/id "EJ2NCAPPk6WSpuv7bwvHAK8sVGV4htZFir242pVCzUEb"]
[:account/vault?]}])
Resolves to:
{[:account/id "EJ2NCAPPk6WSpuv7bwvHAK8sVGV4htZFir242pVCzUEb"]
#:account{:vault? false}}
Honestly, I am not sure, what the problem is, you are having. You have two different queries, of course you get two different results? Why do you want (/need?) to call the parser recursively by yourself? Could you give an example of a query with the expected output?
The expected output would be:
{[:account/id "EJ2NCAPPk6WSpuv7bwvHAK8sVGV4htZFir242pVCzUEb"]
#:account{:stakes #:account{:vault? false}}}
In short, when I evaluate in the repl a simple query it works as excpected, but when I process a query inside a resolver , it resolves to nothing.it’s fulcro related, I tested simple recursive pathom queries and it’s working.
Fulcro and Pathom are two distinct things, what makes you believe, that fulcro has anything to do here? The query for your expected output would be:
{[:account/id "EJ2NCAPPk6WSpuv7bwvHAK8sVGV4htZFir242pVCzUEb"]
[{:account/stakes [:account/vault?]}]}}
hmm because fulcro is a layer on top of pathom, it does stuff to it
Yes, but that’s not my point.
The issue is related to recursive process calls. On the very basic sense, process query A, query A works. process query A within a resolver, query A doesn’t work.
What is the result with this query then?
{[:account/id "EJ2NCAPPk6WSpuv7bwvHAK8sVGV4htZFir242pVCzUEb"]
[{:account/stakes [:account/vault?]}]}}
The expected output.
What I should get running the stakes
resolver alone.
But as the stakes
resolver should process the :account/vault
query, I should be able to get the :account/vault
response in it
I see. 1. You should define a precise output for your resolver. 2. The env contains state about the current process (like the current execution plan). Maybe this breaks things. 3. Do you use any plugins?
It works if I feed an empty env to the process call. I use the the default fulcro parser config.
well not really an empty env, rather the base fulcro env without the execution plan related to the current resolver call.
but I guess I’m losing some optimization by doing that (like cache in case the part of the sub query has already been resolved within that env)
I am still confused about that "fulcro env" where do you get it from? A Template? Fulcro RAD?
And still the question stands: Why do you call the parser recursively in the first place?
yes, fulcro rad
well that example is not good to illustrate it
basically in that resolver call I compute some result based on some filter of the input, then I need to aggregate extra data to undergo the rest of the computation
so input -> filter -> extra data pull -> computation
I can’t feed the extra data as an input because that would mean extra work that’s not needed (not filtered)
I also can’t feed the data as inputs because the query of the extra data is based on a computer parameter, a date, something like [(list :account/name-at {:date <computed date value>)]
that being said, recursive process calls seemed like a perfectly valid pattern to me, but people seem confused by it, so I’m guessing there’s a smarter way around
Well it is... but the env a resolver is receiving is not the same you put into the process… You should probably ask @U066U8JQJ about how to do this „the right way“
it worked in pathom2 tho, the pattern ceased to work after I upgraded
Hm. Well, pathom2 and pathom3 use quite different mechanisms.
You can have resolvers with multiple inputs
(defresolver first-day-of-current-month []
{:date/first-day-of-current-month (calculcate... )})
(defresolver name-at-first-day-of-current-month [{id :account/id}]
{::pco/input [:account/id :date/first-day-of-current-month]}
...)
(defresolver date-of-last-name-change [{id :account/id}]
{:account/last-name-change (get-day-of-last-name-change id})
(defresolver name-bofore-last-change [{:account/keys [id last-name-change]}]
{::pco/input [:account/id :account/last-name-change]
::pco/output [:account/previous-name]}
{:account/previous-name
(get-name-at-date id (day-before last-name-change)})
Yeah but not with parameters afaik
Hm. You can with placeholders. https://pathom3.wsscode.com/docs/placeholders#provide-data
But I have not enough experienced with these kinds of queries, although I probably have to use them a lot more in the near future.