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 💪
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.
- it's good to return the pinnedAt date for ordering
- move test to a better describe block
- remove unneeded outdated variables from graphql/PostQuery UpdatePost
- fix indentation in Post.gql
- fix pinnedAt to return pinned.createdAt, not post.createdAt
Co-authored-by: Mike Aono <aonomike@gmail.com>
- this was causing the noftications to break since they were using the
post fragment and pinnedAt was returning null
- remove unused bits of code
- revert changes to cypress since they were not causing the error
- can be changed in another PR
- following @roschaefer's PR review suggestions
- simplify UpdatePost by using pinPost/unpinPost
- did not remove filtering because attempting to have two queries caused
problems as well to do with duplicate records, etc... and it's working
now
