Debug auto-derived implementation doesn't display queries correctly
Opened this issue · 10 comments
If you have a query saved in a graphql file on disk, it is likely to be correctly formatted and contain newlines
pub struct RepositoryWithPullRequests;
pub mod repository_with_pull_requests {
#![allow(dead_code)]
use std::result::Result;
pub const OPERATION_NAME: &str = "RepositoryWithPullRequests";
pub const QUERY: &str = "query RepositoryWithPullRequests(\n $repositoryName: String!\n $repositoryOwner: String!\n $count: Int!\n $pullRequestStates: [PullRequestState!]!\n) {\n repository(name: $repositoryName, owner: $repositoryOwner) {\n owner {\n __typename\n login\n }\n name\n defaultBranchRef {\n name\n }\n pullRequests(first: $count, states: $pullRequestStates) {\n pageInfo {\n hasNextPage\n endCursor\n }\n\n totalCount\n nodes {\n author {\n __typename\n login\n }\n id\n url\n title\n state\n createdAt\n updatedAt\n closedAt\n ## uh-oh not very safe but it's ok\n labels(first: 100) {\n edges {\n node {\n id\n name\n }\n }\n }\n }\n }\n }\n}\n";
const __QUERY_WORKAROUND: &str = "query RepositoryWithPullRequests(\n $repositoryName: String!\n $repositoryOwner: String!\n $count: Int!\n $pullRequestStates: [PullRequestState!]!\n) {\n repository(name: $repositoryName, owner: $repositoryOwner) {\n owner {\n __typename\n login\n }\n name\n defaultBranchRef {\n name\n }\n pullRequests(first: $count, states: $pullRequestStates) {\n pageInfo {\n hasNextPage\n endCursor\n }\n\n totalCount\n nodes {\n author {\n __typename\n login\n }\n id\n url\n title\n state\n createdAt\n updatedAt\n closedAt\n ## uh-oh not very safe but it\'s ok\n labels(first: 100) {\n edges {\n node {\n id\n name\n }\n }\n }\n }\n }\n }\n}\n";the problem with this is that the Debug macro auto-derive will escape newline, using the Debug format unusable
I'm not sure I understand. What is __QUERY_WORKAROUND in your example? The Debug impl for strings includes escaped newlines indeed, but that's a general thing, not graphql-client specific.
@tomhoule I think the problem is when the macro read from files, we need to use include! rather than reading the file and re-including it, because it will escape the \n
I don't see that as a problem, since that code isn't meant to be readable by humans. The reason why the full string is included, at the time when this was done, was because include_str!() would not always detect change and trigger recompilation, so you could be editing a query, but the compiler wouldn't pick up the changes. That might have changed, and in that case we should revisit.
As it is now, I don't think we should change the Debug impl — the query string in there can use the regular Debug impl for rust strings. If you need to print the strings with real newlines, the Display impl is the canonical way to do that and the field is public. (So something like format!("{}", query_body.query).
I think what I don't understand is the upsides of a custom Debug impl. People are familiar with the default output, and QueryBody is by design a very plain struct.
Imagine you have code like so:
let query = RepositoryWithPullRequests::build_query(variables);
debug!("Github GRAPHQL Query: {}", query);
debug!("Github GraphQL Query: {:#?}", DebugPrettyQuery(&query));the first line wouldn't work (no Display impl), the second line output would be unreadable. This is code from another service where I am wrapping the query into a custom Struct where I implement Debug correctly
The first line wouldn't work, but debug!("Github GRAPHQL Query: {}", query.query); would work, right?
Yes, one option is to have two debug statements
Since all fields are public, you could also have a wrapper around QueryBody for your own debug formatting, like:
struct QueryBodyCustomDebug(QueryBody);
impl Debug for QueryBodyCustomDebug {
// ...
}That's what I did. My suggestion is to have a "readable Debug implementation" out of the box, rather than having people to reimplement it themselves. What's the benefit of having an unreadable implementation? This can also be achieved by modifying the codegen macro
Could you add an example of the current debug output and your suggested output to make the discussion easier?