fix(common): allow number or boolean as http params#40663
fix(common): allow number or boolean as http params#40663cexbrayat wants to merge 1 commit intoangular:masterfrom
Conversation
petebacondarwin
left a comment
There was a problem hiding this comment.
Generally looks good to me.
I think we might want to add to the tests. Should we consider cases where a param is set via one type (e.g. number) but then mutated/deleted via another type (e.g. string)?
Reviewed-for: public-api
0d440da to
2569e75
Compare
|
After discussion, we settled to use |
2569e75 to
f9f391b
Compare
petebacondarwin
left a comment
There was a problem hiding this comment.
A couple of final NITs.
|
@petebacondarwin Done! |
f9f391b to
3974a1c
Compare
jessicajaniuk
left a comment
There was a problem hiding this comment.
LGTM 🍪
I like how thorough these tests are. Thanks for adding them.
Requested changes were resolved.
|
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. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Currently, the HTTP client expects string values for parameters, forcing us to cast numbers or boolean.
For example, if
pageis a number, we have to do something like:Issue Number: #23856 (but does not address the Date part of the issue)
What is the new behavior?
Allows to use number and boolean directly as HTTP params, instead of having to convert it to string first.
HttpParamshas also been updated to have most of its methods accept number or boolean values.Does this PR introduce a breaking change?
Other information