storybook-addon-mock icon indicating copy to clipboard operation
storybook-addon-mock copied to clipboard

Ignore url params (query string)

Open carloschneider opened this issue 3 years ago • 16 comments

I've a scenario where I need generate dynamic url params, like:

?person[0][name]=John+Doe&person[1][name]=Hello+World

When I set the mockData I need mock the parameters too. That way I've got an error when the mock is different from the url request: net::ERR_NAME_NOT_RESOLVED.

A solution would be to create an option to disable the query string check.

carloschneider avatar Dec 14 '21 20:12 carloschneider

@carloschneider this is a special case, where we have to ignore the query parameters. In this scenario, it would be good if we used an asterisk(*) in the URL path to ignore them. Like below

/todos?*

In the package, we are using pathtoregexp package to match the paths. I would recommend trying this approach to resolve this issue.

As this is a special case, introducing a new field Ignore params will make confusion to others. Moreover, this is not a generalized API for this addon.

Considering the overall perception, I am going to revert the PR. Let's discuss further if the asterisk(*) option would fit your requirement.

nutboltu avatar Dec 26 '21 22:12 nutboltu

@nutboltu Using * doesn't work https://runkit.com/embed/uqis3n6q1qt6.

The code just tests path with path-to-regexp. The query string is tested separated.

https://github.com/nutboltu/storybook-addon-mock/blob/8705e8ba31eabcf5117e918c509a79ea345f1582/src/utils/faker.js#L86-L89

carloschneider avatar Dec 27 '21 00:12 carloschneider

The idea is to replace with match function with the exec function which supports the *. ATM, I haven't managed time to look into this implementation during this holiday. Hope to start working on this feature early next year.

But any PR will be welcomed 💯

nutboltu avatar Dec 29 '21 02:12 nutboltu

@nutboltu right.

What if we remove that params validation line?

https://github.com/nutboltu/storybook-addon-mock/blob/aa49c2245d57f9d305a421bfa64c2b9c0e93a235/src/utils/faker.js#L88

carloschneider avatar Mar 08 '22 11:03 carloschneider

Is there any progress on this?

saulrobe avatar May 17 '22 20:05 saulrobe

I suggest (https://github.com/nutboltu/storybook-addon-mock/pull/115) to give comparing query parameters to path-to-regexp package like the path. There we have one disadvantage that this package not handle different order of parameters, but we always can pass regexp { url: '/path?(.*)' } and write our custom response function.

tenorok avatar Jun 14 '22 16:06 tenorok

First of all thank you for the great package it's really useful for us. Can we have an update on this ? we would like to mock dynamic urls and since even the order of query params is fixed we cannot do this at the moment. Thanks.

adriankott avatar Jul 05 '22 10:07 adriankott

@tenorok @adriankott I am currently wrapping things up in launching version 3 of the addon. I have seen @tenorok already raised a PR. I will include the changes in version 3. The overall ETA would be 2-3 weeks. I would really appreciate your patience.

nutboltu avatar Jul 05 '22 12:07 nutboltu

Just a suggestion - would be useful with optional property "parameters" with the value of obj/array which will not care about the sequence. { url: '/someUrl', method: 'GET', parameters: { param1:'val1', param2: 'val2' } || [ 'param1=val1', 'param2=val2' ] }

s1m0nDevs avatar Jul 05 '22 15:07 s1m0nDevs

Any updates?

s1m0nDevs avatar Oct 24 '22 10:10 s1m0nDevs

@nutboltu so to summarize:

  • a variant with flag in mock options object to disable query string parsing looks as unacceptable to this lib
  • the accepted way is to add asterisk support (e.g. /foo?*) which will basically work the same as the flag and skip query matching entirely

Am I right?

I can prepare PR. Will it be accepted in the nearest future?

SleepWalker avatar May 07 '23 10:05 SleepWalker

Hi @nutboltu,

The PR #115 by @tenorok seems to be ready. Is there something we can do to help?

This feature is really a must for me. Indeed, it would be really hard to maintain the mocks if I have to hard-code the query string.

Many thanks for the amazing work, Cheers!

JoaoBrlt avatar Sep 11 '23 10:09 JoaoBrlt

@JoaoBrlt that PR has a lot of merge conflicts. Would you like to take the ownership of this feature?

nutboltu avatar Sep 12 '23 01:09 nutboltu

Hi @nutboltu,

Sure! I would be glad to contribute to the project. I will take a close look at the PR tomorrow to check if the conflicts are easy to resolve or I'll reimplement the feature if too many things have changed.

JoaoBrlt avatar Sep 12 '23 21:09 JoaoBrlt

A couple days ago I've fork this repo and implement this feature in an old version (I'm working with an old version of Storybook), and it has worked for me.

@nutboltu could you take a look in my PR? I recommend bump to a major version, because the question mark will break who already use the current version.

@JoaoBrlt let me know if it works for you.

carloschneider avatar Sep 13 '23 01:09 carloschneider

Hi @nutboltu,

So we have several options.

Option 1: Continue using the match function

We can continue to use the match function from the path-to-regexp package, passing the full URL and making sure to escape the question mark from the query string to avoid it being interpreted as a regular expression character. This is what @tenorok has implemented. Unfortunately, this solution has a major downside. The match function does not correctly manage the order of query parameters because it simply uses a regular expression. This would force current users who don't want their mocks to depend on the order of query parameters to update their queries by passing a regular expression like /path?(.*) with a custom response function. This leads to a lot of complexity for such a simple feature.

Option 2: Use the exec function

We can use the exec function from the path-to-regexp package. This allows users to use ?* in their requests to match zero or more request parameters as a regular expression. This is what @carloschneider has implemented. Unfortunately, this solution introduces a breaking change. Indeed, current users would have to update all their queries using query parameters to escape the question mark at the start of the query string to avoid it being interpreted as a regular expression character. We could also parse the URL and escape it ourselves. But again, this leads to a lot of complexity for such a simple feature.

Option 3: Add two simple options

As @carloschneider suggested at the beginning, we can implement two simple options to simply ignore query parameters when necessary. A first option to ignore query parameters on a per-request basis. A second option to ignore query parameters globally in the global configuration. The implementation is very simple and leads to no breaking change for current users. If you're interested in this option, I've just implemented it in PR #191.

Cheers everyone!

JoaoBrlt avatar Sep 14 '23 22:09 JoaoBrlt