From ee696087a95102ebbebcd676841035a35d1ce6eb Mon Sep 17 00:00:00 2001 From: Timothy Leverett Date: Wed, 28 Apr 2021 16:58:56 -0400 Subject: [PATCH] Fixed minor formatting issues --- .../advanced/server-configuration/template.md | 105 +++++++++--------- 1 file changed, 53 insertions(+), 52 deletions(-) diff --git a/tests/dummy/app/pods/docs/advanced/server-configuration/template.md b/tests/dummy/app/pods/docs/advanced/server-configuration/template.md index 5a2837048..013d6a646 100644 --- a/tests/dummy/app/pods/docs/advanced/server-configuration/template.md +++ b/tests/dummy/app/pods/docs/advanced/server-configuration/template.md @@ -1,60 +1,61 @@ # Server configuration -The MirageJS server is configured for you by ember-cli-mirage. However, if you need to customize the server you can by creating a makeServer function in the config.js. +The MirageJS server is configured for you by ember-cli-mirage. However, if you +need to customize the server you can by creating a makeServer function in the +config.js. The named `makeServer` function export gives you a lower-level way to hook - into how your Ember app instantiates your Mirage JS server. - - Typically, the `/mirage/config.js` file contains a single default export which - is a function defining all your Mirage route handlers. Ember CLI Mirage then - uses this function, along with all the other modules you've defined in - `mirage/models`, `mirage/fixtures`, `mirage/factories`, and - `mirage/serializers`, to create your Mirage JS server when your app boots up - in development and testing. - - You can now opt in to having more control over exactly how your Mirage server - is instantiated, as well as the ability to use imports directly from the - `miragejs` npm package, by exporting a single named function called - `makeServer` instead. - - `makeServer` receives a single argument called `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 - when using `makeServer`, we have provided an additional import called - `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. - - The only thing needed to enable this behavior is that you delete the default - function export and instead export a single named function called - `makeServer`. 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`. - - Eventually, `ember-cli-mirage` will shed its re-exports of everything from - `miragejs`, and become a small wrapper library delegating the rest of the work - to `miragejs`. This will help align the Ember Mirage users with the rest of - the Mirage JS community. +into how your Ember app instantiates your Mirage JS server. + +Typically, the `/mirage/config.js` file contains a single default export which +is a function defining all your Mirage route handlers. Ember CLI Mirage then +uses this function, along with all the other modules you've defined in +`mirage/models`, `mirage/fixtures`, `mirage/factories`, and +`mirage/serializers`, to create your Mirage JS server when your app boots up +in development and testing. + +You can now opt in to having more control over exactly how your Mirage server +is instantiated, as well as the ability to use imports directly from the +`miragejs` npm package, by exporting a single named function called +`makeServer` instead. + +`makeServer` receives a single argument called `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 +when using `makeServer`, we have provided an additional import called +`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. + +The only thing needed to enable this behavior is that you delete the default +function export and instead export a single named function called +`makeServer`. 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`. + +Eventually, `ember-cli-mirage` will shed its re-exports of everything from +`miragejs`, and become a small wrapper library delegating the rest of the work +to `miragejs`. This will help align the Ember Mirage users with the rest of +the Mirage JS community. ```javascript - // Example with inline routes import { createServer, discoverEmberDataModels } from "ember-cli-mirage";