Story-specific handler / request persisting after switching stories

[mmirus]

Hi there! Thanks for the add-on!

I'm running into a problem with a story that demos a loading state:

1. The Loading story applies a handler with ctx.delay('infinite'). This story works great!
   • Specifically, this is a graphql handler for a request from Apollo Client.
2. But when I load that story and then switch to another story in the same file, that second story also appears as loading forever. The pending request from the first story remains in the network tab, and no new request appears from the second story.

Any help debugging / solving this would be appreciated! Please let me know if additional info would be helpful.

It's a bit hard to debug this / pinpoint what part of the stack may be responsible for not ending the pending request and initiating a new one when switching from the Loading story to the next one. Apologies if I'm barking up the wrong tree.

In the meanwhile, since refreshing the browser tab on the second (non-loading) story allows that story to load correctly, I've worked around this by using a decorator that reloads the iframe when leaving the Loading story. This is the only workaround I've found that helps.

// Yuck...
Loading.decorators = [
  (Story) => {
    useEffect(() => {
      return () => window.location.reload();
    }, []);

    return <Story />;
  },
];

[tomgardiner-retailx]

I'm having this exact same issue - and it was related to when I started specifically passing in multiple mocks to the msw handler. I still don't know what's causing the issue, but thanks for your workaround.

Example of what caused it:

// Works
Primary.parameters = {
  msw: {
    handlers: [someMock],
  },
};
Secondary.parameters = {
  msw: {
    handlers: [someMock],
  },
}

//doesn't work
Primary.parameters = {
  msw: {
    handlers: [someMock, someMock2],
  },
};
Secondary.parameters = {
  msw: {
    handlers: [someMock, someMock2],
  },
}

[aaronmcadam]

This seems to be an issue with msw 0.4x, as we don't see the problem with 0.3x.

@yannbf I've recreated this problem in a branch of the mealdrop app here: yannbf/mealdrop@main...aaronmcadam:mealdrop:am-persisting-mocks

Any ideas?

[aaronmcadam]

Here's a screencap of the issue:

[melissawahnish]

I also experienced this when mocking different graphql query responses within the same storybook file. @mmirus's solution does work. Please let us know if this issue is addressed. Thanks!

[aaronmcadam]

I think if we had some way of resetting handlers like we can in unit tests (with server.resetHandlers()), that might help us make sure the story uses the correct handler.

[philjones88]

Also experiencing this with rest handlers. Can't seem to override global handlers I defined in my preview file either.

[fazulk]

Noticing this aswell using 1.6.3. Thankfully doesn't affect chromatic tests. For now i need to refresh the page to get the correct handlers to load for that story. Not the solution of course.

[philjones88]

I kinda work around this by setting RTK's refetchOnMountOrArgChange to true. That seems to workaround the issue and swapped to named handlers not arrays.

[mattduggan]

I've run into this issue and noticing that the way initialize works introduces a memory leak in the test environment if you reuse your stories there.

MSW documentation covers reseting handlers between tests and closing the server after each test file has completed. Storybook documentation also covers how to reuse stories in test.

By then introducing msw-storybook-handler:

1. A server is created before each test file is run and never closed, unable to be garbage collected.
2. The server(s) handlers aren't reset, so a previous server may still be intercepting the requests causing unexpected behavior.
3. We can not reuse an existing worker/server if we've already set one up.

For all cases, I think resetHandlers should be called between stories.

• This does occur in mswDecorator, but you'll need to retrieve the worker/server to have better control outside Storybook

For reusing a server, perhaps initialize could accept it as another option to set as the internal "api".
For test case, esp. where you're not reusing an existing server, documenting how to close it in test.

Ex:

// .storybook/preview.js
import {server} from '../mock/server';
export const api = initialize({api: server});

// setupFileAfterEnv.js
import {api} from './.storybook/preview';

beforeAll(() => api.listen());
afterEach(() => api.resetHandlers());
afterAll(() => api.close());

It's a little clunky, though. Would appreciate other's thoughts. Currently, I've resorted to checking the test environment in .storybook/preview.js and rewriting the mswDecorator to ensure things are cleaned up.

[aaronmcadam]

Currently, I've resorted to checking the test environment in .storybook/preview.js and rewriting the mswDecorator to ensure things are cleaned up.

How are you doing that?

[mattduggan]

Copy/pasting the internals of mswDecorator, replacing the api reference with our server.

import {server} from '../src/mock/server';

const isTest = process.env.NODE_ENV === 'test';

if (!isTest) {
  initialize()
}

export const decorators = [
  isTest
    ? (storyFn, context) => {
        const {
          parameters: {msw},
        } = context;
        if (msw) {
          if (Array.isArray(msw) && msw.length > 0) {
            // Support an Array of request handlers (backwards compatability).
            server.use(...msw);
          } else if ('handlers' in msw && msw.handlers) {
            // Support an Array named request handlers
            // or an Object of named request handlers with named arrays of handlers
            const handlers = Object.values(msw.handlers)
              .filter(Boolean)
              .reduce(
                (handlers, handlersList) => handlers.concat(handlersList),
                []
              );

            if (handlers.length > 0) {
              server.use(...handlers);
            }
          }
        }
        return storyFn();
      }
    : mswDecorator
];

[mattduggan]

Here's something a little better I have working:

export const mswDecoratorFactory = (api) => {
  const onUnmount = () => {
    api.close?.() || api.stop();
    api.resetHandlers();
  };
  
  return (Story, context) => {
    const initialRender = useRef(true);

    const {
      parameters: {msw},
    } = context;

    if (msw && initialRender.current) {
      let handlers = [];
      
      if (Array.isArray(msw)) {
        handlers = msw;
      } else if ('handlers' in msw && msw.handlers) {
        handlers = Object.values(msw.handlers)
          .filter(Boolean)
          .reduce(
            (handlers, handlersList) => handlers.concat(handlersList),
            []
          );
      }
      
      if (handlers.length > 0) {
        api.listen?.() || api.start();
        api.use(...handlers);
      }
    }

    useEffect(() => {
      initialRender.current = false;
      return onUnmount;
    }, []);

    return <Story />;
  };
};

Usage:

export const decorators = [
  mswDecoratorFactory(!!process?.versions?.node ? require('path/to/server').server : require('path/to/browser').worker)
];

In my case, I'm also using @mswjs/data for mocks, which can be used independently of msw itself. In my decorator, I've added a drop(db) to onUnmount to ensure it's clean between Stories. YMMV.

[coofzilla]

I'm having the same issue as this. I tried to import all my handlers into preview.js and then only add the handler required for each story, but that didn't work either. Like the others above, my current solution has just been to refresh.

export const marketHandler = rest.get(
  `some/coin/route`,
  (req, res, ctx) => {
    return res(ctx.json(mockMarketPrices));
  }
);

export const loadingHandler = rest.get(
  `some/coin/route`,
  (req, res, ctx) => {
    return res(ctx.delay('infinite'));
  }
);

export const allNamedHandlers = {
  marketHandler,
  loadingHandler
}

// preview.js
export const parameters = {
  msw: {
    handlers: allNamedHandlers,
  }
}

export const MockedSuccess = Template.bind({});
MockedSuccess.parameters = {
  msw: {
    handlers: { marketHandler },
  },
};

export const MockedLoading = Template.bind({});
MockedLoading.parameters = {
  msw: {
    handlers: { loadingHandler },
  },
};

[JohnValJohn]

I thought I had the same issue, but it turned out that my problem was actually this one : mswjs/msw#251 (comment) (I am using Apollo and the requests were cached and never re-executed)

[mmirus]

@JohnValJohn Did you find a way to clear the cache when switching stories?