I want to touch on how to set up
apollo-link-state to allow for support of multiple stores without interfering with one another.
In my last post we went over how to setup
apollo-link-state for basic use:
Special thanks to Peggy Rayzis for all the awesome work and communication that has been going out around this product.medium.com
Now in this tutorial this is the moon we’re shooting for:
withClientStateto its own file.
- Moving specific resolvers and mutations to their own files.
- Writting an elegant way to merge together multiple stores.
- Adding a new Notes feature to the previous demo.
Lets Dive in! 🚀🌙
My biggest problem when using
To kick this off I want to talk about the problem we are trying to solve.
It boils down to that
CreateClientState expects only one value for
defaults and one value for
Mutations.resolvers which is incompatible if you have more than 1 object you want to store.
It’s incompatible because it forces us to keep the
defaults for multiple logically separate features in one place. OR if forces us to explicitly reference a
default from a separate file every time we create one.
This is bad and in a medium to large app is a great way to make your logic hard to track.
How can we solve this
Thankfully the solution to this is really easy! It involves the following:
CreateClientStore out of our
Move the configuration of your client store to its own file to help highlight that this is a very specific and a very important piece in our application.
client.js should look like this:
2. Move our defaults, resolvers, and
@client queries to their own file
Break out the
resolvers for a specific area of functionality into their own “store” files to help ensure as the application grows code is logically co-located.
3. Tie it together with some lodash magic 🧙
Finally we use some helpers from lodash to merge the export of each
store file into one. This allows us to define
defaults in separate files and bring them back together during configuration.
Look at the
mergeGet function specifically to see how this occurs.
Adding another feature becomes easy-peasy
Now that we have the above infrastructure in place adding a second feature is just as easy as adding the 100th feature.
Lets test out this statement by adding a Freeform notes field to the application.
1. Create the Notes Store
Nearly identical to the Todo Store above.
2. Hook up the new Store
Import the new store into
CreateClientStore.js and add it to our
3. Create the Note Component
Now that we have the store created and wired in it’s time to put it all to use.
4. Add to app.js
Finally add our new component to our
See it in action!
You should now be able to run the update demo and see our new note’s feature in action. Simple.
I wanted to put this out because I think this Apollo’s version of maintaining local state has some real potential and as a young project the more support it gets the more we should see if grow and thrive.
Part of supporting a project is learning how to use it and learning how to improve on it. I hope this helps do both!
🧞 This is open source! you can find it here on Github
❤️ I only write about programming and remote work. If you follow me on Twitter I won’t waste your time.