Browser.element with navigation about browser HOT 8 OPEN

Experiencing the same issue. I understand the reasoning behind this, but certain things (like support for hash-based routing) did not make it into the new Url.Parser module. The old UrlParser module offered support for matching on the components of a URL fragment:

-- Elm 0.18
> import UrlParser exposing ((</>), s, int, string, parseHash)

> parseHash (s "blog" </> int) { ... , hash = "#blog/42" }
Just 42

> parseHash (s "blog" </> int) { ... , hash = "#/blog/13" }
Just 13

> parseHash (s "blog" </> int) { ... , hash = "#/blog/hello" }
Nothing

Applying the path parsers to the fragment field is no longer possible with the new API, so you have to write code that looks like this:

-- Extracting a blog post ID from a URL that looks like
-- http://example.com/social/#/blog/1

matchers : Parser (Route -> a) a
matchers =
    Parser.oneOf
        [ Parser.map Home Parser.top
        , Parser.map Blog (Parser.s "blog" </> Parser.int)
        ]

-- The Url coming from the Browser package
realUrl : Url
realUrl =
    { protocol = Http
    , host = "example.com"
    , port_ = Nothing
    , path = "/social/"
    , query = Nothing
    , fragment = Just "/blog/1"
    }

-- Overwrite the path with the fragment to be able
-- to apply our primitive and path parsers.
hasUrlToUrl : Url -> Url
hasUrlToUrl url =
    { url
        | path = url.fragment |> Maybe.withDefault ""
    }

result =
    Parser.parse matchers (hasUrlToUrl realUrl)

This seems like it goes against the spirit of Elm to have to overwrite your path string with your fragment string just to "trick" the parsing library into parsing it in a meaningful way.

from browser.

Please read https://github.com/elm/browser/blob/1.0.0/notes/navigation-in-elements.md

from browser.

@jinjor I might have not explained my points well ^^° what I meant was that you couldn't use the url parsers (</> and other url-parsing functions) to parse these partial urls without making fake Url objects extracting the fragment and filling in the other Url bits with junk data, which feels very hacky.

from browser.

Yes, that's how we're working around the problem ; it's still a workaround though.

Wouldn't it be a good idea to have something to give an element-like "page" control over the fragments for example? Something like that would make adopting elm less scary for a team that wants history management for the scope of their feature but can't build an SPA right away. As is, it's not very inviting.

from browser.

A few ways it's more scary:

• you loose all benefits of elm/url parsing and there is no easy drop-in replacement
• you have to tinker with the javascript browser navigation yourself, and the documentation explicitly tells you that you "would be sure to run into some annoying bugs and learn a bunch of techniques the hard way!" (https://package.elm-lang.org/packages/elm/browser/latest/Browser-Navigation#navigate-within-page) which is not very comforting
• you have to extract the fragment from the url and compare the base URL with the page's to know whether you should navigate away from the page or stay on it

So, I'm not saying that this solution does not work (in fact, that's what I did as a drop-in replacements in my codebase when I migrated), I'm just saying that it's not inviting, and the kind of wrinkle that can turn off newcomers in environments when building a root-owning SPAs is out of the questions.

from browser.

I don't see it as a workaround.

And why would it be more scary? If I didn't have the article's code perhaps it could be scary but right now I find it very clear what I need to do.

from browser.

@Bastes

you loose all benefits of elm/url parsing and there is no easy drop-in replacement

I think you can still use elm/url parsing. Url is just a type alias, so you can construct it yourself. There is also Url.fromString : String -> Maybe Url function. I did like this for my migration.

from browser.

What he said: @charukiewicz
;p

from browser.