trivial: fix next_page/nextPage confusion in paginated MSW util
#2987
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Just clearing out an old to-do list item. We were incorrectly using
nextPageinstead ofnext_pagein the pagination helper. TypeScript allowed this becausenext_pageis optional and TypeScript can't prevent you from adding extra keys (nextPage) that aren't in the specified return type. This didn't cause any problems because on the client side, thenext_pageis converted tonextPageanyway. So we were just putting the "right" key in there to begin with and it was being left alone by the camel-casing logic. I explored finding ways to enforce an exact type which would disallow unexpected keys in API responses, but TypeScript makes this really tough (see microsoft/TypeScript#12936).