This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-26
Channels
- # announcements (2)
- # babashka (9)
- # beginners (95)
- # calva (4)
- # circleci (2)
- # clj-kondo (5)
- # clojure (57)
- # clojure-berlin (2)
- # clojure-conj (3)
- # clojure-europe (6)
- # clojure-italy (14)
- # clojure-nl (3)
- # clojure-switzerland (5)
- # clojure-uk (32)
- # clojuredesign-podcast (5)
- # clojurescript (29)
- # clojutre (16)
- # code-reviews (6)
- # data-science (6)
- # datomic (9)
- # fulcro (33)
- # graalvm (2)
- # jobs (1)
- # jvm (1)
- # kaocha (6)
- # leiningen (4)
- # off-topic (3)
- # re-frame (31)
- # reagent (16)
- # reitit (22)
- # remote-jobs (2)
- # shadow-cljs (70)
- # spacemacs (19)
- # sql (9)
- # tools-deps (13)
- # xtdb (2)
- # yada (3)
Events are supposed to represent user intent. Do you guys also use them to initialize components with data from external sources even though that isn't really a user's intent? We are currently doing that but it's a bit annoying to use with re-frame-10x. As you step through the events, if you hit a component's initialize event it will re-issue that and very quickly receive the success event. You aren't able to ever go past the component's initialization event.
Kind of. I use effects to issue a search request. Initializing and any subsequent search is the same thing, only the first happens based on some state in the URL. The entire thing is bound to the back/forward buttons as well.
Right - our setup is somewhat similar. Still have the same problem. A component dispatches an event to initialize. When the response comes back, another event is dispatched.
So is the problem that one event triggers an a call to an API which in turn dispatches another event on returning, or that you’re trigger two events close together, and the order is non-deterministic?
We just use the re-frame-http-fx
lib. So the component will dispatch an event to initialize. That event uses the http-fx to call the backend. On success, the http-fx will issue a success event.
this is going to be an unpopular opinion in #re-frame but I prefer to keep the app-db user/application centric, and use other means to handle data fetching and caching
I've been thinking about going down that route too @lilactown. It is convenient to have all my data viewable in the re-frame-10x UI though.
yeah you do lose some visibility, but I’ve used apollo-client in the past and that was a pretty nice way to visualize all of my external data away from my app data using their devtools
You could always argue that you should have a REPL open and to just inspect your data that way haha
I’m also working on some general tooling for browsing CLJS data… that will help a lot in the future
the thing is external data is actually kind of weird… often you have pieces of it accumulate over time, you need to know when to invalidate the cache and which parts to re-fetch. you might also be merging changes over time based on user input
you can start to tie yourself into knots weaving the logic of fetching / caching / re-fetching data with actual application state and logic
Yeah... We use Pathom on the backend. Right now we just force a data fetch from the backend every time a page loads, even if the data is already present.
It's more cost effective to scale the backend than to spend engineering time writing cache code on the frontend 🙂
pathom might also have it’s own way of caching data? for some reason I thought fulcro had some abstraction over this but I don’t know if it’s decoupled from the full framework
I think it does some sort of caching on the backend. We aren't using it at all in the frontend since it seemed to be mostly geared towards fulcro.
that’s why I like tools like apollo (hopefully there’s something that comes out for pathom like that too), which bundles all the easy wins you can get by representing your data as a graph
I just joined a team that is using clojure(script) across all the stack and I imagine we will migrate to something like Pathom or GraphQL in the near(-ish) future, and yeah, the tooling is what makes me lean more towards GraphQL
the type system is troublesome but I don’t know if they’ll let me invent apollo-client for pathom 😛
May take some time but it'd be super cool! Having queries written in native data structures is a huge win though. Allows for so much flexibility.
We put all data into app-db
An entire class of coordination / sync problems disappear
(other problems do arise when you put all the data in the one place, its just that overall we prefer that tradeoff)
If you are interested in GraphQL, and you are using Postgres, have a look at Hasura
. It is working well for us.
I have been experimenting with the same. What do you use for a client? https://github.com/oliyh/re-graph?