Skip to content

Latest commit

 

History

History
125 lines (98 loc) · 4.96 KB

File metadata and controls

125 lines (98 loc) · 4.96 KB

Server configuration

The MirageJS server used to be configured for you by ember-cli-mirage. This has been deprecated in favor of configuring the server similar to MirageJS.

Typically, the /mirage/config.js file contains a default export (no parameters) which is a function defining all your Mirage route handlers.

This new default export function receives a single argument usually named config, which contains all the factory/fixture/serializer/model modules that exist in your project's /mirage directory. This saves you from having to import each module explicitly and then pass it into your Mirage server, just like you're used to with the default setup.

The config argument maps exactly to everything inside of your /mirage directory - notably, it does not contain the autogenerated Mirage model definitions derived from your Ember Data models, which is an important feature of Ember CLI Mirage that is enabled by default. To replicate this behavior, a helper has been provided named discoverEmberDataModels from the ember-cli-mirage package that you can use to augment your config with these models so that your Mirage schema is automatically inferred from your host application's Ember Data models and relationships. The snippet below shows how to do this. Note that the order here matters if you also have models defined in your /mirage/models directory, as those model definitions would "win" in the event of a conflict with the ones autodiscovered from Ember Data. (However, most of time if you are inferring your Mirage schema from Ember Data, you shouldn't need to define additional models.)

Finally, your route handlers just need to be passed to the routes() key in your Mirage config. You can do this inline, or you can make them a separate function, and organize that function however you choose.

You should also add miragejs to your project's dependencies in your package.json file, since you are now importing directly from it. Note that this gives you the added benefit of being able to upgrade miragejs independently of ember-cli-mirage.

All the objects from miragejs are re-exported in ember-cli-mirage such as Model, belongsTo, hasMany as well as Fixtures, Traits for example. These have also been deprecated and you should import directly from miragejs. This will help align the ember-cli-mirage users with the rest of the Mirage JS community.

// Example with inline routes
import { discoverEmberDataModels } from "ember-cli-mirage";
import { createServer } from 'miragejs';

export default function(config) {
  let finalConfig = {
    ...config,
    models: { ...discoverEmberDataModels(), ...config.models },
    routes() {
      // this.namespace = '/api'

      // this.resource('user')
    },
  };

  return createServer(finalConfig);
}

// Example with routes in an external function
import { discoverEmberDataModels } from "ember-cli-mirage";
import { createServer } from 'miragejs';

export default function(config) {
  let finalConfig = {
    ...config,
    models: { ...discoverEmberDataModels(), ...config.models },
    routes,
  };

  return createServer(finalConfig);
}

function routes() {
  // this.namespace = '/api'

  // this.resource('user')
}

See MirageJS documentation for other options.

Serializers

If you would like to have Mirage adjust or create your serializers for you from your ember data serializers adjust your server configuration to have mirage perform this for you.

When Mirage auto discovers your ember data models, should you also have the same model defined in mirage, it will use the mirage version of the model. With serializers, you may have created a mirage serializer to override some methods, but would still like Mirage to apply the primaryKey and transforms. For that reason the method to apply these properties is different than the way you merge the models.

applyEmberDataSerializers will apply the primaryKey and attrs from your ember data serializers to your mirage serializers. If you have not created a mirage serializer it will create one and extend it from your mirage application serializer. Ensure your application serializer extends from EmberDataSerializer as the default JSONApiSerializer will not understand how to use primaryKey and transforms. If you have not created a mirage serializer named application, the created serializer will extend EmberDataSerializer directly.

// Example of having Mirage adjust/create your serializers similiar to ember data models

import { discoverEmberDataModels, applyEmberDataSerializers } from "ember-cli-mirage";
import { createServer } from 'miragejs';

export function makeServer(config) {
  let finalConfig = {
    ...config,
    models: { ...discoverEmberDataModels(), ...config.models },
    serializers: applyEmberDataSerializers(config.serializers),
    routes,
  };

  return createServer(finalConfig);
}

function routes() {
  // this.namespace = '/api'

  // this.resource('user')
}