This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-14
Channels
- # announcements (7)
- # babashka (13)
- # beginners (98)
- # biff (20)
- # calva (3)
- # clj-kondo (5)
- # clj-otel (6)
- # cljs-dev (96)
- # clojure (22)
- # clojure-austin (30)
- # clojure-conj (4)
- # clojure-europe (53)
- # clojure-nl (2)
- # clojure-norway (63)
- # clojure-uk (3)
- # clojurescript (18)
- # cursive (10)
- # data-science (11)
- # datalevin (2)
- # datomic (7)
- # deps-new (1)
- # fulcro (3)
- # graphql (1)
- # gratitude (4)
- # hyperfiddle (43)
- # kaocha (4)
- # malli (15)
- # pathom (6)
- # polylith (2)
- # reagent (3)
- # reitit (2)
- # releases (6)
- # remote-jobs (1)
- # rewrite-clj (45)
- # ring (4)
- # shadow-cljs (47)
- # sql (5)
- # xtdb (8)
What would be the best approach to slurping data from an api into the database? I thought I could make a set of ui less models and resolvers, then create mutations that slurp the data using the models and resolvers, and push it into the database. I'm not sure where to start with this in fulcro really. i have built an entire client for the api in fulcro and that is working well, so things exist in the database that I have put there. What I really want to do is have fulcro query the database, populate the ui, then reach out to the api to be sure the data in the database is up-to-date, and if not refresh the local database with the newer api data. Is this something I should maybe write a dedicated job to do the slurp and populate part on a schedule, and just leave fulcro strictly working from the database?
That is too general of a question to answer well in a chat channel.
There are some simple parts (durable mutations and cahced loading) that you can use in the Fulcro library.
See com.fulcrologic.fulcro.offline.load-cache
I’ve not written this, but here’s an idea that you could implement with a database like Datomic (which has well-defined versions of the server-side database): The UI (via hooks, possibly) adds a subscription to a graph query. The server fulfills that, but as it does, it tracks the IDs of everything returned. Then a diff from that version of the db forward (e.g. the transaction log) can be used to trigger an update (one of the IDs changed, re-push the tree to the client). That solution could work with polling from the client or websockets. Since you “register” the normalizing component as the query to fulfill, normalization will “just work”, as will rerendering.