Skip to content
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.

[Sync] Apollo cache persist should have configurable debug parameter #290

Open
wtrocki opened this issue Mar 11, 2019 · 2 comments
Open
Labels
good first issue Good for newcomers sync Sync issues

Comments

@wtrocki
Copy link
Contributor

wtrocki commented Mar 11, 2019

There is no simple way to see persisted objects in cache. Adding debug flag is possible but currently, there is no way to do it without recompiling distribution binary.

@wtrocki wtrocki added good first issue Good for newcomers sync Sync issues labels Mar 11, 2019
@darahayes
Copy link
Contributor

I think ultimately it would make sense to have accept a client options object and also a cache options object to allow for more flexible configuration.

We could allow users to supply an object satisfying the ApolloPersistOptions interface https://github.com/apollographql/apollo-cache-persist/blob/master/src/types/index.ts#L19-L28 and merge that with some sensible defaults. What do you think?

@wtrocki
Copy link
Contributor Author

wtrocki commented Mar 11, 2019

There are two approaches here. We can allow people to modify how the client is created since currently, we hide tons of options from Apollo client inside our wrapper.
For example, it is not possible to use @Local resolvers in our client as this requires passing custom code to client. Historically we started with something called client builder, but now I think that we may need to simply have a way to build our "uber" link and allow people to create client with their options. To simplify things createClient can still stay, but we should be probably exposing our default link instance (we do not at the moment). This will give users full upstream api that they can interact with + draw line what our client provides: "An opinionated link chain for offline and conflict resolution".

There will be many flags like this that clients will need to poke with and currently the only one way will be to simply fork the project which is not ideal.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue Good for newcomers sync Sync issues
Projects
None yet
Development

No branches or pull requests

2 participants