Does pushy not work with # fragment urls?

[afhammad]

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 "/".

[gfrivolt]

I miss the part behind the hash too. What's the reason it's not taken into account?

[thomasmulvaney]

Hash URLs are used as a way of faking a page change. Now days with modern browsers supporting HTML5 push state this hack is no longer required. Pushy wraps up this newer API into a familiar ClojureScript library. There is currently no plan to support this older approach of history accounting in Pushy.

[ieure]

How do you suggest single-page apps handle navigation? If the whole thing is served from a single app.html file, lack of fragment support means URLs can't be shared — they'd refer to a path which doesn't exist.

I think that fixing this would require making the webserver return the same payload for any request, which limits the deployability — I can't just plop the file on S3 (or another dumb HTTP object store) and have it work. If you need special support on the backend, this defeats the purpose of writing a SPA, at least for me.

[thomasmulvaney]

@ieure We will think about supporting this. For the apps we have written, we have not needed this kind of hash bang routing. The point you make about dumb servers is one we never considered. We will look into implementing this. Naturally, a PR would be very welcome 😄

[ieure]

Thanks, I'll see if I can put something together.

[dustingetz]

Url fragments are used for more things than hacks, for example table of contents links:

<a href="#my-heading">navigate to Heading</a>
<a name="my-heading">Heading</a>

[dustingetz]

I fixed it by using the Modnakasta fork to process url fragments, providing a custom :processable-url? predicate to ignore urls with fragments (thus not calling preventDefault), and also passing an :identify-fn to drop tokens with fragments (thus not dispatching on navigate). I had to make pushy.core/processable-url? not private so i could call it from userland.

(pushy/pushy
  (fn [page-path] ...)
  identity
  :processable-url? #(and (pushy.core/processable-url? %)
                          (not (.hasFragment %)))
  :identity-fn #(if-not (string/includes? % "#") %))

[Ionshard]

I would absolutely love to see this feature as it's causing me some issues. Shouldn't be too hard considering there are two PRs out that solve this issue already. PR #25 and PR #26.

Thank you!

[jwr]

Ok, that might explain why links (with anchors) to specific parts of my user's guide were not working. As @dustingetz wrote, hash fragments are useful in a number of scenarios, not just for faking page changes. In my case, I have a number of server-side rendered pages which are then used ("hydrated") with React-based client-side JavaScript.

[dijonkitchen]

Any update on this or all those PRs (#21, #24, #25)?