feat: custom query key formatters
What kind of change does this PR introduce?
Feature and docs update.
What is the current behavior?
Query keys in the URL are formatted based on property names without any customization.
What is the new behavior?
Introduces the capability for users to define custom formatting strategies for query keys in the URL. This can be achieved by implementing the IUrlParameterKeyFormatter interface and setting it in RefitSettings. The default behavior remains unchanged (using property names as they are) to ensure backward compatibility. Also, the documentation has been updated to reflect these changes and guide users on how to utilize this feature.
What might this PR break? Care has been taken to ensure retro-compatibility. This PR should not introduce any breaking changes, as the default behavior remains consistent with previous versions.
Please check if the PR fulfills these requirements
- [x] Tests for the changes have been added (for bug fixes / features)
- [x] Docs have been added / updated (for bug fixes / features)
Other information:
- The
AliasAsattribute always takes precedence in key naming, regardless of any custom key formatters in use. - Enhanced documentation has been added to clarify the behavior of
IUrlParameterFormatterwhen dealing with dictionaries. - The current handling of dictionary formatting remains unchanged to ensure backward compatibility and prevent potential breaks for existing users.
- The decision to prioritize the
AliasAsattribute aligns with intuitive expectations and mirrors behaviors such asJsonPropertyNamein System.Text.Json. - Formatters are designed to be straightforward: they accept a string and return a formatted version without considering other attributes or extraneous factors.
Closes #1333 Closes #1541 Closes #1258
There are probably more issues regarding this matter.
Can this be looked into, or is the PR stale?
Can this be looked into, or is the PR stale?
I guess they're too busy
I was looking at this at the weekend, but I was away in Scotland, I working my way through the PR's to get them all dealt with appropriately. I will try to find time this weekend to go through this
Codecov Report
Attention: Patch coverage is 87.90698% with 26 lines in your changes missing coverage. Please review.
Project coverage is 86.19%. Comparing base (
6ebeda5) to head (51cc40b). Report is 29 commits behind head on main.
:exclamation: Current head 51cc40b differs from pull request most recent head 6913370
Please upload reports for the commit 6913370 to get more accurate results.
Additional details and impacted files
@@ Coverage Diff @@
## main #1570 +/- ##
==========================================
- Coverage 87.73% 86.19% -1.54%
==========================================
Files 33 34 +1
Lines 2348 2072 -276
Branches 294 297 +3
==========================================
- Hits 2060 1786 -274
+ Misses 208 206 -2
Partials 80 80
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@tcortega Please could you recheck the code you have added after the merge to be sure it still covers the same intended update
@tcortega Please could you recheck the code you have added after the merge to be sure it still covers the same intended update
I'll check it either later tonight or tomorrow
@ChrisPulman From my end, based on my changes, this is pretty much what I can do testing-wise.
It looks like your unintentionally reverted #1619 when merging to the main branch, do you want me to fix this?
@TimothyMakkison yes please
@TimothyMakkison Trying to check everything as best as possible after the merges and updates to ensure all is still intact ready for a release, thank you for spotting this.
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.