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

Allow ignoring the path / Just parsing query parameters #17

Open
robinheghan opened this issue Oct 11, 2018 · 8 comments
Open

Allow ignoring the path / Just parsing query parameters #17

robinheghan opened this issue Oct 11, 2018 · 8 comments

Comments

@robinheghan
Copy link

We're running an Elm app as an embedded element, so we don't actually control the url where the elm app runs. We are interested in variables stored in query parameters though, and as far as I know there's no way to construct a parser which allows us to just parse queries.

Our current workaround is to alter the Url object and always set path to "/", but this feels a bit hackish.

@marmutro
Copy link

This ignores the Url.path:
Url.Parser.parse (Url.Parser.query queryParser) url

@Kurren123
Copy link

Kurren123 commented Jan 30, 2019

EDIT: @marmutro unfortunately this does not work in every case. See these examples:

import Url
import Url.Parser as Parser
import Url.Parser.Query as Query

queryParser =
    Query.int "CompID"

works =
    "http://www.google.com?CompID=123"
        |> Url.fromString
        |> Maybe.andThen (Parser.parse (Parser.query queryParser)) -- Just (Just 123)

doesNotWork =
    "http://www.google.com/test?CompID=123"
        |> Url.fromString
        |> Maybe.andThen (Parser.parse (Parser.query queryParser)) -- Nothing

Looks like I'm going to need to manually parse url.query myself.

@sashaafm
Copy link

I believe I ran into the same problem. I fixed this using a "trick" I saw on the official forum which is to first set the path to empty:

extractSearchArgument : String -> Url -> Maybe String
extractSearchArgument key location =
  { location | path = "" }
    |> Url.Parser.parse (Url.Parser.query (Url.Parser.Query.string key))
    |> Maybe.withDefault Nothing

@Erudition
Copy link

Erudition commented Jun 19, 2019

Oh yeah, I do the same thing:

 -- so that parsers run regardless of path:
normalizedUrl =
    { url | path = "" }

jerith666 added a commit to jerith666/elm-route-url that referenced this issue Jul 28, 2020
…cation

* adapt to the new Browser.application API in the following ways:

  * mirror the two-phase handling of URL changes in
    Browser.application's 'onUrlRequest' and 'onUrlChange' by
    bifurcating the RouterMsg variant of WrappedMsg into
    RouterMsgOnUrlChange and RouterMsgOnUrlRequestInternal variants.

  * add a slot to RouterModel to store the new Browser.Navigation.Key,
    and in the update function, use it to invoke
    Browser.Navigation.pushUrl in response to a urlRequestInternal.

  * create a new 'onExternalUrlRequest' function for the user to
    implement, since RouteUrl can handle internal requests for the
    user, but can't do anything sensible with external requests (as
    suggested by @basti1302).

  * eliminate the distinction between App and AppWithFlags, and all
    related duplication, as there is no variant of the new
    Browser.application that doesn't support flags.

* make UrlChange more strongly typed, mirroring the structure of the
  Url.Url record type from elm/url, and rework the way UrlChanges are
  converted to Cmds with a new 'apply : Url -> UrlChange -> Url'
  function.

* update all examples to work with the new API and 0.19 generally

  * include work-arounds for a couple of elm/url bugs
    (elm/url#37 and
    elm/url#17)

  * store the base path in ExampleViewer.Model to illustrate absolute
    path requirement of UrlChange

  * build the examples with '--debug' so users can get an idea for how
    they work under the hood

* update README

  * remove references to complementary packages that aren't compatible
    with 0.19 (which is all of them)

* remove the RouteUrl.Builder module and the use of the sporto/erl
  package, as this functionality is now largely provided by elm/url.

* remove the older RouteHash module, as it was only present to ease
  the transition from elm-route-hash to elm-route-url.  also remove
  example code illustrating its use.
jerith666 added a commit to jerith666/elm-route-url that referenced this issue Jul 28, 2020
…cation

* adapt to the new Browser.application API in the following ways:

  * mirror the two-phase handling of URL changes in
    Browser.application's 'onUrlRequest' and 'onUrlChange' by
    bifurcating the RouterMsg variant of WrappedMsg into
    RouterMsgOnUrlChange and RouterMsgOnUrlRequestInternal variants.

  * add a slot to RouterModel to store the new Browser.Navigation.Key,
    and in the update function, use it to invoke
    Browser.Navigation.pushUrl in response to a urlRequestInternal.

  * create a new 'onExternalUrlRequest' function for the user to
    implement, since RouteUrl can handle internal requests for the
    user, but can't do anything sensible with external requests (as
    suggested by @basti1302).

  * eliminate the distinction between App and AppWithFlags, and all
    related duplication, as there is no variant of the new
    Browser.application that doesn't support flags.

* make UrlChange more strongly typed, mirroring the structure of the
  Url.Url record type from elm/url, and rework the way UrlChanges are
  converted to Cmds with a new 'apply : Url -> UrlChange -> Url'
  function.

* update all examples to work with the new API and 0.19 generally

  * include work-arounds for a couple of elm/url bugs
    (elm/url#37 and
    elm/url#17)

  * store the base path in ExampleViewer.Model to illustrate absolute
    path requirement of UrlChange

  * build the examples with '--debug' so users can get an idea for how
    they work under the hood

* update README

  * remove references to complementary packages that aren't compatible
    with 0.19 (which is all of them)

* remove the RouteUrl.Builder module and the use of the sporto/erl
  package, as this functionality is now largely provided by elm/url.

* remove the older RouteHash module, as it was only present to ease
  the transition from elm-route-hash to elm-route-url.  also remove
  example code illustrating its use.
jerith666 added a commit to jerith666/elm-route-url that referenced this issue Jul 28, 2020
…cation

* adapt to the new Browser.application API in the following ways:

  * mirror the two-phase handling of URL changes in
    Browser.application's 'onUrlRequest' and 'onUrlChange' by
    bifurcating the RouterMsg variant of WrappedMsg into
    RouterMsgOnUrlChange and RouterMsgOnUrlRequestInternal variants.

  * add a slot to RouterModel to store the new Browser.Navigation.Key,
    and in the update function, use it to invoke
    Browser.Navigation.pushUrl in response to a urlRequestInternal.

  * create a new 'onExternalUrlRequest' function for the user to
    implement, since RouteUrl can handle internal requests for the
    user, but can't do anything sensible with external requests (as
    suggested by @basti1302).

  * eliminate the distinction between App and AppWithFlags, and all
    related duplication, as there is no variant of the new
    Browser.application that doesn't support flags.

* make UrlChange more strongly typed, mirroring the structure of the
  Url.Url record type from elm/url, and rework the way UrlChanges are
  converted to Cmds with a new 'apply : Url -> UrlChange -> Url'
  function.

* update all examples to work with the new API and 0.19 generally

  * include work-arounds for a couple of elm/url bugs
    (elm/url#37 and
    elm/url#17)

  * store the base path in ExampleViewer.Model to illustrate absolute
    path requirement of UrlChange

  * build the examples with '--debug' so users can get an idea for how
    they work under the hood

* update README

  * remove references to complementary packages that aren't compatible
    with 0.19 (which is all of them)

* remove the RouteUrl.Builder module and the use of the sporto/erl
  package, as this functionality is now largely provided by elm/url.

* remove the older RouteHash module, as it was only present to ease
  the transition from elm-route-hash to elm-route-url.  also remove
  example code illustrating its use.
@googleson78
Copy link

Would be nice to have either Url.Parser.query do this or have another function to do so available.

I'd be happy to contribute it, if it's wanted.

@kewaopcode
Copy link

Is it going to be fixed? This is the second time i face this issue having literally no idea what is going wrong, thats kinda sad

@pravdomil
Copy link

no anytime soon probably, use different package

@DHager
Copy link

DHager commented Aug 8, 2023

I'd like to report that I just ran into this in the wild, and it was very confusing and frustrating.

To offer a concrete example I was repl-testing with, in case it helps future searchers:

import Url
import Url.Parser
import Url.Parser.Query

"https://hostname.tld:1234/path1/path2?foo=alpha&bar=beta" |> 
Url.fromString |> 
Maybe.andThen (\urldata -> 
  {urldata| path = ""}  |>  -- OMG why is this secret sauce necessary?
  Url.Parser.parse (Url.Parser.query (Url.Parser.Query.string "foo")) 
)

ktosiek added a commit to ktosiek/url that referenced this issue Sep 23, 2023
Parsing just a query requires additional steps.

Current text suggests a parser created with `Parser.query` ignores the path, but it doesn't, and it trips people up: see elm#36 and elm#17.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants