Fork me on GitHub
#re-frame
<
2015-11-24
>
gabe14:11:09

@sreenath.n: (set! (.-hash js/window.location) (str “#/profile/“ github-id))

gabe14:11:05

dispatch! just triggers a secretary route. it doesn’t change the url

gabe14:11:37

Then you need to listen for the url change and call dispatch! at that point

gabe14:11:21

but this conversation should be moved to another channel. it has nothing to do w/ re-frame. perhaps #C03S1L9DN

jstew21:11:29

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.

jstew21:11:10

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.

roberto21:11:39

I have my own dispatch function, that calls secretary’s dispatch and also sets the js/window.location

jstew21:11:29

I'm using secretary also. That makes sense, thanks.

gabe21:11:26

@jstew: I have a navigation namespace w/ navigate! and go-back! functions. The first sets js/window.location, and the second calls history.back.

gabe21:11:35

I call secretary/dispatch! in a navigate event listener w/ the hash component of the url.

richiardiandrea22:11:24

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?

danielcompton23:11:35

@richiardiandrea: lots of implicit variables in that statement simple_smile 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

richiardiandrea23:11:22

Ah yes, it can be, running on Chrome, but I am double checking so you might be right ;)

richiardiandrea23:11:20

It is re-rendering around 50 re-com buttons by the way.. Be back soon

danielcompton23:11:22

Chrome is the good one usually

mikethompson23:11:15

@richiardiandrea: there's virtually no overhead to dispatch (we stopped using core.async in v0.5.0 which took out a 4ms lag).

mikethompson23:11:27

Your issues are elsewhere

mikethompson23:11:47

That way you'll see which part of the process is taking the time.

mikethompson23:11:05

Event handlers? Subscriptions? Views?

mikethompson23:11:45

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 simple_smile

richiardiandrea23:11:09

Ok right will do it, it is weird indeed

richiardiandrea23:11:37

But it is on my side 95% sure ;)

richiardiandrea23:11:30

It's just that colleagues smiled at me and it got me frustrated lol