Seeds/scenario chooser in dev

[samselikoff]

---

2 upvotes from Canny

[teejayhh]

I am building an addon inhouse atm which does exactly that. Its fairly straightforward to implement it yourself. Without much hacking you can modify the default scenario to load other scenarios. You can create a scenario manager for instance, which either uses a url parameter or local storage to retrieve a scenario name. In the default scenario you can use the this or server._config.scenarios var to get a list of all available scenarios inside of your scenario folder. Now what's left is to match up the scenario from the list with your url param value or whatever. This approach has been working out pretty well for us. Give it a try.

[allthesignals]

The use case for us is that we need to user test our apps under specific user scenarios. For example, user has xyz assigned projects and must complete abc tasks. I'll give @teejayhh's solution a try!

[samselikoff]

Yeah I've come to believe this feature isn't really something Mirage needs to have a first-class API to support. It's basically a subset of "run different code under certain conditions" and those conditions could be build-time, run-time or something else.

I think a future API that might make sense for Mirage is a sort of "reset". I mean today you can do this with server.db.emptyData(), and then you can run a scenario through it. So yeah I think I'll be holding off on an official solution/recommendation here for a bit.

[samselikoff]

Some examples on the new site on how people are solving this would be great though!

[allthesignals]

@samselikoff hmmm that surprises me a little bit because the "scenario" concept in Mirage seems first-class through its usage in the folder hierarchy: a file entry in "mirage/scenarios/" implies the ability to add more "scenarios", as you would factories or fixtures or whatever else. On instinct I went around looking for a way to switch out the scenarios environmentally or through some other means.

I do think updating the docs with some examples will help clear up any confusion—I'm happy to look into that!—but I'm not sure it makes sense to dismiss this just yet.

Thanks!

[samselikoff]

a file entry in "mirage/scenarios/" implies the ability to add more "scenarios", as you would factories or fixtures or whatever else

I know, and I know this is confusing. That was the original intention but we just never got around to implementing it.

I agree we should clarify in the docs somewhere.

Ideally I would like to provide one set of instructions for all miragejs users, which means I want to learn how filesystem support works in React and Vue apps. It might be the case that we always have separate conventions in ember-cli-mirage, but we'll see.

[samselikoff]

The other thing is, in miragejs we're calling them seeds() instead of scenarios: { default() } for precisely this reason. (No other scenario support was ever implemented.)

[teejayhh]

I feel like it would not take too much to expose a simple api. For the project I was working I needed 4 key pieces.

1. Make scenarios useful, other then a function which creates seed data

• Instead of a function this is now an object with options, name, descriptions, endpoints, custom responses

2. The default scenario is the entry point to load a different scenario. In my case I have created a ScenarioLoader singleton which uses local storage to determine which scenario to pick. No one likes url parameters.
3. The mirage config loads a MirageServerProxy which augments/taps the put/post/del/get functions and returns something like this.

return mirageServer.post(route, this._createCallback(this.scenario, route, data, 'post'), options)

The _createCallback needs to return a function which returns

     // create a new RouteHandler to create a normal proper mirage response
      const routeHandler = new RouteHandler({
        schema,
        verb: requestType,
        rawHandler: data,  // modify if you like for some cool use cases
        path,
        serializerOrRegistry: server.serializerOrRegistry,
      })

      return routeHandler.handle(request).then((mirageResponse) => {
        return new Response(...mirageResponse)
      })

4. And as the fourth part you probably need a component which lets you pick a scenario.

I hope this helps to get something started @allthesignals

[allthesignals]

Docs PR here: miragejs/ember-cli-mirage#1802

[samselikoff]

FYI: Transferred this to our Discuss repo, our new home for more open-ended conversations about Mirage!

If things become more concrete + actionable we can create a tracking issue in the main repo.