Take a look into your future 🔮 I want to touch on how to set up to allow for support of multiple stores without interfering with one another. apollo-link-state In my last post we went over how to setup for basic use: apollo-link-state _Special thanks to Peggy Rayzis for all the awesome work and communication that has been going out around this product._medium.com Storing Local State in React with apollo-link-state Now in this tutorial this is the moon we’re shooting for: Moving to its own file. withClientState 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 apollo-link-state To kick this off I want to talk about the problem we are trying to solve. It boils down to that expects only one value for and one value for which is incompatible if you have more than 1 object you want to store. CreateClientState defaults Mutations.resolvers This will get unruly fast It’s incompatible because it forces us to keep the and for multiple logically separate features in one place. OR if forces us to explicitly reference a / from a separate file every time we create one. resolvers defaults resolver default 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: 1. Move our CreateClientStore out of client.js file 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. Our new should look like this: client.js 2. Move our defaults, resolvers, and queries to their own file @client Break out the and for a specific area of functionality into their own “store” files to help ensure as the application grows code is logically co-located. defaults resolvers 3. Tie it together with some lodash magic 🧙 Finally we use some helpers from lodash to merge the export of each file into one. This allows us to define and in separate files and bring them back together during configuration. store resolvers defaults 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 and add it to our . CreateClientStore.js STORES 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 container. <App/> See it in action! You should now be able to run the update demo and see our new note’s feature in action. Simple. Wrap up 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! Happy coding! 🧞 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.
