Fork me on GitHub

For simple things you could make a function that does the actual request, and memoize it


@lilactown I'm aware of but not experienced with Fulcro. I've seen a number of references to Fulcro tools (guardrails off the top of my head) in Pathom source. Any chance the client caching might be usable outside of fulcro? Otherwise I'll probably do something simple like @tomi.hukkalainen_slac suggests


I know that there have been docs and examples of using fulcro's data management system w/o going whole hog to define components. it has looked pretty complex when I tried to understand it (having not used Fulcro in anger)


here's the docs on "Fulcro Raw" which seems to be that. it's very heavy on the lingo


I would probably start with what Hukka said (that's what we're doing in our pathom + reagent/helix app). over time we hope to evolve to adopt either Fulcro raw or a home grown solution for caching


Awesome, thanks @lilactown for the info


ANy chance you've tried react query with pathom etc?


Was just reading through that and thinking about trying it


I haven't but I wouldn't discourage you from trying. you could perhaps key the query based on the top-level keyword of the EQL query you're making, and that might be a sane default



[{::foo/bar [:baz]}]
could become
(useQuery #js ["foo" "bar"] ,,,)
no idea if that's actually good in practice, just an idea 😄


actually that would probably cause issues... since any other dependent on ::foo/bar would only see :baz, even if they previously asked for more data


anyway I'm interested to see if you come up with a good system! the benefit of react-query is it does give you control over how you cache and invalidate it


yup, having similar thoughts about coming up with an EQL to path like translation. Need to read more about how those paths are used and what they consider. Will share if I get something interesting


I’ve been playing with Fulcro Raw and I think with some extra helpers it gets to a quite simple and easy to use stack, I can share with you if you want, but its only an experimental thing (I haven’t tried to use it in a bigger way to see if there are any perf issues)


this is what a component looks like in this model (and I’m using Helix for the component building, and Fulcro Raw for state management):


(h/defnc Main []
  (let [{:keys [app/todos] :as props}
        (frs/use-entity (frs/load {:app/id "cide"})
          {::frs/query [:app/id
    (dom/div {:class "bp3-dark m-12"}
      (if (:ui/load-error props)
        (bp/callout {:intent "danger"
                     :title  "Error"}
            (ex-message (:ui/load-error props)))))
      (h/$ PeerConnectionDemo {})
      (dom/h1 {:class "mb-4"} "Todos")
      (h/$ NewTodo
        {:on-create #(frs/transact! props [(add-todo (assoc % :app/id "cide"))])})
      (dom/hr {:class "my-4"})
      #_ (bp/button {:onClick #(frs/load-component! props {})} "Reload")
      (for [{:todo/keys [id] :as todo} todos]
        (h/$ TodoItem {:key       id
                       :on-change #(frs/transact! props [(toggle-todo %)]
                                     {:component todo-comp})
                       :&         todo})))))


note the frs/use-entity, that's the main thing there


app starter:

(h/defnc AppWrapper []
  (frs/app-provider app
      (h/$ Main {}))))

(defn render! []
  (rdom/render (h/$ AppWrapper) (js/document.getElementById "app")))


app definition:

(defonce app
  (doto (rapp/fulcro-app
          {:batch-notifications (fn [render!] (rdom/unstable_batchedUpdates render!))
           :remotes             {:remote (frs/pathom-remote api/request)}})


but starting with just plain hooks can work as well, the issue is more middle/long term, IME as it grows you may want to start sharing data across components, this is when Fulcro will add a lot of utility (also having Fulcro Inspect is great, so you can observe what your system is doing)


Awesome, thanks @wilkerlucio! I'll get more familiar with Fulcro Raw and try this out


@wilkerlucio this is great, will read through it

🙏 2