Ignore the real query parameters when using hash, expect #whatever?key=value instead

[SergKam]

parseHash parses query params from the main URL not from the hash part
For example this common use-case http://example.com/app/#items?filter=cats
It cannot be implemented using this module.

In my case parseLocation always returns Nothing if the hash query used.

urlToRoute : Parser (Route -> a) a
urlToRoute =
    oneOf
        [ map MainRoute top
        , map ItemListRoute (s "items" <?> stringParam "filter")
        , map ItemRoute (s "items" </> string)
        , map AboutRoute (s "about")
        ]

parseLocation : Location -> Route
parseLocation location =
    parseHash urlToRoute  location

I expect the function with the name "parseHash" parses hash only, but instead, it parses the "location.search" as I can see here
https://github.com/evancz/url-parser/blob/master/src/UrlParser.elm#L353

The workaround I use is this (not very elegant, sorry)

fixLocationQuery : Location -> Location
fixLocationQuery location =
    let
        hash =
            String.split "?" location.hash
                |> List.head
                |> Maybe.withDefault ""

        search =
            String.split "?" location.hash
                |> List.drop 1
                |> String.join "?"
                |> String.append "?"
    in
        { location | hash = hash, search = search }

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[amilner42]

Thanks @SergKam, ran into the same thing.

Could we possibly update the documentation?

[j-panasiuk]

I just ran into the same problem. Thanks @SergKam for quick workaround!

[mauropalsgraaf]

You're a life saver, thanks @SergKam !

[andys8]

I ran into the same problem. Rewriting the code using path params because of this issue.

[kspeakman]

Just spent a couple hours trying to figure out why query parameter parsing always returned Nothing before finding this. I use similar URLs: https://domain/app/#/courses?q=asdf

[kexoth]

I've lost my whole day tinkering this issue & never thought it might be that the browser processes hash & search in this manner.

This is my function for normalizing the Navigation.Location, it will give you the correct and same location with both cases #hello?q=world & ?q=world#hello:

    fixLocation : Navigation.Location -> Navigation.Location
    fixLocation location =
        case String.split "?" location.hash of
            [ hash, search ] ->
                { location
                    | search = ("?" ++ search)
                    , hash = hash
                } 
        
            _ ->
                location

This actually in my opinion messes a lot with people diving into making SPA/PWA's in Elm.
Since libraries such as elm-lang/navigation actually favor the approach of hashed routing, this behaviour should be either overriden or documented, here or in elm-lang/navigation, since developers consistently face this issue here & in elm-lang/navigation#33 .

[3v0k4]

@SergKam thanks a lot, this was making me crazy

[cmditch]

Also took several hours for me to figure out this was the problem, glad this issue was here...

[andys8]

I think this repository is replaced with https://github.com/elm/url. The issues have to be tested, and new issues have to be created if they're still existing.