No way for client to know which paths were invalidated in a model.call ?
emilgoldsmith opened this issue · comments
I'm writing a function for a react app that will call a given falcor function and on the return, it will take the jsonGraphEnvelope that is returned and merge it into this.state.data (where we store the data needed for the component). Right now the client has no way of knowing which paths were invalidated and therefore and therefore should be removed from state though (say I'm deleting from an array). I thought that the jsonGraphEnvelope would return with the invalidated key as seen here: https://netflix.github.io/falcor/doc/typedefs_JSONGraphEnvelope.js.html
But apparently it doesn't, so I guess it's just Falcor that uses that internally?
Could we somehow implement a way so the client could get this information, or is there a workaround I'm not considering?
I just don't want to have to fetch the whole cache, or part of the cache for that matter every time, but would love to just get the specific information needed to the caller of model.call
The Falcor client uses the invalidated field to invalidate the model's cache. The app does not get this information. Your app should use the model as the source of truth though, so it should not need it. It sounds like you are duplicating part of the model somewhere else and need to sync it with the model. May I ask why?
Well we're using React, so the code is modularized, and each React Component has in it's lifecycle methods that it fetches exactly the falcor paths it needs and saves it on it's state property, and also keeps them updated as such. I think this should be quite normal, and isn't the reason that the call function already now returns certain values exactly so that the client can know only what was updated and not need to fetch anything else? If it returns the new values, why not also let the client know that some paths have been remove/invalidated as well?
I'm currently performing issue triage as we get ready to perform a proper release, and closing/tagging as I go.
Secondary caching, and being strongly aware of the state of the falcor cache is discouraged (and avoided at Netflix). Instead, it is recommended that you perform a fresh get() when rendering your react component (in our case we do this during componentWillReceiveProps since you're likely to get some requested data synchronously) and then setState. If some data is available now, and resolves asynchronously later, simply using setState will do the right thing and either provide the data to your render function or trigger a re-render later once the rest of the data is available.