Generate async request executor type for #[derive(WpDerivedRequest)]
#153
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.
Following up on #149 & #151, this PR adds request async request executor generation to
#[derive(WpDerivedRequest)]
.This type uses the the request builder added in #151 and a request executor to make the requests and then parse it. The return type is figured out from the given
output
type. Forpost
&delete
requests, the return type is the same as the givenoutput
type. Forcontextual_get
requests, the type is calculated by replacingSparse
prefix with the{}With{}Context
format, except for filter functions.The PR removes the
RequestType::Get
and theget
attribute fromWpDerivedRequest
. We currently don't have any non-contextual get requests and I think it's unlikely that we'll have any - at least for the foreseeable future. Since we don't exactly know what those requests look like, it's risky to implement it with just our assumptions. I figured removing it until we at least have one regularget
request was the safer choice.Known issues: #152, #154
Due to #154, I've decided to disable generating
filter
functions forpost
&delete
requests in 75d0814. This is not a functionality we currently have intrunk
and even if the issue is tracked, I think it might be risky to produce incorrect code. We can easily re-enable it once we work out how to handle the issue, but at least #154 won't be an urgent issue anymore considering it's very low impact.To Test
make test-server && make dump-mysql && make backup-wp-content-plugins
cargo test --test '*' -- --test-threads 1
Here is an example usage and its generated code: