Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/lucasconstantino/react-apollo-defragment
:cd: Automatic query defragmentation based on React trees.
https://github.com/lucasconstantino/react-apollo-defragment
apollo fragments graphql react react-apollo
Last synced: about 1 month ago
JSON representation
:cd: Automatic query defragmentation based on React trees.
- Host: GitHub
- URL: https://github.com/lucasconstantino/react-apollo-defragment
- Owner: lucasconstantino
- License: mit
- Created: 2018-03-19T00:20:26.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2019-04-16T16:52:32.000Z (over 5 years ago)
- Last Synced: 2024-09-15T04:38:51.268Z (2 months ago)
- Topics: apollo, fragments, graphql, react, react-apollo
- Language: JavaScript
- Homepage:
- Size: 396 KB
- Stars: 12
- Watchers: 4
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# React Apollo Defragment
Automatic query defragmentation based on React trees.
[](https://travis-ci.org/lucasconstantino/react-apollo-defragment)
:warning: **This is experimental software**, and though there are plenty of unit tests you should probably avoid using on production code
## Installation
```
npm install react-apollo-defragment
```
> react-apollo-defragment has peer dependency on [react](https://github.com/facebook/react), [react-apollo](https://github.com/apollographql/react-apollo), [graphql](https://github.com/graphql/graphql-js), and [prop-types](https://github.com/facebook/prop-types). Make sure to have them installed.
## Motivation
When [using fragments](https://www.apollographql.com/docs/react/features/fragments.html) one thing that bothers me is that we lose some of the decoupling between child and parent components. When the fragment is used by a first-level child using fragment as we currently do is not a big problem; you are already declaring the use of the child component via importing it on the parent, after all. But when the fragment is used way below down the tree, it just becomes odd to have the querying component have so much logic on what fragments exactly - and many times sub-fragments - must be in use.
There was already some [discussion on fragment composition](https://github.com/apollographql/react-apollo/issues/140), but the proposals did not went forward.
What I needed was some way to decouple my components once more, and avoid having to define too many inner-queries to solve something that GraphQL should be used for: walking through a graph.
## How does it work
This project exposes a substitute [Query component](https://github.com/apollographql/react-apollo/releases/tag/v2.1.0-beta.0) which traverses the underlying React element tree to find the fragments in use in the query. The components must expose fragments on the static property `fragment` for this to work.
## Usage
The usage is the same as with react-apollo's `Query` component, only in this case no fragments must be imported and declared from the component:
```js
import { Query } from 'react-apollo-defragment'
import gql from 'graphql-tag'
// PersonAvatar.js: a component using fragments.
const PersonAvatar = ({ photo, name }) => (
{ name }
)
PersonAvatar.fragment = gql`
fragment Avatar on Person {
name
photo
}
`
// People.js: a component querying people and displaying avatars.
const query = gql`
query People {
people {
id
...Avatar
}
}
`
const People = () => (
{ ({ loading, data: { people } }) => (
!loading && (
{ people.map(person => (
)) }
)
) }
)
```
## This package should be temporary
I believe something similar to what is accomplished by this package should be soon implemented on the [React Apollo](https://github.com/apollographql/react-apollo) core. If someday that happens, this package will either be deprecated or hold other experimental functionality on the subject of GraphQL fragments with Apollo and React.