Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document that filters::query::query uses serde_urlencoded, and add example for postprocessing filters::query::raw #687

Closed
wants to merge 2 commits into from

Conversation

jcaesar
Copy link

@jcaesar jcaesar commented Aug 8, 2020

serde_urlencoded is used for to deserialize query strings, and hence not all structs that are Deserialize can be deserialized to. I think it would be neat to document that fact and also added an example that shows how to use a different deserialization function instead.

(I didn't want to add serde_qs as a dev-dependency just for this, so I fudged it.)

What do you think?

@seanmonstar
Copy link
Owner

Yes this is a great idea, thanks! I wonder, what if instead of "promising" to use serde_urlencoded, we just say that currently the decoder strictly follows the URL spec, and so cannot decode lists etc.

@jcaesar
Copy link
Author

jcaesar commented Aug 9, 2020

currently the decoder strictly follows the URL spec

Hm, I'll rephrase it like that. But I do wonder whether it's accurate, or at least helpful.
On the one hand side, the URL spec allows duplicated keys (okay, it'd be odd to expect that to work with rust structs structs), on the other hand side, serde_urlencoded supports tagged/untagged enums, which I had not expected to work at all (but only if all values are String).
Then again, mentioning serde_urlencoded does not help that much, since these things aren't documented.

@jcaesar
Copy link
Author

jcaesar commented Aug 9, 2020

Maybe explicitly stating what can be decoded into is a good idea?

@jxs
Copy link
Collaborator

jxs commented Jun 5, 2021

sorry! missed this one and this has since been addressed by #843

@jxs jxs closed this Jun 5, 2021
@jcaesar
Copy link
Author

jcaesar commented Jun 6, 2021

I don't see how #843 documents what limitations the limitations of query parameter deserialization. I wouldn't consider this addressed. But I do feel like I'm being pedantic. In the off-case that you want me to renovate this PR, please do tell.

@jxs
Copy link
Collaborator

jxs commented Jun 7, 2021

Oh sorry! And no, not pedantic at all, if you want to rebase your PR against master and add the limitations of parameter deserialization that would be great!

@jxs jxs reopened this Jun 7, 2021
@jxs jxs added the waiting-on-author awaiting some action (such as code changes) from the PR or issue author. label Jun 10, 2021
@jcaesar
Copy link
Author

jcaesar commented Aug 25, 2021

I've rebased on master and reworded it so the documentation doesn't leak any implementation details.

Copy link
Collaborator

@jxs jxs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM thanks! Out of curiosity, what does Pars mean in this context?

@jcaesar
Copy link
Author

jcaesar commented Sep 3, 2021

Ah, if you're asking, I should probably spell it out. Parameters. But I'll change it to FooQuery to match the other example.

@jcaesar
Copy link
Author

jcaesar commented Jul 9, 2024

Please notify me if you're still interested in this. I'll renovate it if so.

@jcaesar jcaesar closed this Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting-on-author awaiting some action (such as code changes) from the PR or issue author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants