Browser.element with navigation

[Bastes]

Hi ; transitioning to Elm in an older system, we've been using Elm 0.18 to implant incrementally element-style elm parts as pages that still get the benefits of the existing non-elm menus and layout.

We've also successfully used Navigation in some of those parts.

Now we're trying to migrate to 0.19 ; but there is no Browser.elementWithNavigation or such to make an element that's embedded into a non-elm page rather than replacing the whole page, so everywhere we transitioned to Browser.application has no layout.

Is there a library that implements an application-like function that would offer navigation for element-like embedded elm parts?

[carlfredrikhero]

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

[Bastes]

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.

[carlfredrikhero]

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.

[Bastes]

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.

[jinjor]

@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.

[Bastes]

@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.

[charukiewicz]

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.

[Bastes]

What he said: @charukiewicz ;p