-
Notifications
You must be signed in to change notification settings - Fork 26.2k
HttpParams.toString() modifies the immutable object #20430
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
Comments
I just came across this in Angular 4.4.6 as well. :( |
It seems this bug also affects:
Looking through: https://github.com/angular/angular/blob/5.0.2/packages/common/http/src/params.ts As a workaround, I create my own params class which contains a proxy HttpParams. But its really not ideal that an ''immutable'' object is modified.
|
Here's a reproduction in Angular 6: This makes HttpParams near unusable to me. I don't get how this doesn't affect almost everyone using Angular. |
@alxhub Can I get Is there some new-new HttpClient coming out that is the reason we're not fixing bugs in the current "new" one? |
Just hit this too. We were looping over an objects keys/values but inside the for loop were calling .has() it created duplicate entries. The solution / hack was to remove any .has or other operations inside the loop and use .set() only (note, weirdly .set() and .append() seem to do the same?) |
421 days since this bug was reported. If the angular team is never going to look at my pull request (which is 412 days old now) can you at least look at fixing the bug? I just ran into this case again on a table with pagination and sorting and after 3 clicks of a sort you get an absolutely ridiculous URI like this if you don't hack around the bug: |
Wow, spent an hour debugging this. How does this gets into production code considering this is common API and no fixes after more than a year? |
Previously, an instance of HttpParams would retain its list of mutations after they have been materialized as a result of a read operation. Not only does this unnecessarily hold onto memory, more importantly does it introduce a bug where branching of off a materialized instance would reconsider the set of mutations that had already been applied, resulting in repeated application of mutations. This commit fixes the bug by clearing the list of pending mutations after they have been materialized, such that they will not be considered once again for branched off instances. Fixes angular#20430
Same problem when using
My |
…9045) Previously, an instance of HttpParams would retain its list of mutations after they have been materialized as a result of a read operation. Not only does this unnecessarily hold onto memory, more importantly does it introduce a bug where branching of off a materialized instance would reconsider the set of mutations that had already been applied, resulting in repeated application of mutations. This commit fixes the bug by clearing the list of pending mutations after they have been materialized, such that they will not be considered once again for branched off instances. Fixes #20430 PR Close #29045
…gular#29045) Previously, an instance of HttpParams would retain its list of mutations after they have been materialized as a result of a read operation. Not only does this unnecessarily hold onto memory, more importantly does it introduce a bug where branching of off a materialized instance would reconsider the set of mutations that had already been applied, resulting in repeated application of mutations. This commit fixes the bug by clearing the list of pending mutations after they have been materialized, such that they will not be considered once again for branched off instances. Fixes angular#20430 PR Close angular#29045
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
I'm submitting a...
Current behavior
There's really 2 issues here:
toString()
modifies the HttpParams object.toString()
moves all the 'updates' to the 'map', it doesn't clear the 'updates' listThe combination of these both means that params get duplicated if you ever use
toString()
Expected behavior
toString()
shouldn't cause modifications to the HttpParams object at all. The documentation reads thatThis class is immutable - all mutation operations return a new instance.
which isn't true for this method. If there's some technical reason why this happens then:toString()
should clear the updates list when it generates the mapMinimal reproduction of the problem with instructions
http://plnkr.co/edit/pAWaOvymsJwUpnn51ft8?p=preview
What is the motivation / use case for changing the behavior?
I have a screen where I want to update the Params in the URL as you set search parameters so that if you share it with someone or bookmark the search results it will know all the parameters. The issue is that the set of params I want to save to the URL doesn't include all the params that are used in the service. So I create a
HttpParams
object and set the params that are in the URL, then I callthis.location.replaceState(this.baseUrl, params.toString());
, then I send the params off to a service that adds a few more parameters before being fed into athis.http.get<ISearchResult>()
call. Doing this means that the request that goes to the server now has duplicates of all the parameters added to start.Environment
The text was updated successfully, but these errors were encountered: