-
-
Notifications
You must be signed in to change notification settings - Fork 319
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
Refactor/transform queries features #745
Comments
Hey, This would need more details. What is the use case? How would you propose the feature works? |
I'm working on a very complex API that has large number of types and large number of fields in each type. (BTW, that's why I opened #690.) The API is auto-generated. Currently I'm working on refactoring queries in my app, and I do the same actions over and over again by hand.
Suppose there is the following query: query getUsers {
users {
id
firstName
lastName
username
phone
email
github
twitter
}
} The user selects the query getUsers {
users {
id
firstName
lastName
username
...fragment1
}
}
fragment fragment1 on User {
phone
email
github
twitter
}
Suppose there is the following query: query getPosts {
posts(
where: {
OR: [
{
AND: [
{ title_in: ["My biggest Adventure", "My latest Hobbies"] }
{ published: true }
]
}
{ id: "cixnen24p33lo0143bexvr52n" }
]
}
) {
id
title
published
}
} The user puts the mouse cursor on the input argument Query: query getPosts($where: PostWhereInput) {
posts(where: $where) {
id
title
}
} Variables: {
"where": {
"OR": [{
"AND": [{
"title_in": ["My biggest Adventure", "My latest Hobbies"]
}]
},
{
"id": "cixnen24p33lo0143bexvr52n"
}
]
}
} |
Why I extract fields to fragments? In my real case, the queries are a bit more complicated, and the fragments are reusable: query getUsers {
admins: users(role: admin) {
id
firstName
lastName
username
phone
email
github
twitter
}
accountants: users(role: accountant) {
id
firstName
lastName
username
phone
email
github
twitter
}
} query getUsers {
admins: users(role: admin) {
...userFields
}
accountants: users(role: accountant) {
...userFields
}
}
fragment userFields on User {
id
firstName
lastName
username
phone
email
github
twitter
} Why I extract input fields to variables? Because I need to not just change the values in the input, but dynamically change the shape of the query input using nested logical combinators |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@imolorhe Is it really |
No it's not 😄 |
Also it's sometimes useful to do the opposite:
The first (as well as remove duplicated fields feature that is also very useful) is already implemented in graphql-prettier package by @Emetrop. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I think we can implement this in the LSP so it works in monaco/vscode/etc, but Altair will need to migrate from codemirror-graphql to the forthcoming monaco mode to use that. |
That would be a major migration but would be worth looking into once the monaco mode is completed. |
Yeah its unfortunate we have to make such a jump, but after I showed the preview some of the main contributors to the original codemirror mode see how this would reduce tons of redundant code, and allow us to have closer parity with the official LSP standard, potentially being able to roll out features across the ecosystem (including vscode, atom, etc) with a fraction of the code Here's a quick preview, only query pane working now with completions, diagnostics, hovers. We will add declarations very soon and eventually symbol support: As you can see, its set up for my development of the variables editor, so if you just add the variable you'll see all the query editor features. Here's the branch for it, where i add the monaco-graphql package and a monaco test under |
Just went through the monaco-graphql mode and the example. Looking good so far. If I understand correctly, the LSP standard you are referring to is a standardised interface accepted by most IDEs and development environments, and is different from the interface used by codemirror, hence implementing the LSP interface has a better impact in terms of possible integration with more environments? |
Also you mentioned that declarations and symbol support are missing. What are you referring to by those? |
And after a bit of googling around, I found what I was looking for 🙂https://microsoft.github.io/language-server-protocol/
|
yup thats it! my bad, running errands all day, trying to make sure i can overcome this illness our entry for the official LSP site needs updated, but thats a great start to understanding it the monaco team says monaco-graphql is looking pretty good, just need to support webworkers and declarations, variables and it should be mostly ready. we will want to sprinkle in some more features for parity with the codemirror mode. so far, I find many of these features to be much easier to implement in monaco, or already present with a very simple implementation. my goal is to instantiate the full Then, by insantiating that class everywhere, we can add to it a plugin capability that can work universally across vscode server/browser/vscode client/atom. Typescript LS's plugin system and the json language service (pluggable schema loading), monaco-typescript and monaco-json provide nice prior art for this planned architecture |
https:/cypress-io/cypress-example-recipes/tree/master/examples/blogs__a11y
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Please reopen this issue. |
This will be blocked for now until the implementation on the LSP level, unless there's time available to implement it on Altair itself. |
ah! i understand this a lot better now that i’ve reread it @FluorescentHallucinogen. very useful. can see how we could accomplish this with monaco in a vscode style. If you all want to make it work with codemirror first here in altair be my guest! for us to implement this in the LSP (probably in the new monaco mode) it might take a little bit for us to get there |
I'm going to attempt to implement this feature. However the implementation I would be doing would attempt to refactor the entire query, without selective refactoring. What that means is this:
|
It would be nice to have the following query refactoring features:
The text was updated successfully, but these errors were encountered: