Remove deprecated `MockedRequest.body` and cleanup
See original GitHub issueScope
Improves an existing behavior
Compatibility
- This is a breaking change
Feature description
Remove deprecated MockedRequest.body
and cleanup after few releases with deprecation.
https://github.com/mswjs/msw/issues/1302#issuecomment-1173722395
Issue Analytics
- State:
- Created a year ago
- Comments:9 (4 by maintainers)
Top Results From Across the Web
Changelog — aiohttp 3.7.2 documentation
The run_app task needs to be cancelled first for cleanup hooks to run with all ... Modify documentation for Background Tasks to remove...
Read more >Cleaning After Dead Body Removal
When it comes to cleaning up after a body is removed, you need to be careful because there could be body fluids and...
Read more >BrowserTestBase.php | Drupal 8.2.x
BrowserTestBase::cleanupEnvironment, protected, function, Clean up the Simpletest ... AssertLegacyTrait::assertElementNotPresent Deprecated, protected ...
Read more >Mantis: vendor/guzzlehttp/guzzle/CHANGELOG.md
Deprecation : BadResponseException instantiation without a response #1642 ... This means that the Content-Encoding header may be removed an the ...
Read more >Getting request body of mock service worker and react ...
You should be able to get the req.body.email value given your request sets the Content-Type: application/json header.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
There’s some serious dark magic with generics sometimes. I believe we’re using a similar pattern right now, where we have a
res.json<T>()
signature but it gets inferred from the generic you give to the handlerrest.get<T>()
. I think we should keep JSON method annotated while hard-codingtext
andarrayBuffer
.Not sure how this will translate to the future
.formData()
to be honest. I’d expect it to act similar toURLSearchParams
and never be annotated explicitly.Hey Artem,
mmh, I think both is fair, when made clear.
I personally would prefer the option to type the
json()
as suggested, because I think when usingtext()
orarrayBuffer()
the return value is quite clear and completely ok to be hardcoded. Whereasjson()
could be any shape and is quite easy inferable…And you don’t have to use it, if someone likes to stick to a more explicit casting like
as Shape
(which I don’t prefer, because it always looks like; nah, I just cast it anyways…)Maybe a compromise could be something like:
So you put your generic directly and explicitely onto the
json()
-Method and not onto the complete mocked request… But maybe this is to close to the explicit casting.