Actual URL query params (?param=value) are mixed into hash route query params

[forthrightwit]

Let's say I have a Route set up for browse/:id

When navigating to this URL:

http://localhost:9000/?debug=false&noCache=false#browse/tv?renderStrategy=deferNextFrame

I get the following data coming back in the call to _onUrlParams(params):

{
  id: "tv",
  Symbol(queryParams): {
    debug: "false",
    noCache: "false",
    renderStrategy: "deferNextFrame"
  },
  Symbol(store): undefined
}

You can see the actual URL params debug and noCache are mixed in with the hash URL param renderStrategy. I think there should be a way to distinguish these two types of URL params. The actual ones are used to control aspects of the application globally, the hash ones target specifically the Page pointed to at that route.

If anything it would be great to have easier access (not using symbols) to such params. Why not mix the hash URL params in with the hash route params? Something like this, as a suggestion:

{
  urlParams: {
    debug: "false",
    noCache: "false",
  },
  routeParams: {
    id: "tv",
    renderStrategy: "deferNextFrame"
  }
}

[mauro1855]

Hi @forthrightwit, I recently found a situation like this in a Lightning app, and as far as I can tell, the URL format you presented (with queryParams, an hash and more query params afterwards) is against RFC-3986 spec. Specifically, all query params in a URL should come before the # and not after, read here: https://superuser.com/questions/498617/does-an-anchor-tag-come-before-the-query-string-or-after

I don't know what is the solution here (nor do I make those kind of decisions in Lightning), but I'm not sure the Lightning team should be developing a feature to support something non-standard.

[michielvandergeest]

Hi @forthrightwit, thanks for your patience on this issue.

We have looked at your request, and although we understand that it would make easier access, we unfortunately don't plan to implement this feature.

Also as @mauro1855 also pointed out, the URL format you proposed is invalid. And it's not intended behavior to add query params to a route segment itself.