MirageJS: An API mocking library for frontend development

Just my two cents: Mirage is freaking great because it makes mocking shit out pretty much as easy as possible and pretty damn correct.

I don't know how many times mocking up a UI I start to throw some random JS objects in a file and then inevitably after a few hours, those random JS objects are unmanageable and contain very small differences between what my API will deliver.

Using Mirage from the start of projects has made my life a lot easier, it also provides a nice sanity check between what the backend delivers and what the frontend actually expects.

Hello! I'm Sam and I built Mirage JS to be a framework-agnostic API mocking library.

Mirage is extracted it from an addon that's been widely used in the Ember ecosystem for the past 4 years, at companies like Apple, Heroku, Square and Footlocker.

Nearly all frontends need to talk to an API, no matter what framework they're built with! So over the past year I've made Mirage work with any tool or test runner.

I really believe deeply in the frontend-first workflow, and Mirage makes that easier than ever. If it sounds interesting to you, check out the lib + let me know what you think!

I used Mirage with Ember for many years and it has changed the way I think and approach front-end acceptance testing. I was very excited to see the work to extract the Ember-specific bits from the rest of the library (originally by @cowboyd / Charles Lowell and now from the original author Sam Selikoff himself) and am using it with a React app to great success.

How does mirage help with data differences with the real back end? I can't see how it isn't just as vulnerable to getting out of sync.

I have another question. Mirage is installed as a dev dependency. But all the examples show it being used in the application code. Do you maintain a separate branch without the import of Server, etc? Or is webpack smart enough to remove all imports/usage of dev dependencies in the prod build? I don't think I've ever imported dev dependencies into app code before.

For that matter, how does it provide a sanity check between what the back end delivers and the front end expects? Do you mean compared to coding to a spec with no mocking? Like when the back end doesn't exist yet?

Clearly I'm missing something. Could be the sleep deprivation.

I would rather make a component that takes data as props.

Now make a component on top that runs a network request and injects the network response into it.

Now you have a reusable component independent of the api. Your network function can be tested individually. Your top level component doesn’t need testing as that is the part that would be mocked.

You can now test your actual component without any mocking.

If you need some dummy data to show before the backend team is ready, this is trivial. Guess I’m just not a Big enough mocking fan to ever need a library for what is such a small thing in my experience