Since the return value of location.search() is an object, I think care should be taken not to allow modifying the returned object.
(Not sure what the best approach would be though.)

Shouldn't RouteParams also do the replace(/\+/g,'%20') + decodeURIComponent magic?

@flyingmutant Seems like it should. Hopefully a core team member can comment on that.
It is likely that the tryDecodeURIComponent utility function I added might be repurposed in the facade where other utility methods are and could be used forRouteParams as well. I can refactor that once I receive more direction.

@gkalpak I agree with you on making the returned Object immutable. I'll look into this.

@NathanWalker Your error means that there is no decodeURIComponent function in Dart. This is a case where Dart API is different then JS API. The way to solve it is that you have to create a decode.js and decode.dart where you create a function called decodeURIComponent and export it.

In JS case you simply rexport the function as is. In dart case you have to call https://api.dartlang.org/1.12.2/dart-core/Uri/decodeComponent.html

Thanks @mhevery , that's exactly what I needed to know. I updated the PR, squashed the commits and believe I have it solved now.

Not totally sure how I feel about this– I don't want applications injecting and and using search params. They should use RouteParams instead.

But the work on encoding/decoding params is much needed. Either way, this is some solid work, @NathanWalker. Please give me a bit to think about how best to proceed.

@mhevery – please check with me next time before marking tasks as community help so that we can be sure that the design is right. It's frustrating for developers to put a bunch of work into something that isn't conceptually quite right.

@btford I'm ok with using RouteParams if they will contain all search query params. However, in Angular 1.x using $routeParams did not work that way. It only included keys that came from the route configuration like :id, etc.. and did not have anything else like other random params in the query.

If RouteParams still behaves that way in Angular 2, then we would still want location.search() here like we all had in 1.x. This way if a component or app is not using routing at all, it could still easily access the params on the url.

Yep, Angular 2 has a different model. Component all the things!

On Tue, Oct 27, 2015 at 9:12 AM Nathan Walker [email protected]
wrote:

@btford https://github.com/btford I'm ok with using RouteParams if they
will contain all search query params. However, in Angular 1.x using
$routeParams did not work that way. It only included keys that came
from the route configuration like :id, etc.. and did not have anything
else like other random params in the query.

If RouteParams still behaves that way in Angular 2, then we would still
want location.search() here like we all had in 1.x.

—
Reply to this email directly or view it on GitHub
#4905 (comment).

If we can inject RouteParams without including the router package then we
would be good to go. But if RouteParams is only available by including the
router package in an end users application then we would still need this.

Basically we need an easy way to grab all query params at any time whether
the app is using the router or not is the thing.

On Tue, Oct 27, 2015 at 2:18 AM Brian Ford [email protected] wrote:

Yep, Angular 2 has a different model. Component all the things!

On Tue, Oct 27, 2015 at 9:12 AM Nathan Walker [email protected]
wrote:

@btford https://github.com/btford I'm ok with using RouteParams if
they
will contain all search query params. However, in Angular 1.x using
$routeParams did not work that way. It only included keys that came
from the route configuration like :id, etc.. and did not have anything
else like other random params in the query.

If RouteParams still behaves that way in Angular 2, then we would still
want location.search() here like we all had in 1.x.

—
Reply to this email directly or view it on GitHub
#4905 (comment).

—
Reply to this email directly or view it on GitHub
#4905 (comment).

Right now Location is only available in angular2/router. I think it's reasonable to break it out into its own package later so you can use it without the router. But that's a separate concern. It's worth opening a separate issue about it, but there are many higher priority items so it's not likely that I'll have a change to take a look at that any time soon.

But yes, I do want to eventually support use of Location without the router.

Do RouteParams really include the query params ? That would be...unintuitive.
In any case, getting access to the query params should be independent of the ngComponentRouter imo.

Unless there is some reason (I am missing right now), that ng2 apps should not rely on/access the URL's query params. (If that's the case, prepare yourself for looots of complaining 😃)

Hi. I looked in the source code and it seems that the search() function is not equivalent to what we had in Angular1. Is there any plan to also support setter for query params?
It's actually very useful when dealing with search/filter parameters where we don't want to reload the page but we still want to be able to copy/past the url with the page state :)

@tagazok Thank you for pointing that out! I'll see about making the changes to this PR to support that.

@btford I wanted to check in with you on this. I am planning to finish this up over the next week regarding @tagazok's comment. If you have any additional comments (or know of any current blockers), please let me know.

@btford Is this something you can finish, or would you like me to take this over?

@mhevery I was digging into this today making progress with the changes but when I tried to run gulp build and gulp build.js and begin some testing, I ran into this:

[12:27:49] Starting '!bundle.js.min'...

<--- Last few GCs --->

  118341 ms: Mark-sweep 1375.9 (1457.2) -> 1380.0 (1457.2) MB, 1294.5 / 0 ms [allocation failure] [GC in old space requested].
  119684 ms: Mark-sweep 1380.0 (1457.2) -> 1380.0 (1457.2) MB, 1342.5 / 0 ms [allocation failure] [GC in old space requested].
  121040 ms: Mark-sweep 1380.0 (1457.2) -> 1375.0 (1457.2) MB, 1356.7 / 0 ms [last resort gc].
  122360 ms: Mark-sweep 1375.0 (1457.2) -> 1375.9 (1457.2) MB, 1319.4 / 0 ms [last resort gc].


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x28fcd09e3ac1 <JS Object>
    2: walkExpressionStatement [/Users/nathan/Documents/github/angular2-stuff/angular/node_modules/webpack/lib/Parser.js:~359] [pc=0x34cb71fb21f0] (this=0x29abbdb4cc31 <a Parser with map 0x225cbae57b39>,statement=0x376226578579 <a Node with map 0x3412f6f158d1>)
    3: walkStatement [/Users/nathan/Documents/github/angular2-stuff/angular/node_modules/webpack/lib/Parser.js:351] [pc=0x34cb71b9561b]...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
Abort trap: 6

I have had trouble historically with this project build unfortunately. This is after removing node_modules and running npm install from a clean slate.

If you know a quick fix for the above would be appreciated. At moment I'm stuck unable to proceed on this feature.

My system specs are more than adequate I would think:
3.1 GHz Intel Core i7
16 GB 1867 MHz DDR3
Intel Iris Graphics 1536
300 GB available

Just went searching and found this:
#5229
Will try the workaround.

Curious if anyone could comment on this issue: #4943
If that sounds reasonable, I'm thinking tackling the refactor first before finishing this would be great since it would affect this PR. I would likely implement the changes here from scratch in a new PR with the refactor in place.

This is obsolete by the new router work. :-(

This PR is stale (does not rebase; pass CI; had no activity for a while). It is probably our fault, and we are sorry. In an effort to keep our PR queue under control, and prevent us from taking too long to get back to you we are cleaning up the queue. Unfortunately this means that this PR is getting closed.

If you would like to resurrect this change, please rebase on master, make the tests pass and create a new PR.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}