Put query data into the data parameter of the fixture function.

[mtnt]

No description provided.

[elisherer]

I think if look through superagent code you will find somewhere that query object in this. that way eliminate the need for qs (just a suggestion)

[mtnt]

@elisherer there is. It's in the qs key and it is cleared just after stringifying. Besides it is an inner property that I would not prefer to use =)

NB: I removed accidentally added commit Dirty

[elisherer]

wouldn't it be simpler to check includes?

[mtnt]

parts[1] is used further

[elisherer]

I think lodash is a big dependency here, will require consumers to have some lind of lodash optimization. better make those checks part of the code or change the imports to direct ones.

[mtnt]

I really think there are totally all projects have lodash) But ok, I removed it)

[mtnt]

@elisherer could you already merge or reject it?)

[DevSide]

Hi, thanks for your contribution @mtnt.

I wouldn't be exclusive between post data and query string because it is possible to have query params in a POST url 😄.

If I well understand what you need, you can use Regexp capturing groups in the pattern.

// Example 1, the pattern is stricted and the query params order is known
{
  pattern: 'https://domain.example?limit=(\d+)&offset=(\d+)',
  fixtures: match => {
    const [, limit, offset] = match;
    // ...
  }
}

// Example 2, the pattern matches every requests with query params
[{
  pattern: 'https://domain.example?(.*)',
  fixtures: match => {
    const { limit, offset } = qs(match[1]);
    // ...
    // may handle 404 somewhere
  }
}]

[mtnt]

@DevSide hmm, I got your point... Yeah, I did not think about usage query params in a POST...
But. Don`t you think the current behavior is much inconsistent?

Maybe the data should be an object with query and data keys in this case?

PS yeah, the regexp is that what I currently use for this purpose.

[mtnt]

Usage of a regexp is not convenient: actual params order may be different with a pattern. Much more useful way is to get somehow a package of parsed data.

UPD: it`s possible to use "?(.*)" and parse it - in this case each user should reverse engineer the superagent and clarify the qs library usage for stringifying params.

[DevSide]

path-to-regex could be better choice I guess but not sure it handles query params.

[mtnt]

Oh, I`m sorry, I forgot one more thing: passing complex params such as objects and arrays are converted not like json: query({foo: {a: 1, b: 2}}) will be ...?foo[a]=1&foo[b]=2. It is little bit difficult to parse it using regexp =(