Make the :on-success event handler return an effects map with an :fx vector with multiple :dispatch effects. It's all well documented.

okay! Found it -https://github.com/day8/re-frame/blob/bbb8d9483c2546cfb2c0e810d00bf429d45d704f/docs/api-builtin-effects.md , previously I thought I saw that it needed to be done with a library but think that's something else

https://github.com/day8/re-frame/blob/master/docs/Solve-the-CPU-hog-problem.md

https://github.com/district0x/memefactory

But given its size, I'd say looking at it as a place to get started is a waste of time.

GraphQL is just another query language - shouldn't be any different from anything else you might use.

wow what a hilarious example lol

What’s re-frame’s take on co-locating queries with UI components? Fulcro and Relay are big on that.

I suppose that’s the major difference of graphQL as the query language, if you co-locate it with your UI components. Otherwise yes, it is just like anything else.

Can't speak for re-frame, but as far as I'm concerned GraphQL, being a query language, is not tied to what you have in your db or app-db. Even if you change structure of one of those, you can still use the same queries by changing the part that actually extracts the data. So I'd say that it's alright. Of course you would still have to use subscriptions to get that data - otherwise, there's little point in using re-frame.

@U2FRKM4TW you seem pretty knowledgeable, do you normalize your entity data in re-frame? If so what do you use?

Indeed I do - I have given the answer to that in an earlier thread: https://clojurians.slack.com/archives/C073DKH9P/p1627196861400500?thread_ts=1627165731.397800&cid=C073DKH9P

ah sorry, i forgot that was you

> What’s re-frame’s take on co-locating queries with UI components? Fulcro and Relay are big on that. I think it is fair to say re-frame is against that. re-frame docs want you to use events for that, which means you can't really co-locate them with the view. I used to use om.next back in the day, and that is one thing I miss. In a few places in our codebase at work, we use subscriptions that take the query as a parameter and then do a request, but that is something that doesn't follow the re-frame recommendations. And there is no help with aggregating a query based on the components that will be rendered, for example.

But if you use reitit (or similar), you can add metadata/queries/etc at the route-level instead (e.g., fetch some queries when you enter a route), which gets you somewhat close if your SPA is based on routes.

Yeah I do like co-locating queries with UI, @U08JKUHA9 what query language are you using in your codebase at work? in the few place where they are co-located

Ah, right - initially I thought you meant using data queries for app-db, and used another db just to help describe my thought process. And yeah, re-frame wants you to put such queries in events that are triggered when that view is shown. Without React hooks or something clever - just by using events and maybe global interceptors. It is still possible to co-locate queries and views this way though, at least code-wise - it all depends on how you organize your code. But if by "co-locate" you mean React life cycle-wise, then yeah, you have to go against re-frame's grain.

@U09FEH8GN We made our own, but it similar to GraphQL. For example:

{ :top 10, 
  :field "transactions", 
  :selections [
	:id,
	:amount
	:postedAt
	{:field :project :selections [:id :name]}
  ],
  :order [{:field "postedAt", :dir :desc}]
}

I think so. You also might want to check out https://lucywang000.github.io/clj-statecharts/docs/integration/re-frame/

And https://github.com/MaximGB/re-state