starred/gql-query-builder
1
0
Fork 0
mirror of https://github.com/atulmy/gql-query-builder.git synced 2026-04-25 23:55:55 +03:00
Code Issues 36 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #18] Fragments #10

New issue
Closed
opened 2026-03-03 00:02:43 +03:00 by kerem · 7 comments
kerem commented 2026-03-03 00:02:43 +03:00
Owner
Copy link

Originally created by @iYaroslav on GitHub (Aug 5, 2019).
Original GitHub issue: https://github.com/atulmy/gql-query-builder/issues/18

Can I use fragments?

https://graphql.org/learn/queries/#fragments

Originally created by @iYaroslav on GitHub (Aug 5, 2019). Original GitHub issue: https://github.com/atulmy/gql-query-builder/issues/18 Can I use fragments? https://graphql.org/learn/queries/#fragments
kerem 2026-03-03 00:02:43 +03:00
kerem commented 2026-03-03 00:02:44 +03:00
Author
Owner
Copy link

@atulmy commented on GitHub (Aug 6, 2019):

At the moment it's not supported. If you think you can spare time to contribute, feel free to go ahead and send a pull request!

<!-- gh-comment-id:518497241 --> @atulmy commented on GitHub (Aug 6, 2019): At the moment it's not supported. If you think you can spare time to contribute, feel free to go ahead and send a pull request!
kerem commented 2026-03-03 00:02:44 +03:00
Author
Owner
Copy link

@toadkicker commented on GitHub (Aug 9, 2019):

The adapter is basically a bunch of fragments of template being assembled together. I don't see why one couldn't just write it such:

const adapterInstance = new CustomAdapter({withFragments: ['fnName', 'fnName2']})
query(options, adapterInstance)

Then in the adapter class can just check if fnName exists, and call it when appropriate it.

Just my quick thought/hack about it.

<!-- gh-comment-id:520074088 --> @toadkicker commented on GitHub (Aug 9, 2019): The adapter is basically a bunch of fragments of template being assembled together. I don't see why one couldn't just write it such: ``` const adapterInstance = new CustomAdapter({withFragments: ['fnName', 'fnName2']}) query(options, adapterInstance) ``` Then in the adapter class can just check if `fnName` exists, and call it when appropriate it. Just my quick thought/hack about it.
kerem commented 2026-03-03 00:02:44 +03:00
Author
Owner
Copy link

@atulmy commented on GitHub (Aug 14, 2019):

@iYaroslav you can follow @toadkicker's example until we bake in Fragments out of the box.

<!-- gh-comment-id:521089408 --> @atulmy commented on GitHub (Aug 14, 2019): @iYaroslav you can follow @toadkicker's example until we bake in `Fragments` out of the box.
kerem commented 2026-03-03 00:02:44 +03:00
Author
Owner
Copy link

@toadkicker commented on GitHub (Aug 14, 2019):

I think to do that it would be helpful to have a bit of a formalized life cycle for an adapter that includes a better look at features like fragment injection.

<!-- gh-comment-id:521089825 --> @toadkicker commented on GitHub (Aug 14, 2019): I think to do that it would be helpful to have a bit of a formalized life cycle for an adapter that includes a better look at features like fragment injection.
kerem commented 2026-03-03 00:02:44 +03:00
Author
Owner
Copy link

@max-yilang commented on GitHub (Aug 19, 2019):

I would love to have this feature as well

<!-- gh-comment-id:522410514 --> @max-yilang commented on GitHub (Aug 19, 2019): I would love to have this feature as well
kerem commented 2026-03-03 00:02:44 +03:00
Author
Owner
Copy link

@ARHariri commented on GitHub (Apr 2, 2020):

I don't see the purpose of using Adapter (especially to handle fragment). When a user defines and passes an adapter as the second argument, he should write all logic of generating query instead of specifying his especial logic that should be replaced some parts of the default code, because of instantiating from user-defined adapter class and then pass the controller to that instance to handle all flow of generating a query.
I think defining and using an adapter equals defining a new package to generate a GraphQL query.
So it seems using an adapter is not useful unless fixing adapter usage with one of the two following approaches:
1- Use method overriding approach of OOP (It seems the intention of using an adapter is this, but as DefaultQueryAdapter is not exposed, user should implement adapter from scratch)
2- Accept function (or a config) as an adapter instead of class. In this way 1) highly recommended to follow the functional programming approach instead of OOP in the codebase and 2) get a config (instead of function) that defines logic to generate a query based on the passed options.

<!-- gh-comment-id:607719926 --> @ARHariri commented on GitHub (Apr 2, 2020): I don't see the purpose of using `Adapter` (especially to handle fragment). When a user defines and passes an adapter as the second argument, he should write all logic of generating query instead of specifying his especial logic that should be replaced some parts of the default code, because of instantiating from user-defined adapter class and then pass the controller to that instance to handle all flow of generating a query. I think defining and using an adapter equals defining a new package to generate a GraphQL query. So it seems using an adapter is not useful unless fixing adapter usage with one of the two following approaches: 1- Use `method overriding` approach of OOP (It seems the intention of using an adapter is this, but as `DefaultQueryAdapter` is not exposed, user should implement adapter from scratch) 2- Accept function (or a config) as an adapter instead of class. In this way 1) highly recommended to follow the functional programming approach instead of OOP in the codebase and 2) get a config (instead of function) that defines logic to generate a query based on the passed options.
kerem commented 2026-03-03 00:02:44 +03:00
Author
Owner
Copy link

@IAmNatch commented on GitHub (Nov 26, 2020):

For Inline Fragments I found I was able to create the necessary queries by using dynamic object keys.

For example to generate the following query:

{
  page {
    id
    ... on HomePage {
      content {
        blockType
      }
    }
  }
}

I wrote the following query:

const query = gql.query({
  operation: "page",
  fields: [
    "id",
    {
      "... on HomePage": [{
        content: [
          "blockType"
        ]
      }],
    }
  ]
});

This was great news for me. Thanks for building this awesome utility!

<!-- gh-comment-id:734001479 --> @IAmNatch commented on GitHub (Nov 26, 2020): For **[Inline Fragments](https://graphql.org/learn/queries/#inline-fragments)** I found I was able to create the necessary queries by using dynamic object keys. For example to generate the following query: ``` { page { id ... on HomePage { content { blockType } } } } ``` I wrote the following query: ``` const query = gql.query({ operation: "page", fields: [ "id", { "... on HomePage": [{ content: [ "blockType" ] }], } ] }); ``` This was great news for me. Thanks for building this awesome utility!
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
3.8.0
3.7.2
3.7.1
3.7.0
3.6.0
3.5.9
3.5.7
3.5.5
3.5.4
3.5.1
3.5.0
v3.4.1
v3.4.0
3.3.0
3.2.0
3.1.1
3.1.0
3.0.7
3.0.2
2.0.2
Labels
Clear labels   
bug

   
enhancement

   
enhancement

   
good first issue

   
help wanted

   
pull-request

Mirrored from GitHub Pull Request

  
question
No labels
bug
enhancement
enhancement
good first issue
help wanted
pull-request
question
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/gql-query-builder#10
No description provided.