We need the order input types for our admin features.
This is a potential DOS vulnerability: Ordering the tags by taggedCount
might lead to very expensive cypher statements.
Apparently, `neo4j-graphql-js` *replaces* the schema partly. When we use
join models like `EMOTED`, `neo4j-graphql-js` puts in a join model with
the two names of the connected types.
I deprecated the debug flags myself here:
https://github.com/neo4j-graphql/neo4j-graphql-js/pull/288
You can now debug the queries run by `neo4j-graphql-js` by starting
the backend like this:
```bash
DEBUG=neo4j-graphql-js yarn run backend
```
- I wanted to trigger a build, since we had issues with our build server
today. I think this naming is more in the direction we want to go,
though. Maybe it could be makeShoutsPublic as @alina-beck used for the
translation keys... what do you think @kachulio
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 💪
