-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
GraphQL: Renaming Types/Inputs #5883
Conversation
@davimacedo I found that the |
Codecov Report
@@ Coverage Diff @@
## master #5883 +/- ##
==========================================
- Coverage 93.67% 93.67% -0.01%
==========================================
Files 153 156 +3
Lines 10801 10862 +61
==========================================
+ Hits 10118 10175 +57
- Misses 683 687 +4
Continue to review full report at Codecov.
|
@davimacedo i just need help on the last failing test, if you have an idea: |
@Moumouls I fixed the failing test for you: 9d2e769
Agree
Do not agree. What makes Parse Server really special is the existence of the Parse Dashboard and the SDKs that can be used in combination with the GraphQL API, for example for creating cloud code functions. In the case of the |
Thanks @davimacedo for the tests, I'm fixing the tests on renaming |
PR Summary
|
CI Build seems to crash on a |
@@ -0,0 +1,39 @@ | |||
import logger from '../../logger'; | |||
|
|||
const parseMap = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will still have a problem if I create a class called FileWhereInput for example. I know it is weird, but maybe it would be better to create a method in ParseGraphQLSchema prototype called push type that would check if the type was pushed before, it will add the type name to a list and push type to the this.graphQLTypes. Then we could replace all parseGraphQLSchema.graphQLTypes.push() to a call to this new function. If you want, I can help you on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it can't collide with FileWhereInput
it is an input, in normal implementation GraphQL
can make the difference between an input
and a type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was actually a bad example, but a class called FileInfo
would be a problem. Or a class called Query
for example. There is also the problem we talked before of creating the class Car
and the class Cars
. We'd need to create a similar logic that I proposed above also for fields that are pushed to the queries and mutations types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Moumouls sorry for the delay. I had a hard time in the last few days but I should be able start to reviewing faster now. I've just sent some comments of what I think we can improve. We can even leave it to be improved later, if you prefer.
@Moumouls let me know your thoughts and if you need any help here. |
@davimacedo yes i think an help on your suggestions could be productive, is it possible to push a commit with the base of the logic that you suggest ? I could take over later |
@Moumouls I've just added some commits to the PR, basically I:
Please let me know your feedback. |
It seems that we are also missing some tests too, on |
Yes... we need to include more tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Moumouls It looks good to me. Can you please also take a look an leave your feedback? @douglasmuraoka and @omairvaiyani , since I've also done a lot of commits, I think it would be good at least one of you guys to also take a look.
Everything seems good to me, I'm just worried about the I think it's another PR but the new For a next PR after Schema CRUD will be implementedThinking about, actually enum ClassNameEnum {
Role
User
SomeClass
Customer
...
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huge changes incoming! 🚀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job!
@Moumouls first of all, I'd like to explain what is the use case I imagined when designing the generic operations. I wanted to keep in the GraphQL API the same feature of the REST API in which Parse is schemaless, which means that you don't need to create the schema beforehand. You just need to send the data and the schema will be automatically created. These operations are not intended to be used in production but they are very helpful when starting the development of a new app. You don't even need the Parse Dashboard for creating a new app. You can use the GraphQL Playground alone to start sending data and creating your schema. Therefore, the enum is not a good idea and I think that Later I think we could also include in the GraphQL configuration options the ability of enabling, disabling each of the generic operations. Actually I'd like to be able to enable/disable any of default operations, including the file's, user's, etc. Thoughts? Talking about the nested mutations and queries, I particularly like the organization we currently have, but, yes, we can remove them now that we have name management system. Removing them is probably more natural for GraphQL users. I am actually not sure what is better. @Moumouls @omairvaiyani @douglasmuraoka what's your opinion on this? Should we keep the nested operations or remove them? I think we should define this as soon as possible to be implemented before the next release. |
You already know my point of view about to unwrap |
Ok. It's done :) |
* Renaming GraphQL Types/Inputs * Add Native Type to avoid collision * Use pluralize for renaming * Fixing tests * Improve name collision management - tests passsing * Renaming few more default types * Rename file input * Reverting fields types to not collide with the relay spec types Improver users mutations * Adding ArrayResult to the reserved list * Fixing tests * Add more unit tests to ParseGraphQLSchema * Test transformClassNameToGraphQL * Name collision tests
Draft
I moved all
transforming
stuff in a dedicatedfolder
#5863