During the porting of Raptor.UI (the front-end Angular application of our framework), we have used the new Angular HttpClient (as discussed here), with,apparently, any breaking change.
If we examine in depth, we have converted the UrlSearchParams of @angular/http module with the HttpParams of @angular/common/http. The code was as follows:
const params = new UrlSearchParams();
params.set('Direction', parameters.Direction === 'desc' ? '0' : '1');
params.set('ElementCount', parameters.ElementCount);
params.set('FieldsExcludedFromTheSearch', parameters.FieldsExcludedFromTheSearch);
params.set('Language', language);
params.set('OrderBy', parameters.OrderBy);
params.set('PageNumber', parameters.PageNumber);
params.set('PageSize', parameters.PageSize);
params.set('Pages', parameters.Pages);
params.set('SearchText', parameters.SearchText);
params.set('RelatedId', parameters.RelatedId);
We have converted the code as follows, with no compilation errors:
const params = new HttpParams();
params.set('Direction', parameters.Direction === 'desc' ? '0' : '1');
params.set('ElementCount', parameters.ElementCount);
params.set('FieldsExcludedFromTheSearch', parameters.FieldsExcludedFromTheSearch);
params.set('Language', language) params.set('OrderBy', parameters.OrderBy);
params.set('PageNumber', parameters.PageNumber);
params.set('PageSize', parameters.PageSize);
params.set('Pages', parameters.Pages);
params.set('SearchText', parameters.SearchText);
params.set('RelatedId', parameters.RelatedId);
But this new code doesn’t work, because HttpParams is immutable, so the set method creates and returns a new instance of the params. The correct code is as follows:
const params = new HttpParams()
.set('Direction', parameters.Direction === 'desc' ? '0' : '1')
.set('ElementCount', parameters.ElementCount)
.set('FieldsExcludedFromTheSearch', parameters.FieldsExcludedFromTheSearch)
.set('Language', language) .set('OrderBy', parameters.OrderBy)
.set('PageNumber', parameters.PageNumber)
.set('PageSize', parameters.PageSize)
.set('Pages', parameters.Pages)
.set('SearchText', parameters.SearchText)
.set('RelatedId', parameters.RelatedId);
Ok, it works fine, but I’ve created 11 HttpParams instead of one. The problem can be solved basically as follows:
const direction: string = parameters.Direction === 'desc' ? '0' : '1';
const params = {
Direction: [direction],
ElementCount: [parameters.ElementCount],
FieldsExcludedFromTheSearch: [parameters.FieldsExcludedFromTheSearch],
Language: [ language ],
OrderBy: [ parameters.OrderBy ],
PageNumber: [ parameters.PageNumber],
PageSize: [ parameters.PageSize],
Pages: [ parameters.Pages ],
SearchText: [ parameters.SearchText ],
RelatedId: [ parameters.RelatedId ]
}
But the question remains: why? Why my objects should be immutable? And I think that this question is broader than the Angular HttpClient parameters .I discussed this matter with some friends, that are hobbyist functional programmers, but we have to move the discussion in the (programmer) philosophy world. In the functional programming, the object immutability is a need, because the mutability of the state of an object can cause side effects in the async world: you should lock the resource to prevent that another thread changes the state in the middle of your change. But if objects are immutable, every change to them would create new objects. Obviously, this mechanism creates problems in terms of memory allocated, and there are also some techniques to limit the resource requested: then the problem remains.
The official Angular documentation talks about the choice of the immutability in the interceptors topic, you can read something here: https://angular.io/guide/http#immutability It makes sense, but in our example there isn’t any problem of concurrency, so the use of immutable object creates only an unuseful memory waste.
Happy coding!
