Do you have a hard requirement on using figwheel? shadow-cljs makes consuming js libraries much easier

thanks, I'll consider switching to shadow-cljs

there's a nice helper to get a project setup quickly: https://github.com/filipesilva/create-cljs-app you can then copy config etc from that project to yours

sweet!

if you follow this to the letter you can get a working npm setup for figwheel-main. https://figwheel.org/docs/npm.html

i think there may also be a leiningen template for it

It has been discussed very thoroughly in the past here: https://github.com/Day8/re-frame/issues/137

Thanks, that looks super useful!

Although no clear answer emerges…there are some forks that try to address this problem but they seem kind of sketchy. It’s been an open issue on re-frame for 5 years.

It's been an open issue for other libraries that attempt to gather all the state in a single place as well, like e.g. Redux. There's simply no easy answer to it. Absolutely all approaches have downsides, and choosing one without offending a decent chunk of the users seems to be impossible.

Ah well. Thanks again for the info.

separating multiple instances of the same kind of state under separate keys in the global db and using a parameter in your events and subs to access them would definitely be tedious to convert to, but once it is implemented it definitely just works. of course the instance approach might be nicer in that you only have to specify the frame when you call and not when you write. one approach you might look into is writing a regsub macro that can automatically insert the proper instance subscription and then have that act as the “db” in your subs.

iirc the re-frame docs encourage custom regsub wrappers, and we use one pretty successfully. parameterized subs by section of the db are also easy to work with, and I imagine that even for the largest applications it wouldn’t be more than an afternoon of a mechanical refactor if they are already well organized to begin with

The official solution to this in a future, as yet unscheduled, re-frame release will be to use React context (https://reactjs.org/docs/context.html) to pass around a 'frame'; i.e. there will be a default 'frame' ala traditional re-frame then multi-frame support for n number of frames on the page.

In this way we will also solve re-usable 're-frame components'; i.e. bundles of subs/events/views with their own context that can be multi-instanced on a page.

You aren't missing something, that's how it's supposed to work. re-frame has a queue of events. The :dispatch effect handler just adds to the end of that queue.

I see that ‘`fx` allows for effects to be ordered’ [1]. So this order just refers to when the events are put into the queue, right? [1]: http://day8.github.io/re-frame/releases/2020/#110-2020-08-24

For my use case, should I use dispatch-sync for the first event then?

> So this order just refers to when the events are put into the queue, right? Yes. > For my use case, should I use dispatch-sync for the first event then? It won't solve anything. The request will still be async. Instead, don't use two :dispatch but rather wrap one :dispatch in another. Alternatively, use https://github.com/day8/re-frame-async-flow-fx or something like it. Be extra careful about handling failed requests and about issuing multiple requests - you don't want any bad states or race conditions.

Makes sense. Thanks!

Just out of curiosity, what’s the use case for fx? In other words, why would the order of events being put into the queue matter? (since you won’t control their order of execution anyway)

You are controlling their order of execution. You're controlling everything. In your particular case, :on-success or whatever is dispatched after the second event in :fx, that's it.

Events go into the queue. The queue is ordered. That's all there is to it.