Fork me on GitHub

ok, so the module is compiling and loading, but now it seems that the set-query! is not working, or rather that the routing target component is not getting the query update by the time it renders, since it still has the initial temporary [{:loaded component [*]}] query when the attempt is made to load its new query's component to render it: (some-> this prim/get-query prim/query->ast1 ,,,) call. However the new query IS visible in the router's list of queries and components inside of Fulcro Inspect.


the call to get-query needs the state map


(get-query this state-map)…dynamic queries are resolved via the state map. There is a dynamic var that supplies that during render, but outside of the render loop it has to be manually supplied (or the dynamic var set).




Open an issue if that’s in the dr namespace


(and thanks for trying it out 🙂 )


Is there an idiomatic way to use react’s renderToStaticMarkup?


Or rather, on the server, some call analogous to renderToStaticMarkup


If you run server-side in node, then all js libs are available…In Fulcro, we have to have clj code that can “interpret” the UI…so, render-to-str is actually a CLJ implementation of React’s server render stuff.


that’s a great idea! running it on node would be perfect for my use case


It looks like fulcro/pathom makes heavy use of namespaced keywords in queries (“input” “output”). It makes sense to me now, but I am curious: this looks like it would fit well with datomic (which I don’t use). Do people do things differently with ex. SQL / other databases? Do they add an extra step in the resolver (like prefixing elements with the table name)?


@nha in my current project I am using PostgreSQL as a database, and yes my resolvers do have a step to prefix elements. Perhaps I could abstract it away but for now I have kept it very explicit, e.g.:

(defresolver course-resolver
  [env input]
  {::pc/input #{:course/id}
   ::pc/output [:course/name]}
  (let [course (Course (:course/id input))]
    {:course/name (:name course)}))


ok, I was thinking about doing something similar - thanks for the data point 🙂


No problem 🙂 Also, I have found it useful to only provide IDs for references. For example:

(defresolver course-resolver
  [env input]
  {::pc/input #{:course/id}
   ::pc/output [:course/name {:course/task-sets [:task-set/id]}]}
  (let [course (Course (:course/id input))
        task-sets (map (fn [{:keys [id]}] {:task-set/id id})
                       (db/select TaskSet :course_id (:id course)))]
    {:course/name (:name course)
     :course/task-sets task-sets}))


Then a “task set” resolver can pick up from there and load more data


performance-wise it’s not ideal as it suffers from the N+1 queries problem, but conceptually it’s nice imho


you can optimise performance later


You could also look into something like (I haven’t used it yet)


Interesting, I am not sure yet how I am going to model my queries so thanks for that 🙂