We don't have an "offline first" approach to our webapp. It's essentially a nice interface to a REST API. Refreshing the browser bootstraps the app which fetches any data it needs. Our data model is complicated. This approach would generate a lot of requests except that we've provided a "pull api" mode which amounts to a poor-mans GraphQL. Goal is saving query count (at the cost of complicating bakend db queries)
Good summary of the problem… and interesting ideas. The project at hand being a hobby I'm under no pressure to make this work; just found it to be a good occasion to take a first stab at SSR. As I've said: I've already gotten this to work:
1. Endpoint receives a request containing app state (as b64 query-param)
2. Set Re-frame to that state (via multiple dispatches)
3. Render SVG-component via
4. Convert SVG to PNG and save to disk
5. Redirect to the static PNG (with 302) – works with crawlers.
Steps 2–4 are skipped if an image for that particular state already exists.
My only remaining worry is about concurret requests: What if another request comes in during 2. Could the DB-Atom be reset by handler B dipatching against it while handler A is still building the state it wants to render. Whith a global DB atom I smell trouble, but this is hard to test – maybe there would be no issue. With my current project there wouldn't be, since I get a couple of hunded reuqests per day at best – but in principle?
If I ran this on an actual server rather than a shared hosting limited to a single node runtime I could just add another node build, that starts no server at all but only takes the encoded state and spits the PNG to disk. The handlers would then just shell out, run that node script and then redirect to the resulting PNG. This would separate the Re-frame instances – but, again, I'd like to find something more elegant, even if it's less brutal than firing up Puppeteer all the time.
I'm trying to call
document.querySelector("#my-id").scrollIntoView() for a url that goes to a different view (from
/my-other-view#my-id) by dispatching two effects (`[:navigate-to "my-other-view"]` followed by
Unfortunately this doesn't work because the
:scroll-to event is fired before the corresponding element exists (both events seem to fire as a batch, before the view is rendered).
Is there a way to ensure that the
:scroll-to effect doesn't get applied until after the view has been re-rendered?
Re-frame acts on a queue - no handlers are run in threads. So no handlers can run in parallel. However, workflows can run concurrently if they consist of multiple events - when handling an event results in dispatching another event via some means.
Yes. By not using the effect and instead calling
scrollIntoView inside the component itself.
I would 100% not use re-frame machinery for this particular task.
Yeah I think that's what I'll end up having to do
And, of course, before calling the scroll function you would have to check that the URL fragment points to the relevant view.
I had this solution in place for moving around an already loaded page (where it works fine), and was hoping for a quick fix so I wouldn't have to redesign it right away
I've been in your shoes before, and I don't think there's a proper fix here. There's a dirty workaround - just firing up
setInterval and checking if the element exists.
Yeah okay, thanks 🙂
I have a question on http-fx. So here: https://github.com/day8/re-frame-http-fx#step-3a-handling-on-success I have to write a global callback for each http call? Seems quite clumsy?
You're using that fx in an event handler that's also available globally. Same thing.
This comes clumsy when
So we have to write lots of call backs here for a specific purpose.
(defn some-func  (call-http-1) (use-the above-http-result) (call-http-2 with the above transformed result))
Zero clue what you mean with that code, to be honest.
(defn some-func  (-> (call-http-1) (use-the-above-http-result) (call-http-2 with the above transformed result)))
Maybe more direct. So if I want to make several http requests with the later depending on the further. It is a little bit verbose to go with the (dispath [:response-handler]) approach.
Events in re-frame are in general indeed a bit more verbose when you need to chain then. That's a given, regardless of whether you're using re-frame-http-fx or not. There are libraries that try to alleviate that, like https://github.com/ingesolvoll/re-chain for example.
Thanks. It’s a quite niche package. How do you get to know that?
You mean, how I found that library? No clue. I just hoard and catalog all links that I see that seem to be useful. So probably someone mentioned it here before.
Also, the same guy is behind kee-frame, which I use - so maybe that's how I know about it.
@zackteo, we have found that a functional reactive approach can be very effective when dealing with mutable JS view objects like a Leaflet object: 1. Model all aspects of your Leaflet map as immutable data in your db. If you want to have multiple maps on the page, your db model has to support multiple model instances. 2. Bind your Leaflet object to the relevant dom node when the view component is created 3. Produce a subscription to your map's immutable data 4. Create a reagent reaction that updates the JS Leaflet object with the immutable data as input. There are two important restrictions: 1) your immutable data is your only input to the reaction 2) the only side-effects of the reaction are changes to your mutable JS object. Your Leaflet object effectively becomes a materialized view of your app db. The only way to make changes to your mutable Leaflet object is by transforming the immutable data in the app db. Reagent/re-frame will take care of keeping your mutable JS in sync with your app db.
alas, re-frame-10x doesn't work in a sandboxed iframe, which is part of my (admittedly unusual) app architecture.1
is there any hope of making that a soft requirement, maybe with degraded functionality? or is it vital to how 10x works?