Open JohnAlbin opened 2 years ago
would be nice indeed to have that ability
@yormy This missing feature was a deal breaker for me; I needed to test successful endpoint responses and failures. I ended up writing my own Storybook wrapper around the fetch-mock library.
@JohnAlbin your code only mocks fetch, but Angular uses XHR, so it's important to note that it's not compatible with Angular apps. Unlike this module =)
And yeah, this module is mockingly powerless to do real mocking. Can't set headers etc, that's just pathetic.
your code only mocks fetch, but Angular uses XHR, so it's important to note that it's not compatible with Angular apps.
Fair enough. But if an app needs XHR mocking, it's pretty clear storybook-addon-fetch-mock
only does fetch mocking.
And yeah, this module is mockingly powerless to do real mocking. Can't set headers etc, that's just pathetic.
Don't be unkind. Just because storybook-addon-mock
doesn't solve our issues, doesn't mean it can't solve lots of other people's issues.
Don't be unkind. Just because
storybook-addon-mock
doesn't solve our issues, doesn't mean it can't solve lots of other people's issues.
Well, after I invested time into integrating this module, it just doesn't work for anything beyond simple things. That's quite unkind from the module.
Imagine you take a car, it goes 10km and stops middle-way. Not what you'd expect ;(
That said, I appreciate the time @nutboltu spent developing this and making it open source. There's just a small step further. I'll try to make a PR and hopefully one day the author accepts it.
Added MR for customized status code returns
I've just added a PR for adding response headers option support https://github.com/linearlabs-workspace/storybook-addon-mock/pull/206
When mocking fetch responses, we should have full dynamic control over all aspects of the Response object, including:
Currently, we only have this:
response
to a function)Example use case
I have a fetch endpoint that various authentication tasks and they all use the same URL; the endpoint returns different data, status codes and headers depending on the request body.
In one story, I have a page component that needs to have the client credential request respond with HTTP 200 immediately followed by another request to the same endpoint that should respond with HTTP 500 (mocking a user validation error).