facebook / create-react-app

Set up a modern web app by running one command.
https://create-react-app.dev
MIT License
102.79k stars 26.87k forks source link

Consider using Mock Service Worker as the default API mocking solution #11250

Open kettanaito opened 3 years ago

kettanaito commented 3 years ago

Is your proposal related to a problem?

Indirectly.

Create React App comes with React Testing Library as a great default for testing React applications. Elaborating on the topic of great defaults, I think it's safe to say that most CRA projects involve some extent of data fetching. Those components that do HTTP requests must be tested as well, so developers have full confidence in the applications they build. I think it makes sense to include an API mocking layer in CRA with a minimal setup that not only achieved the goal, but encourages best practices along the way.

Describe the solution you'd like

I'd like to suggest integrating Mock Service Worker (MSW) as the default API mocking solution in Create React App.

You can see the example of the proposed integration that features the minimalistic setup and re-usage of the same mock definitions in integration and E2E tests. I will be happy to open a pull request that showcases the changes necessary to have the library set up in Create React App.

Why I think Mock Service Worker is a good suggestion

  1. It's a request client-agnostic solution. This means that no matter how developers fetch the data, be it window.fetch, React Query, Apollo, SWR, they will be able to capture and mock the responses they need.
  2. Derived from the previous point, MSW setup remains the same when switching request clients. This means that the recommended setup we provide is not only suitable for the current tools that the developer uses, but also for any tools they may consider migrating to in the future.
  3. It can run across environments. You can reuse the same mock definitions in a browser, Node.js, React Native, Electron. All that with the same setup. The project is strictly following a framework-agnostic policy and does not introduce code specific to any framework.
  4. API types support. The library supports mocking of REST and GraphQL API, with Server-Side Events and WebSockets being in the future works. For instance, I've heard a lot of positive feedback from people migrating to MSW from the MockedProvider in Apollo.
  5. It's actively used and maintained. The library is years old and is being used by companies like Google, Spotify (read the case study), Auth0, and hundreds of others around the globe. We keep growing our community and the ecosystem around the project.

Describe alternatives you've considered

There are no alternatives (to my best knowledge) that would allow seamlessly reusing the same mock definitions across environments and, thus, different testing levels, on the same scale that MSW does. The current testing reality is that developers configure different tools, often repeating the testing setup, to achieve the same goal—all that to compensate for how such tools are written and function. Code repetition is the least concern here, as the technical implementation of most API mocking tools replace request-issuing clients, significantly decreasing the confidence in any related tests, as opposed to allowing the tested code to make requests as it does in production. MSW does not suffer from this.

I can also be terribly biased regarding this, so feel free to correct me and reference similar technologies that developers may consider.

Additional context

MSW introduced a brand-new approach to API mocking by utilizing the Service Worker API. That allows your application to perform requests and receive responses and have control over the network without stubbing anything. The concept and implementation behind MSW had brought it "The Most Exciting Use of Technology" award on Open Source Awards 2020 and established it as a technology to assess by TechRadar.

I can't ignore the fact that the adoption of MSW in Create React App would increase its usage surface, which would help to discover more issues and usage scenarios, improving the developer's experience for all our users and the ecosystem in general. Perhaps such integration could also bring more collaborators to the project and ensure its bright future.

You can learn more about Mock Service Worker:

kentcdodds commented 3 years ago

I strongly support this 👍

nareshbhatia commented 3 years ago

Wholeheartedly support this idea 👍

In fact, MSW is built right into my team's template (which is based on CRA): https://github.com/PublicisSapient/cra-template-accelerate. Making it an integral part of CRA will give greater visibility to this awesome tool, and will help React developers improve the quality of their work.

alffrey commented 3 years ago

I've spent numerous hours mocking and stubbing data for tests over the years wishing for a better approach and tool. I was recently introduced to MSW and love how it instantly improves the developer experience. Would love to see it as a default in CRA.

ryota-murakami commented 3 years ago

Good Idea 👍 BTW anyone know is there tool kind of convert MSW mock-server to real backend server like Express?

kettanaito commented 3 years ago

@ryota-murakami, as a matter of fact, we've just released an extension that does just that. It's called http-middleware and you can read about it in this post.

ryota-murakami commented 3 years ago

@kettanaito this is awesome! That's exactly what I've been looking for!

ryota-murakami commented 2 years ago

@kettanaito Hello Artem! I'm created opinionated configured Vite extended template as a CRA alternative.

https://github.com/laststance/vite-react-ts-extended

It's installed msw already but currently I had only setup for jest.
I'd like to add browser side setup as a built-in data fetch/mutation solution, but I'm not familiar msw as a service worker.

I wanna ask you your prefer setup as a author, I followed getting start document though.
Or send PullRequest directory is really really appropriate it if you have a little free time! 😀

Main use cases are Demo, Prototyping, little experience any library or React itself etc.