I pathom3 error handling is still undergoing active thought so I'll just through this out there: Using ::psm/error-mode-loud
and guardrails enabled, if the smart map cannot compute the requested key, guardrails throws an unhelpful error. When guardrails is disabled, the smart map returns nil. I'd like to see a useful error message under the loud case regardless of whether guardrails is enabled or not.
Well, I'm not longer sure this is a me problem 🙂
When guardrails is enabled, accessing :a/output
from m
results in an unhelpful guardrails exception.
when a->b
's input is available, the result is what you'd expect
when guardrails is disabled and a->b
's input is not available, the result is nil
. I'm agnostic as to whether this is desired behavior or not.
just checked on it, that guardrails messages are not wanted, something is wrong inside, checking now
@markaddleman should be fixed on master, by this commit: https://github.com/wilkerlucio/pathom3/commit/a6d9c3430f36a3b48a0952bd812fbfb3eb4dc37a
now there is a third type of error ::node-error-type-unreachable
, which covers the case where Pathom can't find a path for some attribute
Thanks!
in loud mode it should throw an exception in case something goes wrong, independent of guardrails
if you are seeing something different, is probably a bug, can you send a reproduction case?
for EQL mode there is a new plugin that I'm about to document, that exposes the errors on the data
New page for Pathom 3 docs: built-in plugins 🎉 ! https://pathom3.wsscode.com/docs/built-in-plugins
it seems like attribute-errors-plugin causes a massive slowdown, from 55ms to 200ms on my api call
gonna check on that, how big are your queries?
@kevin842 can you try again on master please? I made a change that will remove the checks when no errors happen, this should make the standard path (when no errors happen) to stay the same speed
@wilkerlucio: much better now, no apparent perf impact in repl
cool, being honest, you will probably see a bit more when some error happen, but at least will be only for the entries that have error
this cost comes from plan traversing to find the errors, the plugin will do it once for each attribute you requested, and in case of a no-error it has to traverse back until the root, so the cost will highly depend on the graph complexity
I think this can be optimized in the future to reduce the number of required lookups
It turns out this is a me problem and not a pathom problem. The smart map is working exactly as you describe
Is there a recommended way to test pathom resolvers? I would prefer to not have to call my create function before each test of a resolver
👋 in pathom3 you can invoke your resolver as if it were a function. not sure if that works in pathom2 as well
@royalaid if you are in pathom2 you can call the resolver function from your tests like this:
((::pc/resolve your-resolver) context params)
in pathom3 you can call the resolver directly https://pathom3.wsscode.com/docs/tutorial#resolversnot sure if that’s recommended way for pathom2 though 🙂 that’s how we do it.
can map data be combined with EQL idents https://pathom3.wsscode.com/docs/eql#providing-map-data? I am trying to provide both in an eql query but it seems pathom is ignoring at least one of them
I ended up just putting the initial attributes into env and proxing them to params through a resolver
@wilkerlucio Will pathom3 implement parameters like :xform
, :as
, :default
or it will be done only by external plugins?
example?
not planned to do any of that, make your plugins
could the notion of ::pc/mutation-join-global
also be done by an external plugin?
for that there is a new key, the new key is called :com.wsscode.pathom3.format.eql/map-select-include
, the attribute-errors-plugin
does it: https://github.com/wilkerlucio/pathom3/blob/master/src/main/com/wsscode/pathom3/connect/built_in/plugins.cljc#L16-L22
ah, sorry, for mutations is different, but doable as well, if you make a mutation plugin you can do the same there
great! i will investigate. would there be interest in having a built-in plugin to support that old behavior? if i get a solution I can submit a PR if you’d like
only if the feature makes sense as new feature for Pathom 3, but not for compatibility. its on my plans to have yet another library, to make the porting easier, any things that are related mainly for porting should go there