-
-
Notifications
You must be signed in to change notification settings - Fork 32
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
Improve serialization of VFS URL query parameters #165
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please amend the commit message so that it says:
Improve serialization of VFS URL query parameters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is a test that you can place in a new file called __tests__/utils/fetch.js
:
import * as fetch from '../../src/utils/fetch';
describe('utils.fetch#encodeQueryData', () => {
test('should create valid query string', () => {
const result1 = fetch.encodeQueryData({
a: 1,
b: true,
c: null,
d: 'foo'
});
const result2 = fetch.encodeQueryData({
a: {
a: 1,
b: true,
c: null,
d: 'foo'
},
b: {
c: {
d: 'foo'
}
}
});
expect(result1).toEqual('a=1&b=true&c=null&d=foo');
expect(result2).toEqual('a.a=1&a.b=true&a.c=null&a.d=foo&b.c.d=foo');
});
});
As you can see from this test and the one in osjs-server, it demonstrates that issue with all values being strings 🤓
Yes, You are totally right. We should preserve value type somehow. |
To support encoding arrays, we can change method as below 🤔 function encodeQueryData(data, nesting = '') {
const pairs = Object.entries(data).map(([key, val]) => {
if (typeof val === 'object' && val !== null) {
return Array.isArray(val)
? encodeQueryData(val, nesting + `${key}`)
: encodeQueryData(val, nesting + `${key}.`);
} else {
return Array.isArray(data)
? encodeURIComponent(nesting) + '=' + encodeURIComponent(val)
: encodeURIComponent(nesting + key) + '=' + encodeURIComponent(val);
}
});
return pairs.join('&');
} Do you have a better idea? |
I have not yet reached a solution to this problem 🤔 |
Technically the serialization is correct, so I don't really think this needs to be changed to support arrays. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff!
Now that we're on the same wavelength on how this all should work, I thought I'd open a new review thread on the final issue which is to solve the preservation of types.
I have added a possible solution to this here: #165 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet. I think this is done now.
I'm at work now, but I will test this myself etc. and merge when I get home.
Thanks a lot for your help :) |
And thank you for making these changes.
Don't worry about that. I haven't spent any time I don't have to look at this.
Glad to hear that :) |
Hi again, did you find anytime to take a look at my new commited codes? |
Sorry. Personal stuff has prevented me from doing much lately. Sorry about that, but I will get to this ASAP. |
Could you split up this PR so that it only contains the URL changes ? Right now this technically contains two different kinds of work, and I don't want to merge everything at once. |
@andersevenrud Here is the subset of changes for URL serialization: Here is the subset of changes for URL unserialization: |
Do you agree to split like this:
|
I'm closing this since we've agreed on a way to move forward. I've also opened an issue where we can concentrate the discussion. Things got a bit confusing with the client/server stuff :D |
The implementation of encodeQueryData method changes to support encoding of nested objects.
Relevant: