Respect GET params#987
Conversation
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here (e.g. What to do if you already signed the CLAIndividual signers
Corporate signers
|
Toxicable
left a comment
There was a problem hiding this comment.
Can you do the following:
- Undo the formatting changes. It's hard to identify what you've changed when you've reformatted the whole file.
- Squash commits.
- Sign the CLA
- Make the commit something similar to:
feat(@nguniversal/common): allow cache to work with url params
|
Sry do not have time for it. What I done -
|
| let key = `${req.method[0]}_${req.url}`; | ||
|
|
||
| key = key | ||
| .replace(/[^\w\s]/gi, '_'); |
There was a problem hiding this comment.
Can you explain what this is doing?
A comment should suffice here
There was a problem hiding this comment.
this just beutify key. Because url can be with slashes so it replaces all not letter characters with '_'.
| return key; | ||
| } | ||
|
|
||
| private hashParams(body: any) { |
There was a problem hiding this comment.
What is this hashing method?
Is it some well known method?
Why not use something off the shelf?
There was a problem hiding this comment.
It is taken from stackowerlof. I thought why to take another dependency for such simple hashing functionality.
There was a problem hiding this comment.
Can you add a comment to credit the author and source
There was a problem hiding this comment.
There was a problem hiding this comment.
Can you add that as a comment in your src code
|
@vytautas-pranskunas- If you cant resolve the above comments then we cannot accept this PR. If that's ok with you then I'll implement the changes when I next get a chance |
| return { key: req.params.get(key) }; | ||
| }); | ||
|
|
||
| key += this.hashSeparator + this.hashParams(hashedParams); |
There was a problem hiding this comment.
Doing it this way means if someone has the params in a different order it'll casue a new request.
EG
foo=2&bar=3 produces key of 25
bar=3&foo=2 produces key of 52
When since their content is the same they should produce the same key
There was a problem hiding this comment.
you are right. But usually queries are fixed ant their order not changing. But ofcourse if you want - you can sort arasm before applying hashing.
There was a problem hiding this comment.
FWIW, param order should not matter. A reliable, case-sensitive (!) sort by key seems reasonable.
There was a problem hiding this comment.
So you want to say that in one query it can be user=..&User=... and in another visa versa? Sounds like a smell...
There was a problem hiding this comment.
The keys should be case senstive.
Meaning that the keys user and User are not equal.
There was a problem hiding this comment.
I have added comment about sorting you asked
There was a problem hiding this comment.
Sorry I didn't mean to make a comment about this, it needs to be applied aswell.
Merging this without the sorting will be broken.
|
Closed in favour of #1005 |
|
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?
Cache is not respecting GET params
What is the new behavior?
Cache is respecting GET params
Does this PR introduce a breaking change?
Other information
No matter that my API is pure JSON and i am not using GET I fixed bug that GET requests where not cached by params. Just one smal remark - for the same reason that I am not using GET i was not able to test. I tested with POST so GET should work similar. Please test befor merge.