Itâs time to get you started with a minimal Apollo Client in React application that can be used as boilerplate project. There will be sections later on where you can use this application as starter project, but also you may want to experiment with it on your own. After all, it gives you all the necessary parts to consume GitHubâs GraphQL API in your React application by using Apollo Client in a minimal starter project. In addition though, there will be some local state management with React only to show you that local state management for local data is still used when having Apollo Client for your remote data.
In the following case study application, you will consume GitHubâs GraphQL API to query a bunch of repositories from an organization. You have learned those steps before. Basically it is how your remote data is managed in Apollo Clientâs Cache. However, this time you will introduce local data along the way. Imagine a use case where you would have to select the queried repositories in a list to make a batch operation (e.g. mutation) on them. For instance, you maybe want to star 3 of the 10 repositories. Therefore, you would have to introduce local data to track the selected repositories which are managed in a local state. In the following you will implement this use case, first by using Reactâs local state but then transition to Apollo Link State as alternative.
It is up to you to create a React application with create-react-app . Afterward, you will have to setup Apollo Client in your React application as you have done in previous applications in the src/index.js file.
Donât forget to install the necessary packages for GraphQL, Apollo Client and React Apollo on the command line:
And furthermore, donât forget to add your personal access token from GitHub as value to the key in the .env file which you have to create in your project folder.
In the next step, implement the components to display the remote data which gets queried with React Apolloâs Query component eventually.
Once you run this application, you should see initially a loading indicator and afterward the list of repositories fetched from the defined GitHub organization in your GraphQL query. In addition, it could be possible to star a repository by executing a GraphQL mutation with the Mutation component.
Nevertheless, there are a couple of potential improvements that you can do as exercise already before continuing with the tutorial. For instance, there is only a star mutation but not a unstar mutation when the repository is already starred. Another thing could be a search field to pass in a dynamic login of an organization to be flexible in querying repositories from different organizations. All of these improvements are up to your implementation to internalize the learnings from previous applications which you have built while learning about GraphQL in React.
Another requirement for this application was it to be able to select (and unselect) repositories in the list of repositories for performing batch operations. Such a batch operation could be to star (and unstar) selected repositories. Before being able to execute such an operation, it must be possible to select the repositories from the list in the first place. Therefore, Reactâs local state management is the most straight forward choice for this problem to keep track of selected repositories. Each rendered repository row will have a button next to it. When clicking the button, the repositoryâs identifier will be stored in Reactâs local state. When clicking it again, the identifier will be removed again.
In order to keep the components lightweight and suited to their responsibilities (e.g. fetching data, rendering data), you can introduce a Repositories component which is used as container component in between of the App component and the RepositoryList component to manage local state.
The Repositories component in between manages the state of selected repositories by storing their identifiers in Reactâs local state. in the end, it renders the RepositoryList component which was rendered previously in the App component. After all, you only introduced a component in between which has the responsibility to manage local state (container component) while the RepositoryList component only needs to render data (presentational component).
Now implement the business logic of the class method in Repositories component which adds and removes (toggles) the identifier of a repository depending on its incoming selection state.
Since the list of selected repository identifiers and the class method to actually toggle a repository are passed to the RepositoryList component, you can implement a new Select component there to make use of those props.
The Select component is only a button which acts as toggle to select and unselect a repository.
The select interaction should work after starting your application. It is indicated by a toggling âSelectâ and âUnselectâ label after clicking the new button multiple times. But you can do better by adding some conditional styling to each row in the RepositoryList component.
Last but not least, you have to define the CSS classed which were used for the repository row in the src/App.css file:
Thatâs it for the selection feature implementation. You should be able to select and unselect repositories in your list when starting your application now.
Remember that this solution with Reactâs local state would already be sufficient to deal with this problem. No one else than the one component is interested in the selected repositories. So the state is co-located to the component. But following applications will show you how to replace Reactâs local state management with Apollo Link State or Redux which is used side by side with Apollo Client. The minimal boilerplate application can be found in this GitHub repository as boilerplate project .