-
-
Notifications
You must be signed in to change notification settings - Fork 731
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
Array of Objects should always have indices #422
Comments
So, to clarify - you want to stringify into a mix of What's your serverside where that's idiomatic? |
Note that doing something implicit here isn't an option, because |
Hi @ljharb - thank you looking into this. I can see the potential problem with the array of mixed data types To answer your first question, we are making a tool that supports permalinks for the URI. One of the query parameter fields is an array of string values and a second one needs to be an array of objects because it needs both a database name and an ID for each element in the array. We also have more fields to add in the future to the tool that would likely need multiple fields grouped together. The schema for the object we want to reconstruct is the same as the one provided in the example of the OP, just the names changed to be generic values. The permalinks work as needed when the string array in stringified to I attempted to use the filter option to create my own callback to handle the encoding of the simple array, but couldn't quite figure out the proper way to return the value. Maybe this is a path to investigate more. As for the example array of mixed datatypes you mentioned as being problematic, I image the following string would be supported by the current parser to rebuild that array properly (I'm not on my development computer at the moment to try for myself). Pseudo code to stringify: For example |
It looks like that already works as hoped: const qsObj = qs.parse('arr=1&arr=a&arr[2].b=c&arr[3].d=e', { allowDots: true });
JSON.stringify(qsObj, null, 4)
/*
{
"arr": [
"1",
"a",
{
"b": "c"
},
{
"d": "e"
}
]
}
*/ The one exception is that the first element is a string instead of a number, but I think that will always be the case |
@jerrens yes, it will; all query params are always containers or strings unless you decode them differently. |
In the scenario of stringify'ing the following object:
I would like to encode the query string as:
string=A&string=B&string=C&obj[0].field1=A.1&obj[0].field2=A.2&obj[1].field1=B.1&obj[1].field2=B.2
I've attempted to use the stringify options:
{ encodeValuesOnly: true, allowDots: true }
along with various forms of the indices choices, but I can't seem to get the right combination.Would it make sense if the stringify options of
indices: false
and/orarrayFormat: 'repeat'
logic were to be updated to not include indices UNLESS the element type is an object - when it is an object, indices would need to be included because otherwise there is no way to know which fields the individual params should be reassembled into.Current Attempts:
In the second and third examples, are qs.parse'es back into:
which make sense.
I have also confirmed that my desired format:
string=A&string=B&string=C&obj[0].field1=A.1&obj[0].field2=A.2&obj[1].field1=B.1&obj[1].field2=B.2
does correctly parse into the original object, so no code change would be required on the parsing side.The text was updated successfully, but these errors were encountered: