This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-15
Channels
- # babashka (41)
- # beginners (47)
- # calva (7)
- # cider (5)
- # cljsrn (2)
- # clojure (38)
- # clojure-europe (74)
- # clojure-nl (2)
- # clojure-spec (1)
- # clojure-uk (38)
- # clojurescript (42)
- # component (30)
- # core-async (2)
- # cryogen (6)
- # cursive (47)
- # datahike (7)
- # datomic (18)
- # defnpodcast (1)
- # fulcro (17)
- # graalvm (8)
- # graphql (4)
- # helix (5)
- # honeysql (5)
- # introduce-yourself (1)
- # jobs (5)
- # jobs-discuss (4)
- # malli (20)
- # meander (4)
- # mental-health (1)
- # off-topic (41)
- # pathom (18)
- # podcasts-discuss (2)
- # re-frame (20)
- # react (1)
- # reagent (22)
- # reitit (2)
- # releases (2)
- # remote-jobs (1)
- # reveal (2)
- # sci (10)
- # shadow-cljs (42)
- # sql (20)
- # tools-deps (7)
- # vim (2)
- # xtdb (51)
I'm trying to call document.querySelector("#my-id").scrollIntoView()
for a url that goes to a different view (from /my-view
to /my-other-view#my-id
) by dispatching two effects (`[:navigate-to "my-other-view"]` followed by [:scroll-to "my-id"]
).
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?
Yes. By not using the effect and instead calling scrollIntoView
inside the component itself.
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?
This comes clumsy when
(defn some-func []
(call-http-1)
(use-the above-http-result)
(call-http-2 with the above transformed result))
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)))
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.
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.
alas, re-frame-10x doesn't work in a sandboxed iframe, which is part of my (admittedly unusual) app architecture.
is there any hope of making that a soft requirement, maybe with degraded functionality? or is it vital to how 10x works?