Bypass Apollo Cache about react-mobx-state-tree

[alexvcasillas]

Hi @nareshbhatia ! Thanks for opening this issue.

I was considering using the Apollo Cache to avoid more network calls when you want to retrieve data that's already there in the MobX Store. In this example (for the repos, the user needs to be fetched bypassing the cache, with fetchPolicy: 'network-only', because it could potentially change), there's no need to use Apollo Cache because you only retrieve the data once, then it will remain exactly the same so basically there's no need to use Apollo Cache, that will be advantageous when for example you need to keep fetching data over time, so whenever the data remains the same, you won't need to make the call because you already have that data.

But as I said, there's no need of Apollo Cache for this small example I built to showcase the boilerplate.
I could work on a more advanced example where we can make use of subscriptions or fetching over time like a refresh to update or something. If you have any example proyect built with this boilerplate that you'd like to share, it's welcome : )

Agains, thanks for the issue : )

[nareshbhatia]

Hi @alexvcasillas, thanks for clarifying. I was actually thinking more on the lines of subscriptions, where we would cache the data in MobX and update it using subscriptions. We could normalize the data in MobX at an entity level (similar to what Apollo Cache does), thus making MobX a substitute for the Apollo Cache. The ideal scenario would be to make it API compatible with Apollo Cache, however I have not quite wrapped my arms around Apollo Cache to do that.

I have a slightly more complex use case in my graphql-bookstore example (see client and server). I think I will create a version of the client using MobX. Please feel free to collaborate. I will do the same for react-mobx-state-tree.

[kfrajtak]

Hi @alexvcasillas,
as I understand it the GraphQL queries are more or less in a tight relationship with the components - the query describes the data for the component which renders it. In your code, you have used the GraphQL query for the store/model. Are you following the approach that the state/data is the source of truth for the UI and UI is driven by the state and its changes? Opposed to the approach described earlier.
Thanks,
Karel

PS: Still getting my head around your code :)

[alexvcasillas]

Hello @kfrajtak !

First of all, sorry for the late response.
Second, I made use of MobX State Tree to create a similar MST Model that is closely related to the data that comes from the GraphQL server, this way I can make sure that everything is close to be a source of truth having this two models (MST Model & GraphQL type definition). The first will also be in charge of handling the data that comes/goes from/to the server : )

I'm not sure if this answers you question, I hope it does, but if not, don't hesitate to ask more about it : )

Warm regards!

[kfrajtak]

Thanks, no worries :)

So the data your component requires come from a view of a MST model and the data is loaded using GraphQL query?

[alexvcasillas]

Technically it does come from a model's properties instead of a view of a MST model, in MST views could not refer to all the properties and also could have computed values that extends the modeled data.

I make use of GraphQL to load my data and put it into a MST model, that way, I asure that the data in my database will remain almost the same (with the exception of computed and derived properties) during the whole app execution and locations, and I'll make changes to the database based on the properties of the MST model that happens to be exactly the same as the data structure at the database : )