-
Notifications
You must be signed in to change notification settings - Fork 43
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
Comments
This ignores the Url.path: |
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 |
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:
|
Oh yeah, I do the same thing: -- so that parsers run regardless of path:
normalizedUrl =
{ url | path = "" } |
…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.
…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.
…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.
Would be nice to have either I'd be happy to contribute it, if it's wanted. |
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 |
no anytime soon probably, use different package |
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"))
) |
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 setpath
to"/"
, but this feels a bit hackish.The text was updated successfully, but these errors were encountered: