Fork me on GitHub
Timofey Sitnikov12:02:13

Good Morning, Just making sure, in the, instead of the app, in the (app/set-root! app ui/Root {:initialize-state? true}) there could be SPA as on the image?

Jakub Holý (HolyJak)16:02:37

yes! pls be so kind and send a fix PR!


I think there might be an issue with RAD/Pathom3 and the Pathom Viz Connector. I'm not entirely certain. Is anyone else using it? I about it the other day but still haven't really gotten to the bottom of it. Since RAD's pathom3/new-processor builds up the env internally, and I couldn't figure out how to get access to it otherwise, I modified the code of new-processor to include the call to p.connector/connect-env like so:

(fn [env tx]
  (when log-requests?
    (rpc/log-request! {:env env :tx tx}))
  (let [ast      (eql/query->ast tx)
        env      (assoc
                   (env-middleware env)
                   ;; for p2 compatibility
                   :parser p.eql/process
                   ;; legacy param support
                   :query-params (rpc/combined-query-params ast))
        response (process env {:pathom/ast           ast
                               :pathom/lenient-mode? true})]

    ;; added this call
    (p.connector/connect-env env
                             (assoc config
                                    ::pvc/parser-id ::env))

    (when log-responses? (rpc/log-response! env response))
And while it succeeds in adding the new tab for the environment in Pathom Viz, it doesn't contain any of the attributes that I defined in my application, only the native Pathom stuff:
I've used Pathom3 with the Connector in a non-Fulcro repo and it worked fine, so I'm inclined to think that I'm either doing something wrong here, or there might be some bug with the way things are set up in RAD.

Jakub Holý (HolyJak)16:02:22

Any resolvers defined manually on the attributes and auto-generated resolvers are just Pathom resolvers (provided they are indeed P3 and not P2?) so they should be visible.


That is my expectation. If I instead use (pci/register [resolvers]) as the second argument instead of the env built up inside pathom3/new-processor, those resolvers are visible.


yeah i hit the same thing and never got it figured out. I can still use pathom viz for inspecting queries n stuff. I thought I just did something wrong and didn't bother to put any more time into figuring out why it doesn't display those attributes


thats a strange set of resolvers, given Pathom 3 by default doesn't expose anything (using p.eql/process), and with the boundary interface it should expose only a single attribute (`:com.wsscode.pathom3.connect.indexes/indexes`)


I guess Fulcro add all the others to make some compatibility with Pathom 2 and current Fulcro Inspect


I'm mostly interested in the index explorer so I can get a visual of it. I guess it is a bit of a bug/miss-aligned expectations between RAD and Pathom3 at this alpha stage.

Jakub Holý (HolyJak)09:02:34

So Wilker is saying that P3 should expose :com.wsscode.pathom3.connect.indexes/indexes but it is not in the list of what @UPWHQK562 shows above (despite a number of :com.wsscode.pathom3.connect.indexes/* being there). Why?


I'm guessing its something related to the specifics of the RAD implementation, I can have a look on it on the weekend to understand better whats going on there


The fulcro-rad-template repo organizes code into / and the guidance is to keep requires to a minimum in model_rad. We still will likely need to require db query namespaces to use in model_rad's ao/pc-resolve, right?


Yes, lib requires are fine, but project nses should be avoided. Putting resolves on the attributes turns out not to be the best idea sometimes as a result

Jakub Holý (HolyJak)09:02:52

I.e. you could instead of ao/pc-resolve define the resolver separately in the model ns (and make sure you register it with Pathom). Right? BTW not sure the reason for limiting requires is clear - I believe that more you require the slower (re)loading of a ns is, i.e. it is to optimize feedback speed during deving


circular requires…the RAD model is very useful for writing pretty much everything from save middleware to UI. If you start requiring arbitrary code in the RAD model files, you will run into circular require problems (and pretty quickly at that)

👍 1

for example, validations on forms: you write something in some ns (say predicates) that checks for something like an email pattern. Then you include that in your RAD files, and then your RAD files are all included in central model for all-attributes. Then you decide that you need the predicates and all-attributes in some other location to make some additional thing. Then later someone writes a new predicate that wants to use that other thing and now you have a loop.


Thank you for the explanation. Makes sense. For ao/pc-resolver, I wonder if it would be helpful to adopt a convention like Fulcro uses for mutations that can't be required: quoting the fully qualified name.


Resolvers are really a pathom concern, and the pc-resolver option was probably a bad idea to begin with (as a standard feature). The RAD model defines the data layer, and the resolvers resolve that. The resolvers should kind of always therefore be a concern that is stacked on a layer above the RAD model.


merging the two sometimes works (esp if the resolver is merely a computed thing that has no deps)…e.g. current time