Fork me on GitHub

Is there a way to use multiple inputs to a resolver from fulcro df/load! Pathom docs state to set the :pathom/context. I can’t see anything in fulcro about that. One option might be to use the update-query option on load! but that feels a little icky. Any suggestions?


I add middleware to Pathom that migrates the first load’s parameters into the env as :query-params. That allows you to send any amount of info into the env via load params.


That works unless you actually need them to be dependency resolution inputs


(def query-params-to-env-plugin
  "Adds top-level load params to env, so nested parsing layers can see them."
   (fn [parser]
     (fn [env tx]
       (let [children     (-> tx eql/query->ast :children)
             query-params (reduce
                            (fn [qps {:keys [type params] :as x}]
                              (cond-> qps
                                (and (not= :call type) (seq params)) (merge params)))
             env          (assoc env :query-params query-params)]
         (parser env tx))))})

Jakub Holý (HolyJak)07:08:37

does this solve your problem, @U3FKR3KDF?


Only just saw this. Will take a look.

Jakub Holý (HolyJak)07:08:47

FYI RAD uses this to pass report params to resolvers, for pagination and stuff, I believe

Jakub Holý (HolyJak)13:08:37

Hello! I have created a minimal template for a frontend-only Fulcro apps (with in-browser pathom) intended not for prod apps but for learning and experiments, with all the necessary plumbing: Feedback most appreciated!

👏 6

thank you!! have often wanted something like this


Couple of questions, first why use deps.edn at all, if it's frontend only? Pure shadow dependency management would seem simpler


Then other, what makes it not suitable for production? This would be a good addition to the README

Jakub Holý (HolyJak)07:08:52

I've added now deps.edn: Good point. I have not thought of that - and I have no experience with using shadow for clojure dependency management. Also, I expect people to move over to a backend-full development soon and then they will need deps anyway so the overall simplicity is improved this way. But perhaps you have good arguments why to drop tools deps from this template anyway? Also, I would still like to hear your reasons why you wanted a template like this one. I have mine but surely they do not overlap 100% 🙂


I would (and do) separate the backend and frontend, not try to manage the dependencies from the same files, or even same folder even if running a monorepo. Before that meant lein for backend, shadow for frontend, but now deps.edn and shadow.


> I've added now Sounds good! I think there's an important distinction between "Do not do things like this" and "This is not complete, but what is here is valid".

👍 1

Especially since production needs vary awfully lot. Not everything needs the security (if it's really a frontend only service, everything happening locally), or performance. Hopefully error tracking is a universal concern 😉


My reasons to use a template such as this would be to perhaps get a small speedup while prototyping, but I often get the template I need from previous projects. A bigger benefit personally would be to see best practices, especially if the repository/template is kept up to date when practices change

👍 1

Hm, reading it more carefully > npm install # or yarn install sounds at quick glance as a bit misleading. I haven't actually tried, but based on github issues, shadow-cljs does not support yarn2, does it? So this might need an explicit mention that only yarn 1.22 would work (or I guess yarn2 with those node_module compat options set)

👍 1

Continuing on the deps.edn subject, I find that using the shadow-cljs executable directly more canonical and straightforward, than setting up aliases in deps.edn and using the shadow's api for that. So just npx shadow-cljs release main instead of clj -M:build. If more complex build steps would be needed, I would lean to babashka's tasks, since bb is already in the instructions.

Jakub Holý (HolyJak)15:08:14

FYI now has example of using tempid to create a new entity and detecting that a load! failed

🙌 2
Jakub Holý (HolyJak)16:08:09

@U8ZQ1J1RR I think the official template / RAD demo are much better at showing best practices, since this template contains almost nothing 🙂 > I would (and do) separate the backend and frontend [deps] well, you likely want the same Fulcro both on backend and frontend, is this not the separation more error prone? But to each what s/he prefers 🙂 Regarding shadow exec. via npx - I guess you are right. I just remember I had issues with this b/c of some node stuff so I migrated over to clojure cli and never looked back 🙂


You mean server side rendering? I probably wouldn't use that. Just Pathom. But anyway, I'd say there are distinct needs for frontend and full stack apps. Running pathom in the frontend would be very useful when connecting to existing APIs only, especially multiple different kinds.


I haven't had strict coupling between the frontend and backend since rails/django times. Common cljc code (validation etc.) would go to a shared library.

Jakub Holý (HolyJak)17:08:04

No. But there is also Fulcro server - side code, eg to exclude the api endpoint. Much more so in RAD.


Haven't looked at RAD at all yet

Jakub Holý (HolyJak)19:08:41

Ok, I cannot use shadow's :dependencies because I have not been bothered to publish holyjak/fulcro-troubleshooting to clojars 😅


Hadn't thought about that. Not being able to get dependencies from version control sure is a big downside


Perhaps big enough that using deps.edn as default is a good choice for a template anyway, no matter if the template really needs them at first