Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-05-11

Channels

#pathom
<
2020-05-11
>
Aleed14:05:36

why are mutations referenced by a symbol rather than a keyword? i.e. `'user/create` rather than `:user/create`

Aleed14:05:29

also, how to people handle errors client-side? from apollo graphql I’m used to having separate error property, i.e. the query would return {data, errors, loading}, but in pathom error is returned in place of the result. not immediately obvious to me why that is and how to best handle that

wilkerlucio14:05:05

hello @alidcastano, mutations are symbols to separated than from reads, since mutations and resolvers do fundamental different operations (read vs write), this also aligns with Clojure itself, where keywords are usually a way to read information, while lists with symbols are calls. about the error, pathom by default will give the error in a separated property on the map, similar to GraphQL, but IMO for UI development its easier to have the errors close to the entity that failed, there is a helper to do that p/raise-errors

Aleed16:05:22

I was seeing the error as part of mutation result (i.e. {user/create *some error*} ), but perhaps that’s because I have the p/error-handler-plugin configured i tried p/raise-errors but didn’t see it do anything. is it meant to wrap the parser output?

Aleed16:05:52

i.e. (p/raise errors (parse env eql))

Aleed16:05:18

re: symbols. I figured that was the case. just makes it a bit more awkward to use in frontend, since you have to quote/unquote . likely just have to get used to that

wilkerlucio20:05:55

oh, mutation errors always go on the mutation itself, resolver errors will use the gql style

Aleed20:05:23

I’m trying to figure out best way of thinking about this. for comparison, in apollo graphql if a mutation errors out you’d catch the error and data is only returned when promise is resolved. but in pathom mutations result can resolve to both data or errors. so should I always check that result is not an error before trying to use the actual returned data? (I guess that’s the obvious thing to do, but wondering if there’s any non-obvious approach Im not considering)