This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-24
Channels
- # admin-announcements (25)
- # beginners (132)
- # boot (89)
- # cider (26)
- # clara (12)
- # cljs-dev (10)
- # cljsrn (11)
- # clojure (151)
- # clojure-germany (8)
- # clojure-russia (1)
- # clojurescript (137)
- # cursive (33)
- # datavis (28)
- # datomic (3)
- # devcards (8)
- # hoplon (5)
- # immutant (11)
- # jobs (4)
- # ldnclj (58)
- # lein-figwheel (7)
- # off-topic (95)
- # om (114)
- # onyx (91)
- # parinfer (38)
- # portland-or (1)
- # re-frame (26)
- # reagent (1)
@sreenath.n: (set! (.-hash js/window.location) (str “#/profile/“ github-id))
but this conversation should be moved to another channel. it has nothing to do w/ re-frame. perhaps #C03S1L9DN
Thanks @gabe :)
If I have to set the window location hash after some event, where would I put that? handlers seems like a bad place, since we're just updating the app-db
there.
more specifically, I'm loading in data via an xhr request, and I have a callback to process that data. Depending on what type of data comes back from my API, I need to update the location hash so that the user can bookmark what the app state is at that point.
I have my own dispatch function, that calls secretary’s dispatch
and also sets the js/window.location
@jstew: I have a navigation namespace w/ navigate!
and go-back!
functions. The first sets js/window.location, and the second calls history.back
.
I call secretary/dispatch!
in a navigate event listener w/ the hash component of the url.
Today I tried to use re-frame to change the columns of a h-box dynamically through enquire and media query...it was slow...even with dispatch-sync..is there something I can do to cut the dispatch time?
@richiardiandrea: lots of implicit variables in that statement Which browser were you running it on? re-frame itself has a very low overhead so if it’s slow it’s probably because you’re doing a lot of work or doing something inefficiently. Some browsers also have perf issues with flexbox so it could be that
Ah yes, it can be, running on Chrome, but I am double checking so you might be right ;)
It is re-rendering around 50 re-com buttons by the way.. Be back soon
Chrome is the good one usually
@richiardiandrea: there's virtually no overhead to dispatch
(we stopped using core.async in v0.5.0 which took out a 4ms lag).
Your issues are elsewhere
Use something like this approach: https://github.com/Day8/re-frame/wiki/Debugging
That way you'll see which part of the process is taking the time.
Event handlers? Subscriptions? Views?
I'm suggesting this because you appear to making all sorts of false assumptions .... you need some facts. That debugging technique will give you good information
Ok right will do it, it is weird indeed
But it is on my side 95% sure ;)
It's just that colleagues smiled at me and it got me frustrated lol