Better handling / differentiating with external links #7

ricardojmendez opened this Issue Aug 27, 2015 · 6 comments


None yet

3 participants


Pushy right now is not differentiating between links internal to the application that could indicate an action that needs dispatching (say, /user/123) and external links pointing to a different site. (http://someothersite/userprofile/456).

In both cases, pushy would look at the path and try to handle it with the dispatch-fn, but since the function gets only the path and not the root, we can't differentiate ourselves.

Allow us to indicate which URLs pushy should handle. A straightforward option would be with a regular expression that the href gets matched against when deciding if the link should be bypassed. That would allow a user to filter out all links where, for example, the full URL isn't a relative path starting with /.

For anyone running into this issue, a workaround right now seems to be be adding the external links as targeting _blank.

pupeno commented Aug 27, 2015

I haven't experienced this issue because I'm just starting to build an app with pushy, but this would certainly be problematic for us as well. Possibly related, pushy only sending the path and not the full URI makes it hard to handle dispatching in multi-domain applications.


Yeah, I have actually ran into this problem too!

We could use regex (or even cemerick's url library) to only dispatch on relative path URLs

@pupeno: if pushy had an optional argument in its constructor that specified the host it dispatches on would that solve your problem? Or I guess you could simply use the host of window.location

pupeno commented Aug 28, 2015

@wavejumper I think the best would be an argument that makes pushy send the whole URL. I can think myself wanting to inspect the scheme for example (I can't think of how to use port number, but maybe someone else did).


Unfortunately it is difficult to pass the full URL to the dispatch function because of the way I am using goog.HTML5History for push state (eg when you mutate the history stack, the token transformer returns a relative path which is what gets passed to the dispatch function).

I have simply added an optional arg to the constructor :processable-url? which is a predicate function that gets passed an instance of goog.Uri.

By default pushy will dispatch on relative paths + absolute URLs that match the windows origin.

@wavejumper wavejumper closed this Aug 30, 2015

Pushed to clojars as 0.3.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment