Clojurians Log v2

Hey all, I've been trying to use https://github.com/adazzle/react-data-grid with re-frame/figwheel and finding it quite difficult... any pointers to how I can do this?

seems it's not as straight forward as I thought to use react libraries with figwheel. I have tried several things but I'm never able to require the library

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!

Hi, I have a moderately complex re-frame application for doing visual query building[1]. I wanted to make a version of it that could be embedded in a tutorial page for live examples. The problem is that this means I want multiple instances of my complex machinery, each with its own database. Unfortunately re-frame’s global state machinery makes this hard. Here are some possibilities: ◦ Add an extra context parameter to every subscription, event, and database access. This seems like a lot of work and is inelegant. ◦ Use iframes. Simplest, but also inelegant and requires loading the common parts multiple times ◦ Add some hacks on top of re-frame to keep track of the context (eg, functions of my own that wrap the rf functions). I made some stabs at this but didn’t succeed; the flow of control in re-frame eluded my attempts to add stuff on top of it. Anybody have any suggestions? Seems like something like this should not be this hard. [1] http://hyperphor.com/papers/enflame-clojure-meetup.pdf

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

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

Hi folks. When a page is loaded, my app check if there’s any query params. If there are, then it must execute a series of sync dispatches. I’m trying to achieve this with an event that uses :fx for dispatching two events. However, I’m pretty sure it’s not working as intended. I see that the second event in fx is dispatched before the chain of events dispatched by the first one finishes. Am I missing something? (consider that the first event uses :http-xhrio and the success condition makes another request. Not sure if this influences how fx works).

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.

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.