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.

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

Can you give an example of how a component would look?

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

Looks like it's for GraphQL only though?

yeah that’s correct

You could always argue that you should have a REPL open and to just inspect your data that way haha

that too ¯\(ツ)/¯

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

hahaha yeah fair

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

Ya. That was a big downside to using Pathom. The tooling for GraphQL looks excellent.

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.

yeah GraphQL made the same mistake as SQL

no programmatic / data API for their queries

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.