kibu-australia / pushy Goto Github PK

Hi there!

It appears that reloading an application though figwheel doesn't quite re-initalize the pushy routing component. If I load the page, and change a route (triggering a figwheel reload, not a full page reload), it appears that the previous set of routes remain, despite a new pushy def.

It appears to dispatch on initial reload, but any further dispatching reverts to the old router.

It's probably a lack of knowledge, but it'd be nice to have an example if there's a hook in pushy that figwheel would need to reload properly. Do I have to cleanup anywhere? I'm using bidi as a router.

Consider the next link: http://localhost:3000/%5C, where %5C is URL encoding of backslash. When following such link it appears as http://localhost:3000// in browser's address bar.

It seems to happen because pushy uses goog.Uri for parsing URLs and, for some reason, .getPath returns decoded URLs (doc).

Also, the resulting URL contains the slash and not a backslash, because browsers seem to replace all backslashes with slashed by default.

This is for the authors (Thanks for the work, @wavejumper), but also anyone who comes upon here: this is obviously a useful (micro)library, but it looks like is no longer being maintained. Many tutorials for cljs/pushState still leads here, and the lack of IE11 support is especially annoying. Can any of the following happen?

1. Find new maintainers (need the authors' permission)
2. Are there any existing forks that's open to new development/PRs? Looking at the collox and hyperfiddle ones especially.
3. I'd be open to forking this and taking over maintenance failing the above two.

Figure out a way to test code.

Phantomjs seems to dislike goog.history.Html5History's setToken method.

Returns:

SECURITY_ERR: DOM Exception 18: An attempt was made to break through the security policy of the user agent.

It's common to use svg's in anchor tags with xlink'ing. Occassionally, a click will target the use tag, and since it has an href attribute, recur-href will stop there instead of iterating up to the anchor tag.

Shouldn't the recur-href function check whether the element is an anchor tag?

related: #15

Opening a link in a new tab is usually done with target="_blank", but currently the click event handler just ignores this property and handles it like any other click.

I think there should be a special condition added for this. What do you think?

I'm using pushy 0.3.0 with secretary 1.2.3 exactly as per the README. I'm able to navigate between routes just fine in my app, but the URL location bar doesn't update as one would expect with a pushState event. Is this a known issue?

I'm using Pushy with re-frame and I have a link that looks like this:

[:a {:on-click #(re-frame/dispatch [:mark-tool-as-used (:id tool)])} (:name tool)]

It's here: https://github.com/carouselapps/ninjatools/blob/master/src/cljs/ninjatools/views.cljs#L25

I'm expecting that link to just call the ClojureScript method, but it's also triggering Pushy to dispatch. I'm setting it here:

https://github.com/carouselapps/ninjatools/blob/master/src/cljs/ninjatools/routes.cljs#L27

The second dispatch is particularly problematic since the URL being processed is empty.

Unknown exception after upgrade from 0.2.2 to 0.3.0 during CLJS compilation. Using secretary 1.2.3

Compiling ClojureScript.
Compiling "target/prod/scripts/app.js" from ["src" "src-client"]...
Compiling "target/prod/scripts/app.js" failed.
clojure.lang.ExceptionInfo: failed compiling file:src-client/main/client.cljs {:file #<File src-    client/main/client.cljs>}
    at clojure.core$ex_info.invoke(core.clj:4403)
    at cljs.compiler$compile_file.invoke(compiler.clj:1040)
    at cljs.compiler$compile_root.invoke(compiler.clj:1070)
    at cljs.closure$compile_dir.invoke(closure.clj:353)
    at cljs.closure$eval3165$fn__3166.invoke(closure.clj:393)

Usage:

(ns main.client
(:require [reagent.core :as reagent :refer [atom]]
        [secretary.core :as secretary :refer-macros [defroute]]
        [pushy.core :as pushy :refer [push-state!]]
        [main.core :as core])
 (:import goog.History))

 (reagent/render-component [core/app-view] (.getElementById js/document "app"))

 (push-state! secretary/dispatch!

 (fn [x] (when (secretary/locate-route x) x)))

If I switch to back to "0.2.2" in project.cljs it comes fine. And everything works.

https://github.com/hzhu/reagent-nodejs
Any ideas?

It seems that in some browsers (IE10/IE11 is where I saw it), <img /> DOM elements have an href which represents the path portion of the src URI, e.g.:

<img id='test' src='http://somewhere.de/image.png' />

document.getElementById('test').href
// => '/image.png'

Now, when pushy checks for (.-href target) (and only afterwards recurses through target's parents), it might pick up the image tag instead of the anchor in the following example:

<a href='/valid.png'>
  <img src='/invalid.png' />
</a>

Note that, while href is present in both IE10's and IE11's image elements, I can only observe the problematic behaviour in IE10 (and even then only on some machines, so there might exist some patched versions - or another factor I haven't discovered yet).

But, generally speaking, would it make sense to you to exclude image tags when checking for href? I'd be happy to supply a PR if desired.

Have a nice day!
Yannick

Looks like pushy is using a function that isn't supported in IE. Might want to consider a polyfill or relying on .parentNode instead.

Happy to put together a pull request based on any input.

fragments after the # don't seem to be supported. Is there a reason for that?

i.e if an href contains "/#some/path" the match function will only be passed "/".

Triggering the event on right click makes it impossible to do the usual right-click actions (copy, inspect, etc). Either don't do this by default or make it an option.

See: #17

In some IE versions, location.origin (or window.location.origin to fully specify it) is undefined [1], resulting in this piece of pushy's code to generate the pattern #"^.*$" - which always matches.

If you're okay with it I'd open a PR implementing the workaround described in [1].

[1] http://tosbourn.com/a-fix-for-window-location-origin-in-internet-explorer/

I tried using set-token! to redirect to a different URL, but it's not triggering the parse url or the dispatch function. It's just replacing the URL. How do I cause the dispatch function to be triggered?

Related to #2, would it be possible to have an attribute in target that causes pushy to ignore the event? Semantically, target="_self" makes sense (and is used for e.g. Precursor).

My use case is that I have a long form with a ToC in a sidebar. I want the links in the ToC to link to parts of the page using the id hash (just standard html stuff), but pushy is intercepting the click and disables it (since it otherwise qualifies for a pushy event)

https://github.com/kibu-australia/pushy/blob/master/src/pushy/core.cljs#L118

Could be changed from:
(not (= "_blank" (.getAttribute el "target")))
to
(not (get #{"_blank" "_self"} (.getAttribute el "target")))

Thanks for Pushy by the way, it's really fantastic!

When writing forms that redirect to a route if successfull, I find out that I can't write valid/SEO compliant HTML by using classical anchor.

I need to dispatch route on the action/formaction attributes.
I no that pushy only filter a/href ; what do you think about opening it to action/formAction

• action on form element
• formaction on button

Thanks for your advices

"This adds an event listener to all click events, which dispatches on all matched routes. Bypasses on Alt, Shift, Meta, Ctrl keys and middle clicks."

What does this mean? Does a click event somehow generate a "route" that can be "matched"?

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.