storybook-addon-mock
storybook-addon-mock copied to clipboard
Ignore url params (query string)
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 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 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
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 right.
What if we remove that params validation line?
https://github.com/nutboltu/storybook-addon-mock/blob/aa49c2245d57f9d305a421bfa64c2b9c0e93a235/src/utils/faker.js#L88
Is there any progress on this?
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.
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.
@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.
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' ] }
Any updates?
@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?
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 that PR has a lot of merge conflicts. Would you like to take the ownership of this feature?
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.
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.
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!