Fork me on GitHub
#re-frame
<
2021-07-26
>
emccue02:07:33

> I have a bizarre problem with callback hell, despite using `async-flow`

emccue02:07:13

> I have a bizarre problem with callback hell, d̶e̶s̶p̶i̶t̶e̶ ̶u̶s̶i̶n̶g̶ because i used `async-flow`

emccue02:07:18

Fixed that for you

emccue02:07:08

it truly just for bootup tasks

emccue02:07:15

and even in that it has some caveats

zackteo08:07:03

Hello, may I know if there is a way to dispatch multiple events on triggering a specific event? More specifically ... I need to be able to dispatch multiple events :on-success in re-frame-http-fx . Or is :on-request what i need? I don't quite get what the getting the raw request entails https://github.com/day8/re-frame-http-fx#optional-handler-for-on-request

p-himik08:07:39

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

zackteo08:07:41

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

Al M16:07:01

Does anyone have a good example of using re-dispatch to handle processing of a large vector of data points? I've got a leaflet map app that plots a few 1000 markers but am seeing a UI hit because the :on-success event handler is then mapping a function over the data before updating app-db. I think the solution is re-dispatch but not entirely sure.

currentoor18:07:13

Is there an open source example project that uses re-frame and graphQL?

p-himik18:07:07

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

p-himik18:07:45

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

currentoor18:07:54

wow what a hilarious example lol

currentoor18:07:26

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

currentoor18:07:37

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.

p-himik18:07:45

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.

currentoor18:07:11

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

currentoor19:07:46

ah sorry, i forgot that was you

🙂 2
isak20:07:52

> 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.

isak20:07:17

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.

currentoor23:07:58

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

p-himik07:07:13

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.

isak14:07:50

@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}]
}

👍 3
Braden Shepherdson21:07:19

here's a general re-frame design question: I have several user actions in my app that require 1 or more "downstream" choices before it can really submit the action to the server. ie. the user chooses to do The Thing, app asks them to make a few other choices, then sends the request to the server. kind of a "wizard" flow. if these were one or two unique wizards, no worries, I'd just bake them in. but instead there's ~20 user actions that each need 1 or 2 downstream choices out of a set of about 6, so I'm looking for something a bit more flexible.

Braden Shepherdson21:07:23

my current best idea is: - put a map in the state that holds the partially-constructed action - put also in the state a list of pending downstream choices - the app would work its way through that list, showing a dialog to the user for the next such choice. - when they make the choice, update the action map and pop the choice from the list - when we pop but the list is now empty, send the action. does that kind of state machine seem sensible?