Fork me on GitHub
#fulcro
<
2019-02-06
>
thosmos01:02:10

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.

tony.kay03:02:05

the call to get-query needs the state map

tony.kay03:02:51

(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).

tony.kay03:02:19

prim/*query-state*

tony.kay03:02:40

Open an issue if that’s in the dr namespace

tony.kay03:02:40

(and thanks for trying it out 🙂 )

levitanong09:02:23

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

levitanong09:02:55

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

tony.kay16:02:33

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.

levitanong18:02:14

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

nha12:02:23

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)?

hmaurer12:02:44

@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)}))

nha13:02:41

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

hmaurer13:02:32

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}))

hmaurer13:02:46

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

hmaurer13:02:15

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

hmaurer13:02:19

you can optimise performance later

hmaurer13:02:09

You could also look into something like https://walkable.gitlab.io/ (I haven’t used it yet)

nha14:02:04

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