Fork me on GitHub
#pathom
<
2021-01-27
>
royalaid05:01:33

Hey all, trying to build pathom-viz on windows here and it looks like in order to get shadow to actually compile I had to run:

npx shadow-cljs --aliases dev:dev-ws:electron:provided release electron-background electron-renderer
this replaces the
./script/build-electron
step in the docs

wilkerlucio14:01:19

did you tried on master? I tough I fixed that yesterday

wilkerlucio14:01:25

but I also didnt got to test on windows, after that command it ran fine for you?

royalaid14:01:15

Yeah, I have pathom viz running

royalaid14:01:41

It seems like the exe isn't one file and you have to keep it in the build output location

royalaid14:01:52

but other than that, it seems to work

wilkerlucio14:01:22

glad to hear, please let me know if you find any issues

royalaid14:01:06

copying from the query output seems... odd? Like I think I can paste into that field

royalaid14:01:53

and using node+async seems to cause issues with the autocomplete, all my resolvers don't show up in autocomplete, and the trace seems incomplete an ungraphed

royalaid14:01:16

And those resolvers do show up in indexes

royalaid14:01:34

I am not sure its my graph being poorly built or if it is something with pathom viz

royalaid14:01:17

Also if I toss a query that is malformed or impossible I lock up the UI

wilkerlucio14:01:43

resolvers don't show auto-complete, just the attributes

wilkerlucio14:01:58

async should be ok, Pathom 2 or 3?

wilkerlucio14:01:23

(also, attributes are contextual, the options depend on your query path)

royalaid14:01:12

and to be fair, I am just assuming async is the problem which, on reflection, probably doesn't make a lot of sense

royalaid15:01:22

re the resolver and attributes comment, I meant the attributes that I have added via resolvers

royalaid15:01:38

pathom's built-in's seem to show up

wilkerlucio15:01:12

probably a dependency thing

wilkerlucio15:01:20

at root you only see what is globaly available

wilkerlucio15:01:37

but if you start a query, let's say: [{[:user/id 123] [CURSOR_HERE]}]

wilkerlucio15:01:45

at that point, it should show up things that are reachable from a :user/id

wilkerlucio15:01:59

support for data from Placeholders is coming soon

royalaid15:01:05

Ahh problem seems to be that I rely on two inputs to my resolver

wilkerlucio15:01:15

if you have some entry point that provides both, them you can see auto-complete for it

mss16:01:51

hey everyone, what’s the preferred way to inject query data that’s already been resolved in a parent/sibling key into a child query input? attempting to put the relevant key on my input declaration doesn’t seem to be working

mss16:01:33

I figured it would be possible to do something like ::pathom-connect/input #{:user/email :other-thing/id} but that doesn’t seem to be the case

wilkerlucio16:01:07

@mss if I get right, what you need is to place the data in the output of the parent, so it will be available for children

wilkerlucio16:01:33

the input is a declaration of requirement, the data needs to come from somewhere, can you give a small example of what you are trying to do?

mss16:01:21

yeah so I have a fulcro load! call on app startup that’s parameterized by :user/email like so:

(df/load! mounted-app
 [:user/email user-email]
 User...)
that load! hits a series of resolvers that pull user app state. a user has projects, which have goals, which have tasks. within the the resolver for a task, I want to be able to utilize that :user/email key that’s theoretically already resolved by the input entity to pull some state within the resolver. for whatever reason, declaring a resolver with input of #{:user/email :task/id} doesn’t seem to be getting triggered. I’m sure I’m missing something simple here, just not sure what

wilkerlucio17:01:22

this a good time to debug just your parser, use the REPL and make calls direclty to it, use * on the query to see all the data available at that point

wilkerlucio17:01:29

this way I usually can spot where the data is missing

souenzzo18:01:01

@mss in pathom3, placeholders do that https://pathom3.wsscode.com/docs/placeholders in pathom2, you can use :pathom/context special params Your query should look like that:

[{([:user/email "abc"] {:pathom/context {:other-thing/id 42}})
  [:user/something]}]

mss20:01:55

@wilkerlucio what specifically would I be looking for? my query is calling the correct resolver unless I put in the key :user/email in the input set like so:

{::pathom-connect/input  #{:user/email :task/id}
   ::pathom-connect/output [:task/title
                            :task/description]}
the parent/sibling resolvers are getting correctly invoked given an input set of #{:user/email}. not quite sure how to debug that at the repl

mss20:01:38

I would think that since :user/email is both a key satisfied by a query parameter/ident and returned into the response map at my top level user resolver that it would be available as an input key to child resolvers

mss20:01:11

FWIW my query looks something like this:

[{[:user/email ""]
  [:user/first-name 
   :user/last-name 
   :user/email
   {:user/projects
    [{:project/goals
      [:goal/id
       {:goal/tasks
        [:task/id
         :task/status]}]}]}]}]
and my top level user resolver looks roughly like this:
(pathom-connect/defresolver user [env params]
  {::pathom-connect/input  #{:user/email}
   ::pathom-connect/output [:user/first-name
                            :user/last-name
                            :user/email]}
  {:user/first-name user-first-name
   :user/last-name  user-last-name
   :user/email (:user/email params)})

mss20:01:20

I would have expected that :user/email would then be available in child resolvers

wilkerlucio21:01:47

the ident only provides data to the first child level of it, after that each context has only the data provided for it

wilkerlucio21:01:11

you can flow the data down manually if you want, but seems too many levels for me

wilkerlucio21:01:45

another option is have a path to fetch the user id from the task id (if it has a reference to one)

mss22:01:59

What would a path to fetch the user id look like? Something out of band? My initial way of solving this was to reach for storing global data like that in the request and throwing it into the parse env. Is that the best way to go about that?

mss22:01:30

yeah unfortunately within the task resolver there’s no context around what user id exists. I tried to assoc the user/email into the env within the user resolver, but that didn’t seem to work

wilkerlucio22:01:19

it depends on how you data is organized, does your db row/entity for task knows about the user related to it?

wilkerlucio22:01:26

does it have a reference to it?

wilkerlucio22:01:56

a path is just a resolver that gets :task/id and outputs :user/id, pulling that relationship from your database

wilkerlucio22:01:18

but this also depends if your data model a task has a single ID, or if its something else

mss23:01:50

The task knows nothing about the user, unfortunately. It’s currently designed as a one way relationship from users to projects to goals to tasks

wilkerlucio23:01:16

in this case I suggest you do the manual forward down of the user id

wilkerlucio23:01:45

for example, in the reoslver for :user/projects, in each item you add the :user/id you got on that resolver input

wilkerlucio23:01:02

then you do the same for :project/goals, then same for :goal/tasks, makes sense?

mss23:01:21

Yep, absolutely. Really appreciate the insight here. And thank you for all the work you’ve done w pathom — it’s phenomenal software

❤️ 3
jmayaalv17:01:01

@wilkerlucio having several problem with the new pathom-viz app, it’s constantly locking. couldnt’ really see anytyhing in the console log. how can i debug it? i noticed that everytime i paste something app blocks, this is not the only case though.

wilkerlucio17:01:53

you can open the devtools with cmd + opt + i (on mac). or ctrl + alt +i on others

wilkerlucio17:01:56

what OS are you in?

wilkerlucio17:01:14

and you mean pasting at the query editor?

jmayaalv17:01:54

mac (bigsur), dont’ really see anything on the devtool, it just freezes when writing the query

jmayaalv17:01:10

yes, pasting at the query editor. but it’s freezing also when comlpeting a query with an input. example, i am trying to type this

[{[:edge.calendar/code "{{code}}"] [:edge.calendar/name :edge.calendar/code   :edge.calendar/calendarid  :edge.calendar/creation-date :edge.calendar/expired
                                                                    :edge.calendar/status :edge.calendar/workdays  :edge.calendar/weekend
                                                                    {:edge.calendar/events [:edge.calendar.event/day :edge.calendar.event/type :edge.calendar.event/label]}]}]
so when i get here it freezes.
[{[:edge.calendar/code "acode"] []}] 

jmayaalv17:01:32

this is against a pathom2 engine

jmayaalv17:01:18

saw this is in the console when connecting to the remote

main.js:2441 POST  500 (Internal Server Error)
h	@	main.js:2441
l	@	main.js:2442
$APP.cljs.core.async.impl.ioc_helpers.run_state_machine	@	shared.js:7233
$APP.cljs.core.async.impl.ioc_helpers.run_state_machine_wrapped	@	shared.js:7234
(anonymous)	@	main.js:2443
$APP.cljs.core.async.impl.dispatch.process_messages	@	shared.js:7166
processImmediate	@	internal/timers.js:439

jmayaalv17:01:43

no error when the app freezes, just when connecting to the remote

wilkerlucio17:01:35

the engine shouldn't matter because the calculations happen inside the app for auto-complete

wilkerlucio17:01:59

I didn't upgraded to Bigsur, but I heard about some general complaints on performance, I wonder if the version of Electron (which is not very recent) is getting affected by it

jmayaalv17:01:50

might be, i didn’t use pathomviz since upgrading to big sure, let me check if the older version of PathomViz has the same issue

wilkerlucio17:01:22

cool, thanks for checking, curious to learn of your findings

jmayaalv17:01:33

no problem with 1.1.1

jmayaalv17:01:51

pasting works, query i was trying to enter works fine

jmayaalv17:01:06

so i think something it’s going on with the latest version. i am happy to help test it, not sure how though :/

wilkerlucio17:01:27

is it a big index? I did changed the auto-complete algorithm, but I personally only tested on small things, it can it

jmayaalv17:01:08

no, it’s not big at all

wilkerlucio17:01:08

if you have some time to help with debug, you can build the app locally, and try there, using the performance tools from Chrome, in the dev app you will be able to see the names of the functions

wilkerlucio17:01:16

have you used the performance tab from Chrome before?

wilkerlucio17:01:26

(and just to give you context, even if the algorithm was slower, there is a bunch of caches, so it should be slow only for the first letter, after that its the same, so I wonder if the cache is misconfigured)

wilkerlucio17:01:35

or maybe its something else entirely

jmayaalv17:01:39

could it be the cache from the prev version interfering with the latest? ill remove it and try again

wilkerlucio17:01:16

no, this cache is memory only

jmayaalv17:01:55

ok, will check the performance tab and send you my findings.

jmayaalv17:01:01

this a screenscast with the issue

wilkerlucio17:01:07

yeah, and the view is strange too, it shouldn't be black on the right side

wilkerlucio17:01:23

how is the style after you run a query?

jmayaalv17:01:57

the black is the console

wilkerlucio17:01:15

before that, the query results pane part

jmayaalv17:01:16

(dark theme)

wilkerlucio17:01:41

for comparison here

wilkerlucio17:01:55

dark theme shouldn't affect it (unless there is something I dont know about Codemirror6 and Bigsur :P)