A query such as `{ notifications }` would return `null` for Locations
with a missing translation, e.g. `nameRU`. This would not happen for
queries implemented by `neo4j-graphql-js` because they nullify all
missing attributes automatically.
- there should only ever be one Donations node to start off with, if
that changes in the future for some reason, then we'd need to look into
changing the match to something that makes more sense.
@mattwr18 vue-apollo rocks! Taking the time to study the docs is a
rewarding investment.
My first idea was to cache the `unreadNotificationsCount` with Vuex.
But the docs of apollo even suggest to use apollo's local state as a
complete replacement of Vuex:
https://vue-apollo.netlify.com/guide/local-state.html
Then I further investigated why the updated `NOTIFIED` objects won't
update the notification counter. Turns out: They don't have an ID and
the computed property didn't fire when the notifications array would
change. I fixed both in this commit and yes, it works as expected.
No additional code required 💪
- Remove package-lock.json because we are using yarn
- Remove every instance of graphql-requests as the backend doesnt use it anymore
- Remove graphql-request dependancy from the backend
- Update scripts for running tests in package.json and remove the unused scripts
- Update travis.yml to run the new test scripts
This registers the language Russian in the backend. Unfortunately, the
locations seem to be implemented with a hard coded attribute for each
language. 😞
We should refactor this.
@KapilJ your solution is right now the best solution, I think. Probably
the ideal solution would be if we could implement the `CreateComment`
resolver in such a way that it is doing eager loading of the
`comment->post->author` relationship and resolving a commment object
which has the required objects all set. Then you wouldn't have to
refetch all the stuff.
But I think this is OK for now 👍
