Generate endpoint type for #[derive(WpDerivedRequest)]
#149
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.
Implements endpoint type generation for
#[derive(WpDerivedRequest)]
. This will replace theFooEndpoint
types, such as theUsersEndpoint
one here.I've added
UsersRequest
type that uses this derive macro, but I've done it inside a temporarygenerated mod
so that it doesn't interfere with the current implementation. This also allows easily expanding the derived macro for inspection. I've left instructions on how to do that as a line comment.This endpoint type works almost the same way as the current hand written one does with the following changes:
list(context: WpContext)
becomeslist_with_edit_context
,list_with_embed_context
&list_with_view_context
. This is how the current request builders work as we have to be able to return a type specific to the given context. These functions will not be called directly - except by unit tests - so it doesn't matter too much which setup we select. Since this is simpler to implement/maintain and also consistent with the request builder functions, I think it's the clear winner.filter_list
&filter_retrieve
before, but now that it's being generated, it makes sense to generate all of them._fields
query pair is now added inline, instead of calling theappend_filter_fields
fromUrlExtension
as there is no reason to have an external function for this anymore.ApiBaseUrl.by_extending
, we now useApiBaseUrl.by_extending_and_splitting_by_forward_slash
. If we have the"foo/bar"
as a segment, we used to add it directly which meant the/
character would be encoded - which in my opinion is the correct behaviour. However,/plugins
endpoint requires the/
character to be preserved, so we had a custom logic for that just for plugins. Now that logic is being used for all endpoints - which at the moment is onlyusers
&plugins
. I don't like this setup at all, but at the same time, this is a minor issue and I don't want to shift my focus away from the derive macro to address this. So, I think this is good enough for now.The code generation is split into many small parts and those small parts are unit tested. There are some intermediate steps, such as generating a function signature that are also unit tested. However, anything bigger is not unit tested. Those bigger parts only combine tested smaller units, so it should be a safe setup. We'll also still have unit tests like the ones in
users_endpoint::tests
module. We also cover the parser with integration tests and usage of generated code with integration tests, so I am pretty happy with the test coverage.Here is an example usage and its generated code: