Fork me on GitHub
#pathom
<
2021-02-13
>
markaddleman20:02:48

I'd like to ensure that all all resolver inputs are smart-maps. I have written this plugin:

(p.plugin/defplugin as-smart-map {::pcr/wrap-resolve (fn [resolve]
                                                       (fn [env node]
                                                         (p.ent-tree/swap-entity! env (fn [m] (if (psm/smart-map? m)
                                                                                                m
                                                                                                (psm/smart-map env m))))
                                                         (resolve env node)))})
When this plugin is activated, retrieving data from the smart-map results in a StackOverflowException. What am I doing wrong?

wilkerlucio03:02:06

hello, I wanna think a bit more about it maybe there is a different extension point for it., but I would suggest to not mix smart maps with in resolvers, you should try to just make the resolver ask for the most direct input you need, and can you always add more resolvers to the game, doing smart maps inside resolvers will make your runs more unpredictable and harder to debug (and probably running slower, given you have to plan more times than if you delegated to pathom to do in a single go)

wilkerlucio04:02:29

and putting a smart map on an entity is a bad way to do it, because then you add smart map overhead to each and every operation that pathom does (and that can be a lot of merges)

wilkerlucio04:02:59

all that disclaimer said, to make it "work", the wrapper would need to be in another place, write now it kinda of go around the "node execution", the resolver itself is a bit more inner, so I'm considering if I should rename the current to something like ::pcr/wrap-run-node, and use the ::pcr/wrap-resolve to run around the actual resolve, this could allow for a more internal manipulation of what goes in the resolver, and what goes out

wilkerlucio04:02:11

would be a breaking change, but I'm still open for that at this stage

markaddleman14:02:18

Thanks for the feedback. I ended up adding the required parameters to the resolver's input. At first, it seemed a little weird because it wasn't the resolver directly that required the parameter but a downstream function which, in another context, was obtaining its parameters from a smart-map.

markaddleman14:02:04

Right now, I'm leaning towards your opinion: Wrapping a resolver's input as a smart-map is a bad idea.

wilkerlucio14:02:01

in case the distance between input and the calling part starts get apart, one thing to consider is if there aren't more resolvers in between that could add clarity to the process

markaddleman16:02:58

I don't understand this. How would I place a resolver between a resolver implementation and a downstream function?

wilkerlucio17:02:36

this is hard to explain without a concrete example, can you give a quick version of how you doing this, where the input is farther from the resolver call?