[#564] Tighten docs around force404 behaviour #876
Conversation
| --- | ||
|
|
||
| Start a server to begin routing responses to `cy.route()` and `cy.request()`. | ||
| Start a server to begin routing responses to {% url `cy.route()` route %} and {% url `cy.request()` request %}. |
There was a problem hiding this comment.
Hyperlinking the first mention of these other commands in order to be helpful.
| @@ -67,7 +65,7 @@ Option | Default | Description | |||
|
|
|||
| ***After starting a server:*** | |||
|
|
|||
| - Any request that does not match a {% url `cy.route()` route %} will be sent a `404` status code. | |||
| - Any request that does **NOT** match a {% url `cy.route()` route %} will {% url 'pass through to the server' network-requests#Don’t-Stub-Responses %}. | |||
There was a problem hiding this comment.
The meat of this PR:
- document the correct behaviour
- hyperlink to the relevant section of the Network Requests page to be helpful.
| @@ -53,7 +51,7 @@ Option | Default | Description | |||
| Option | Default | Description | |||
| --- | --- | --- | |||
| `enable` | `true` | pass `false` to disable existing route stubs | |||
| `force404` | `false` | forcibly send XHR's a 404 status when the XHR's do not match any existing | |||
| `force404` | `false` | forcibly send XHR's a 404 status when the XHR's do not match any existing route | |||
There was a problem hiding this comment.
I thought the sentence ended abruptly so I added a trailing route to make it read smoother.
richdouglasevans
changed the title
| 2. The `POST /messages` will match our 2nd route and respond with a `200` status code with the message object. | ||
| 3. The `GET /updates` did not match any routes and its response automatically sent back a `404` status code with an empty response body. | ||
| You can {% url 'read more about this behavior here.' server#Options %} | ||
| {% endnote %} |
There was a problem hiding this comment.
Right, so this is rather a large edit, possibly the largest I've made so far. Do steer me Jennifer.
I've removed this example in favour of a short block that directs the reader to the documentation about force404 on the server page. It's a good example but it essentially duplicates a much shorter example on the server page. I've attempted to preserve the thrust of this section while also directing the reader to the server page because the force404 option is applied at the level of the server rather than the route.
Yeah? 🤔
There was a problem hiding this comment.
This is fine and a good use of a 'note' as it is outside of the flow of the content.
|
|
||
| ```javascript | ||
| cy.server({force404: true}) | ||
| cy.server({ force404: true }) |
There was a problem hiding this comment.
Again, I'm directing the reader to the "canonical" documentation about the force404 option on the server page.
There was a problem hiding this comment.
I feel like we have lost the info about the headers being null - I haven't verified this is what truly does happen though, so I'm trusting that it was documented correctly to begin with. 😅
| @@ -103,9 +101,9 @@ Adding delay can help simulate real world network latency. Normally stubbed resp | |||
| cy.server({delay: 1500}) | |||
| ``` | |||
|
|
|||
| ***Prevent sending 404's to unmatched requests*** | |||
| ***Send 404s on unmatched requests*** | |||
There was a problem hiding this comment.
This header logic was the wrong way round: the force404 option doesn't prevent; rather, it enables the sending of a 404 on unmatched requests so I've changed the header to reflect that.
richdouglasevans
changed the title
richdouglasevans
changed the title
|
|
||
| ```javascript | ||
| cy.server({force404: true}) | ||
| cy.server({ force404: true }) |
There was a problem hiding this comment.
I feel like we have lost the info about the headers being null - I haven't verified this is what truly does happen though, so I'm trusting that it was documented correctly to begin with. 😅
| 2. The `POST /messages` will match our 2nd route and respond with a `200` status code with the message object. | ||
| 3. The `GET /updates` did not match any routes and its response automatically sent back a `404` status code with an empty response body. | ||
| You can {% url 'read more about this behavior here.' server#Options %} | ||
| {% endnote %} |
There was a problem hiding this comment.
This is fine and a good use of a 'note' as it is outside of the flow of the content.
| @@ -103,9 +101,9 @@ Adding delay can help simulate real world network latency. Normally stubbed resp | |||
| cy.server({delay: 1500}) | |||
| ``` | |||
|
|
|||
| ***Prevent sending 404's to unmatched requests*** | |||
| ***Send 404s on unmatched requests*** | |||
closes #564
I verified the behaviour locally: routes that are not matched will, by default, just pass through to the server.