@mattwr18 I prefer (I believe it's even best practice) that a delete
mutation should return the deleted object. If you run the delete
mutation again, it should return `null` because there is no object like
that anymore. That way the client knows if a delete mutation has changed
any state in the database.
Also I fixed another bug in the resolver. If your graphql mutation looks
like this:
```gql
mutation {
RemovePostEmotions(to:{ id:"p15"}, data:{emotion: angry}) {
from {
id
name
}
to {
id
title
}
emotion
}
}
```
Then you get errors because your resolver does not return the name for
the user or the title for the post anymore. Just use spread operator...
and it's fixed.
This commit takes all backend changes for signup and invite feature. I
was working on these features and removed the generated mutations for
type user along the way.
- use UNWIND instead of iterating over categories(cypher magic)
- do not return nested categories on post creation as it's expensive and we don't use
- refactor backend test
- component tests for CategoriesSelect
