Fork me on GitHub
#pathom
<
2019-06-25
>
wilkerlucio11:06:03

@codonnell hello, no worries, about 1, I guess that would be ok, but doesn't munging only goes on keys?

wilkerlucio11:06:22

2. I don't remember why is that, maybe just missed, can't think of a case to need to keep as uuids

codonnell11:06:36

Perhaps I miscommunicated 1. The reason I'd like to see tempid? passed through there in addition to demung is so tempid? isn't defaulted to (constantly false) when connect builds graphql queries. I couldn't find a way to pass that predicate in, but that could be my unfamiliarity. Wasn't sure what that had to do munging only going on keys, so trying to clarify.

wilkerlucio12:06:22

oh, I see, I think its makes sense to forward it down

wilkerlucio12:06:52

otherwise, as you found, you can't set it

wilkerlucio12:06:08

@codonnell if you wanna send those changes I would be glad to merge it in

codonnell12:06:06

Will do, thanks for your time.

souenzzo15:06:28

Why ::pc/batch? dont always receive/return "many" ?

wilkerlucio16:06:00

@souenzzo thats for interface/api compatibility, but if you want that pathom has some helpers for you 🙂 you can use the ::pc/transform in combination with pc/transform-batch-resolver to receive consistent input, example:

👍 4
wilkerlucio16:06:34

(pc/defresolver batch-sample [env input]
  {::pc/input     #{:some/id}
   ::pc/output    [:some/output]
   ::pc/transform pc/transform-batch-resolver}
  ; input will always be a sequence now, also note ::pc/batch? true will be automatically
  ; add by the pc/transform-batch-resolver helper
  ...)

mss21:06:59

is metadata on data from a resolver preserved as a parse result is built up? running into this weird case using the parallel parser where some data returned from a root resolver has metadata attached to it. when I actually pull the parse result off the chan returned by the parse call, it doesn’t contain that metadata. kind of at a loss here, and maybe I’m missing something about how core.async preserves/doesn’t preserve metadata under the hood

wilkerlucio21:06:08

@mss, currently there is no assumption on the preservation of the data, there are multiple layers of caching and merging happens in multiple times (specially in the parallel parser), so there is a good chance some meta data is been lost in the process, can you tell me more about what is the use case you have for the metadata? maybe we can find a way around it

mss21:06:17

I’m using ring cookie middleware and depending on the mutation/resolver want to drop a cookie by including a :cookie key in a resolver/mutation result. pathom doesn’t preserve that out of band data if I just include it afaict

mss21:06:47

So similar to fulcro’s impmementation, I was attempting to add metadata with a response transformation fn onto the result with the data to add to the ring response, parse that result later and feed the raw ring response into the transformation fn

mss21:06:30

If you have a better idea for how to accomplish including out of band data with a parse result from inside of a resolver I’m all ears

mss21:06:26

Here’s the fulcro implementation as a reference FWIW. What I’m doing looks pretty similar

mss22:06:32

My inclination is to just put an atom in the env and swap in data in my resolvers that needs to be merged into the response. Deref it post parse and build the complete response

codonnell22:06:33

@wilkerlucio PR with uuid and tempid changes at https://github.com/wilkerlucio/pathom/pull/96. (Is pinging you here about PRs actually helpful or just extra noise?)

wilkerlucio22:06:00

@mss doing the atom approach is totally fine, I do that for a lot of things, including the built-in error system 🙂

👍 4
wilkerlucio22:06:22

you can use the fn env version to always inject a new one, or write a plugin

mss22:06:29

Appreciate the feedback. Really a lovely library to use, thanks for all the work you put in

🙏 4
wilkerlucio22:06:43

thinking a bit about it, in your case, the caller to the parser can send the atom as part of the env, so you have external control over it