Fork me on GitHub
#fulcro
<
2022-07-25
>
janezj16:07:29

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 ") value))} In all my attempts to cache the formatter: (def dfrm (date-time/formatter "yyyy.MM.dd ")) the result is always in the wrong timezone

tony.kay16:07:36

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

janezj15:07:12

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.

Quentin Le Guennec20:07:25

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.

Quentin Le Guennec21:07:40

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}}

Björn Ebbinghaus15:07:01

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?

Quentin Le Guennec09:07:24

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.

Quentin Le Guennec09:07:54

it’s fulcro related, I tested simple recursive pathom queries and it’s working.

Björn Ebbinghaus11:07:15

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?]}]}}

Quentin Le Guennec11:07:47

hmm because fulcro is a layer on top of pathom, it does stuff to it

Quentin Le Guennec11:07:23

Yes, but that’s not my point.

Quentin Le Guennec11:07:23

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.

Björn Ebbinghaus11:07:08

What is the result with this query then?

{[:account/id "EJ2NCAPPk6WSpuv7bwvHAK8sVGV4htZFir242pVCzUEb"]
 [{:account/stakes [:account/vault?]}]}}

Quentin Le Guennec11:07:20

The expected output.

Quentin Le Guennec11:07:39

What I should get running the stakes resolver alone.

Quentin Le Guennec11:07:30

But as the stakes resolver should process the :account/vault query, I should be able to get the :account/vault response in it

Björn Ebbinghaus12:07:45

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?

Quentin Le Guennec12:07:33

It works if I feed an empty env to the process call. I use the the default fulcro parser config.

Quentin Le Guennec12:07:34

well not really an empty env, rather the base fulcro env without the execution plan related to the current resolver call.

Quentin Le Guennec12:07:17

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)

Björn Ebbinghaus12:07:43

I am still confused about that "fulcro env" where do you get it from? A Template? Fulcro RAD?

Björn Ebbinghaus12:07:05

And still the question stands: Why do you call the parser recursively in the first place?

Quentin Le Guennec12:07:28

well that example is not good to illustrate it

Quentin Le Guennec12:07:28

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

Quentin Le Guennec12:07:53

so input -> filter -> extra data pull -> computation

Quentin Le Guennec12:07:47

I can’t feed the extra data as an input because that would mean extra work that’s not needed (not filtered)

Quentin Le Guennec12:07:14

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>)]

Quentin Le Guennec12:07:34

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

Björn Ebbinghaus12:07:48

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“

Quentin Le Guennec12:07:50

it worked in pathom2 tho, the pattern ceased to work after I upgraded

Björn Ebbinghaus13:07:05

Hm. Well, pathom2 and pathom3 use quite different mechanisms.

Björn Ebbinghaus13:07:19

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)})

Quentin Le Guennec13:07:51

Yeah but not with parameters afaik

Björn Ebbinghaus14:07:25

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.