Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Browser.element with navigation #43

Open
Bastes opened this Issue Oct 15, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@Bastes
Copy link

Bastes commented Oct 15, 2018

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

This comment has been minimized.

@Bastes

This comment has been minimized.

Copy link
Author

Bastes commented Oct 19, 2018

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

This comment has been minimized.

Copy link

carlfredrikhero commented Oct 24, 2018

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

This comment has been minimized.

Copy link
Author

Bastes commented Oct 25, 2018

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

This comment has been minimized.

Copy link

jinjor commented Nov 5, 2018

@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

This comment has been minimized.

Copy link
Author

Bastes commented Nov 5, 2018

@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

This comment has been minimized.

Copy link

charukiewicz commented Nov 12, 2018

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

This comment has been minimized.

Copy link
Author

Bastes commented Nov 12, 2018

What he said: @charukiewicz
;p

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.