feat: whenMatch - for more advanced matching needs
#23
Conversation
sometimes, you want to define your own matching logic and now you can. if you just want to match when a certain request parameter is present or if the http method is GET and the first letter of the path is "z". who knows what you'll need? the sky is now the limit. breaking change: removed CharlatanHttpRequest#pathParameters. it is no longer possible to support this attribute of the request type because the request is provided in the matching phase when we don't know what the path template is and whether its a match yet.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #23 +/- ##
==========================================
+ Coverage 95.34% 95.91% +0.56%
==========================================
Files 4 4
Lines 86 98 +12
==========================================
+ Hits 82 94 +12
Misses 4 4
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
| ), | ||
| ); | ||
| } | ||
|
|
There was a problem hiding this comment.
for some more understanding of where this is valuable...
now we can support matching against graphql API calls like this:
c.whenMatch(
(r) => r.path == '/api/graphql' && r.body.asJson['queryName'] == 'GetUserQuery',
(r) => {'name': 'bilbo'}, // but obviously in the shape of GQL responses
);which we can then wrap in some helpers to look more like this:
c.whenMatch(
requestMatchesGqlQuery('GetUserQuery'),
requestGqlResponse({'name': 'bilbo'}),
);
| @@ -75,62 +117,33 @@ class Charlatan { | |||
| CharlatanResponseBuilder responseBuilder, { | |||
| int statusCode = 200, | |||
There was a problem hiding this comment.
I think we could make a breaking change to make things more typesafe
whenDelete(
'/users',
charlatanResponseWith({'id': 123}, status: 200),
);where charlatanResponseWith returns a CharlatanResponseBuilder that produces a json response with a 200 status code. then if you wanna do something fancier, you drop down to defining your own builder but we change it to require the builder to return a CharlatanHttpResponse instead of Object?. as a reminder, the reason it expects Object? right now is to support returning just a Map from the builder in the normal case where you want a 200 with a json body.
There was a problem hiding this comment.
this is definitely not a do it in this PR thing, but it might be a nice thing to consider as a better solution to the default status code and short-hand response builder definition.
| test('it provides the path parameters to the response builder', () async { | ||
| charlatan.whenGet( | ||
| '/users/{id}/{other}', | ||
| (request) => {'pathParameters': request.pathParameters}, |
There was a problem hiding this comment.
If we really want to keep this functionality, I think it's possible. It's just more effort than I wanted to invest here. I think the approach I'd take is to create a subclass of the CharlatanHttpRequest type that can be enhanced with the matched CharlatanResponseDefinition and it can use the underlying dio request and the definition to extract the path parameters. I started to implement that and got hung up on... something... that I can't remember.
I thought this was a cute feature when I added it originally, and I still really like it, but I didn't want to work out the kinks of making it continue to work. Open to someone tackling it though if we can find a clean solution. I just don't want to carry around a gnarly implementation for a feature that I'm not sure folks are clamoring for.
There was a problem hiding this comment.
Since we likely are one of the heaviest users of Charlatan and have zero usages of that API (that I can find at least), I'd agree let's not force it now. If it ends up being missed, we can investigate supporting it again in a future version and folks that really need it can wait for that version.
| test('it provides the path parameters to the response builder', () async { | ||
| charlatan.whenGet( | ||
| '/users/{id}/{other}', | ||
| (request) => {'pathParameters': request.pathParameters}, |
There was a problem hiding this comment.
Since we likely are one of the heaviest users of Charlatan and have zero usages of that API (that I can find at least), I'd agree let's not force it now. If it ends up being missed, we can investigate supporting it again in a future version and folks that really need it can wait for that version.
📰 Summary of changes
sometimes, you want to define your own matching logic and now you can. if you just want to match when a certain request parameter is present or if the http method is GET and the first letter of the path is "z". who knows what you'll need? the sky is now the limit.
breaking change: removed CharlatanHttpRequest#pathParameters. it is no longer possible to support this attribute of the request type because the request is provided in the matching phase when we don't know what the path template is and whether its a match yet.
🧪 Testing done
Updated the test suite according to the changes, but existing tests all pass!