This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-28
Channels
- # announcements (12)
- # babashka (87)
- # beginners (84)
- # calva (22)
- # circleci (4)
- # clj-kondo (46)
- # cljdoc (6)
- # cljsrn (15)
- # clojure (87)
- # clojure-europe (18)
- # clojure-uk (7)
- # clojurescript (20)
- # community-development (3)
- # conjure (1)
- # cursive (13)
- # datomic (14)
- # events (7)
- # fulcro (27)
- # graphql (31)
- # helix (8)
- # jobs-discuss (1)
- # lsp (43)
- # malli (11)
- # meander (64)
- # off-topic (7)
- # pathom (26)
- # polylith (9)
- # practicalli (2)
- # re-frame (33)
- # reagent (2)
- # reitit (5)
- # releases (2)
- # rewrite-clj (2)
- # shadow-cljs (69)
- # specter (5)
- # sql (1)
- # tools-deps (85)
- # tree-sitter (1)
- # vim (3)
In lenient mode, when I query a field with (pco/? :field) and the field is not returned by the resolver, I get an attribute error, but I would expect no error, the field should simply not be in the output (or do I miss something?)
no docs yet,but would be nice to have
about this specific issue, I fixed already, but I left home and forgot to push :face_palm:, will push once I get back home in a few hours
but I suggest you can start familiarizing with the namespaces and how the concepts are organized
Im happy to go over any questiona you have on it
pushed
Now I don’t have the errors when the attributes are declared in the resolver pco/output, but if they’re not, an EQL query with a (pco/? :undeclared-output-key) will add an attribute error :com.wsscode.pathom3.error/attribute-unreachable It forces me to declare all the possible output keys in my resolvers, which I wanted to avoid, is it a wanted behavior?
When I think about it the error is legit, what I would want actually is to declare the strict minimum in my resolvers, only some keys and what’s necessary for joins, but the rest would be fed from the resolver data when possible, a kind of a new kind pco/?
, maybe a pco/try
or something like that
just seen your issue https://github.com/wilkerlucio/pathom3/issues/81
> In lenient mode, an optional attribute missing on the index adds an error, it shouldn’t by “missing on the index” you mean it’s not available in a reachable pco/output right ? (Oh no this corresponds to the one just after it, I understand it’s in the case where there is no pco/output at all corresponding to this in any resolver in the env)
missing on the index means there is no resolver that contains that attribute at the resolver output root level (nested levels have a different process)
in strict mode, when I request only an optional attribute, pathom will still throw. is that expected?
example? and consider the comment I sent on the other message :)
in general it seems if there isn't a path to an attribute it doesn't matter whether it's a pco/? or not
in strict mode, exceptions will always flows up
the exception is if the attribute has multiple options and only some of them fail, in this case it doesnt throw
ah, yes, thats correct, in strict mode if you ask something not on the index, always a failure
but this is not set in stone, thinking a bit more about it, maybe makes more sense to ignore that optional in case of absense
I'm thinking that it should behave the same way in inputs and queries, and in inputs its not an exceptional thing if the attribute is not in the index at all (for optionals)
at least my intuitive expectation is that if a requested attribute is optional, it should have no effect at all on the rest of the query, and all the processing steps done solely for its sake should be considered lenient, but I can see how that adds a lot of complexity to pathom
not being able to find an optional attribute also adds an attribute error to lenient mode btw
thanks for the input, I opened an issue, should address them soon: https://github.com/wilkerlucio/pathom3/issues/81