-
Notifications
You must be signed in to change notification settings - Fork 104
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
Function to Serialize JS objects in Query String Parameters #161
Comments
Heh, I've tried to do this so many times. One of them resulted in #136 . All of them however end up not being generic enough, or too big and add bloat that I'm not sure is worth it (to keep Bliss small, we need to exercise a lot of restraint). |
Thanks for the heads up. I did not see that issue. I think at the minimum just taking the existing functionality and moving it to a place where it's testable and fixing the bug I mentioned above would be an improvement without trying to add new functionality. |
I guess Lea already knows this, but in relation to this issue it can be interesting to note anyway: The URL standard, https://url.spec.whatwg.org/, actually has a Query String builder in the form of
The URL standard sort of feels like the As Bless is about vanilla js it could perhaps be interesting to try and use suchna standard if one wants to make something like this more generic. That will also show possible short-comings in the standard which one can eg. propose extensions to fix where suitable – such as maybe a way to send in such a plain object directly into Not sure how if Bliss is generally positive or negative towards relying on polyfilling – it can surely make Bliss less small. If one would want to try and use more of the URL standard going forward then there seems to be polyfills like https://github.com/WebReflection/url-search-params out there anyway that one can use until non-Firefox browsers catches up on that spec part. Update: There's actually already an issue about this in the URL-spec repo: whatwg/url#27 |
I've looked into URLSearchParams, no idea why I decided against using them there. |
URLSearchParams is useful if you want to manipulate a query string (probably intended for usage pushState and similar), but not as much if you want to build them from scratch from object literals.
|
I just posted an alternative suggestion (json) to this problem: #213 |
You can try to use q-flat package
will be convert to
More details: |
You probably shouldn't use query strings for that ^. All your numbers will be converted to strings. See #213. |
@friday well, I don't use query-string for that, I use that for query-string :) |
This is in reference to this line in the code:
o.data = Object.keys(o.data).map(function(key){ return key + "=" + encodeURIComponent(o.data[key]); }).join("&");
I just noticed that there is a very helpful utility function nested in 'fetch' that is not testable and not reusable even though it has pretty generic functionality (serializing objects into Query String params.)
Thoughts on moving this functionality into it's own utility method that is testable and reusable?
Lastly, I can make a pull request if necessary but I would suggest adding encodeURIComponent to the 'key' variable as well because JavaScript allows characters in object keys that need to be encoded in order to be valid query parameter keys. e.g.
var params = { "tom & jerry": "friends" };
The text was updated successfully, but these errors were encountered: