Declaratively define order that responses are delivered

[wheresrhys]

Might be nice to declaratively define race conditions

e.g.

fm
  .once('blah', 200, {order: 1})
  .once('bloop', 200, {order: 2})

// code to test.. not a very exciting example
let a = 0;
fetch('bloop').then(() => a = 2)
fetch('blah').then(() => a = 1)

expect(a).toEqual(1) // true

Needs some thought as should probably only be available to 'oncey' methods. Also, maybe order is not the right abstraction. Maybe something a bit more like defining a dependency on another call is called for:

fm
  .once({name: 'blah', ...}, 200,)
  .once({name: 'bloop', ...} 200, {waitFor: 'blah'})

// code to test.. not a very exciting example
let a = 0;
fetch('bloop').then(() => a = 2)
fetch('blah').then(() => a = 1)

expect(a).toEqual(1) // true

[chet-manley]

I think your second suggestion is much more useful and declarative. As a more fleshed-out arbitrary example, let's say you have a scenario where a call to .../api/v2/users requires a previous call to .../api/v2/auth:

fm
  .once({
    name: 'auth-route',
    url: 'path:/api/v2/auth',
    response: new Response(...)
  })
  .once({
    name: 'users-route',
    url: 'path:/api/v2/users',
    response: new Response(...),
    requires: ['auth-route']
  })

// if not already authorized, app should fetch auth token automatically
await expect(app.get('users')).resolves.toEqual(...)

// or, app should fetch auth token automatically, but throws on bad credentials
await expect(app.get('users')).rejects.toThrow(APIAuthError)

// or, app should fetch auth token automatically, but rejects on bad credentials
await expect(app.get('users')).rejects.toBeInstanceOf(APIAuthError)

// no matter the app's implementation, the mocked fetch still works

consider:

• requires should allow a string or Array of strings, containing named route(s)
• A call to a route with a requires property
  • should throw if all required routes have not completed
  • should throw if any required routes do not exist
  • should otherwise pass requires check
• Undefined required routes
  • should throw in route call instead of declaration
    • allows required route(s) to be defined out of order

It seems prudent to only allow this functionality on named routes, to eliminate considerable implementation overhead, and thus complexity. This implementation also allows nested required routes without any extra work: users requires auth requires Oauth, et al.