feat(biome_graphql_parser): parse schema definition #2557
Conversation
CodSpeed Performance ReportMerging #2557 will not alter performanceComparing Summary
|
| } | ||
|
|
||
| fn is_at_list_end(&self, p: &mut Self::Parser<'_>) -> bool { | ||
| is_at_root_operation_type_definition_end(p) |
There was a problem hiding this comment.
Could you please help me to understand why we need here is_at_root_operation_type_definition_end?
What cases do we cover? Is it possible to check only p.at(T!['}'])?
There was a problem hiding this comment.
Consider this case:
schema {
query: MyQueryRootType
mutation: MyMutationRootType
schema {
query: Query
}If we only check for p.at(T!['}']) the second schema definition is also included in RootOperationType, so I included another check to see if we are at the start of other definition or not.
There was a problem hiding this comment.
Do you think this is a good idea?
There was a problem hiding this comment.
I believe it's a great idea.
I'm wondering if it's possible to have a 'complex' check when we get an Absent result from the parse_element function.
Specifically, it would be beneficial to maintain p.at(T!['}']) the happy path, avoiding additional checks which are required for the failure path.
I don't have any work solution for now, we might think about it in the next MR.
|
|
||
| #[inline] | ||
| fn parse_root_operation_type_definition(p: &mut GraphqlParser) -> ParsedSyntax { | ||
| if !(p.at_ts(OPERATION_TYPE) || p.at(T![:]) || p.lookahead_at(T![:])) { |
There was a problem hiding this comment.
I believe we can extract p.at_ts(OPERATION_TYPE) || p.at(T![:]) || p.lookahead_at(T![:]) as a is_at_root_operation_type_definition function and reuse it in the RootOperationTypeDefinitionListRecovery.
3db791d to
00dc3b2
Compare
00dc3b2 to
42c0b7f
Compare
Summary
Parse GraphQL schema definition. This is a small case so I parse both the happy path and error path in this PR
Test Plan
All tests should pass