You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is really the same as #98 but that issue has been locked. The original rational for not adding the ability to pass configuration parameters to qs was that package was abandoned. That is no longer the case and qs is now actively maintained. As such, I wonder if we might be able to revisit the original request and decision as that ability would be really useful.
Also released is #203 requesting support for custom parsers. That issue is perhaps less important since qs is maintained again?
The reason I'd like to see this, is that if I submit something like l-2[].dp-1 then the parameter in req.body is alwaysl-2 regardless of what follows the []. (I think the same applies with just a .) due to the lack of support being able to set allowDots in qs.
The text was updated successfully, but these errors were encountered:
I agree with him.
And in any case, I want to solve this problem as soon as possible, so I will fork body-parser in the meantime.
For future compatibility, I am curious to see if the library will take the generic parser as a solution or reorient itself in response to #453.
I would like to hear your thoughts once again.
I had parsing inconsistencies when using with Datatables Editor until I found out is was something that could be configured using qs options.
For instance, DT Editor by default uses an id, which is usually an integer, to identify objects and because of default array options in qs:
Sending this query string: data[2][name]=joe, results in: data: [{name: "joe"}] (data is an array)
But with a higher id number:
Sending this query string data[101][name]=joe2 results in: data: {"101": { name: "joe2" }} (data is now an object)
So it can result in an array or a plain object depending on the value of the number because the default limit for parsing an array is 100; above that threshold, it's parsed to an object.
In this case it's preferable to set qs not to parse arrays or have the array limit to 0.
So, would be nice to expose "advanced" qs options.
@dougwilson, have there been any new thoughts on the idea of passing parameters to qs? Or should we still wait for a next major release for a new approach on this parsing "issue", so to speak.
Thanks !
This is really the same as #98 but that issue has been locked. The original rational for not adding the ability to pass configuration parameters to
qs
was that package was abandoned. That is no longer the case andqs
is now actively maintained. As such, I wonder if we might be able to revisit the original request and decision as that ability would be really useful.Also released is #203 requesting support for custom parsers. That issue is perhaps less important since
qs
is maintained again?The reason I'd like to see this, is that if I submit something like
l-2[].dp-1
then the parameter inreq.body
is alwaysl-2
regardless of what follows the[].
(I think the same applies with just a.
) due to the lack of support being able to setallowDots
inqs
.The text was updated successfully, but these errors were encountered: