feat: add ability to execute raw (untyped) requests #3
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #3 +/- ##
==========================================
- Coverage 29.72% 28.36% -1.37%
==========================================
Files 9 9
Lines 656 691 +35
==========================================
+ Hits 195 196 +1
- Misses 461 495 +34
☔ View full report in Codecov by Sentry. |
| /// A raw body. Allows for nullable untyped data that is passed directly | ||
| /// to `data` of the request, useful for instances where the data type | ||
| /// is not known until runtime. |
There was a problem hiding this comment.
May be worth noting how data will be treated? As in, do we just call toString() on it and send it as the body? Does it have to conform to something that can be .toJsoned?
There was a problem hiding this comment.
Does:
nullable untyped data that is passed directly to
dataof the request
not help?
Dios data is untyped (Object?) so the type here can be left as is.
There was a problem hiding this comment.
perhaps related to Will's line of questioning: does the usage of the .json constructor here result in setting the content-type header to application/json whereas this type will result in not setting the header? the reason i ask is because technically if we're sending json we are supposed to set that header and if we're sending something else we should set the corresponding header for that data type (form-url-encoded, mutlipart, application/xml, whatever)
There was a problem hiding this comment.
We don't do any of that (mainly because Dio does it for you). It may have been that I originally planned to, but then learned Dio did it (hard to recall now). If we don't feel there's a big enough value-add from the type safety/readability offered by these (I don't imagine consumers are passing NetworkRequestBodys around, so type safety is maybe not a huge deal here), we could nix the type entirely and just allow Object? 🤷♂️
There was a problem hiding this comment.
nah, i like having the type safety for specifying the interface. I wouldn't won't to accept Object? where a more constrained type would be better
There was a problem hiding this comment.
Worth calling out that we actually remove the implied content type interceptor by default, so consumers of sturdy need to do this themselves. I should probably add documentation on the NetworkRequestBody type at the very least indicating that this doesn't dictate content type deduction.
There was a problem hiding this comment.
Follow-up PR here: #4
|
/no-platform |
📰 Summary of changes
This PR adds
RawRequestas a subclass ofNetworkRequestwhich is a convenience for creating requests whose methods are not known until runtime. This is the case forRetryInterceptorin thetest_track_dart_client(see PR here). Rather than switching on the method of the failed request and creating a request-per-type (where all params other than themethodare identical),RawRequestallows us to pass the type in as a parameter. Very open to other implementations!🧪 Testing done
Since the underlying data passed to the request type is pre-existing, I didn't add any tests and I think the existing
SturdyHttptests are sufficient.