re-frame 2022-04-24 | Slack Archive

Ivan Fedorov13:04:25

Bit myself with event competition. I’m setting db route via :set-route during the initialisation phase, then from a different place comes another :set-route . And they start to compete one sets route then updates url, and that url update in turn triggers another :set-route to make sure that data is in there. While I acknowledge that it’s a bad design, and I’m fixing it – are there any other measures, to ensure that only one :set-route can be accepted into re-frame event queue?

p-himik14:04:21

Such event-based infinite loops are a relatively common thing in similar systems. I don't think there's anything in re-frame to prevent it, but in general people set some flag somewhere to signify that the activity has been triggered by :set-route where that flag tells that activity not to issue new :set-route.

👍 1

Ivan Fedorov21:04:33

@U2FRKM4TW Thanks! Yeah, thinking about some locking or queueing mechanism too

isak21:04:39

Can you call one of the underlying functions directly when initializing, and then just put the route directly in the db without dispatching?

isak21:04:11

Failing that, can you detect if the URL actually needs to change from the present URL, and then just do nothing otherwise?

2022-04-24

Channels