This commit message is a great example of why you should explain
**the reason** of your commit.
When I came across this bug I had a quick look into the code where it
came from. I could see that the bug only happened after a timer and
apparently reverting the biggest part of d84892930295dcfd3f6687fc33c7234446127099
would fix the bug. However I have no idea what the following commit
message means:
```
commit d84892930295dcfd3f6687fc33c7234446127099
Author: Grzegorz Leoniec <greg@app-interactive.de>
Date: Wed Mar 6 18:45:57 2019 +0100
Improved countTo component
```
I just don't know why the code is there - like what is it's purpose
@appinteractive? I can only guess: I believe that it's supposed to
update the counters in-place (without starting from 0 everytime).
Because apollo was set to poll the data every second.
Taking that into account I would rather remove this polling feature
completely and have less code and less complexity. Admins can still
refresh the page.
@ogerly there is a difference between read and confirm: You can read but
don't have to confirm the terms and conditions. Therefore it's quite
important that the user also confirms the terms and conditions.
@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.
- add filtered state to vuex, so as to maintain filter
- filter is reset when visiting other pages, so reset the active buttons in the filter posts dropdown
- maybe we want to maintain the filters between page transitions and only clear when the user requests to?
Apparently the default pasteRules of tiptap interfere with the
pasteRules of a Link (in our case an Embed node). Consider this example:
https://de.wikipedia.org/wiki/Yin_und_Yang
Depending on some random conditions, tiptap might parse the `_und_` to be
italic because it's wrapped with underscores (markdown syntax). The
result is:
https://de.wikipedia.org/wiki/Yin # link
_und_ # italic
Yang # plain text
So let's remove the default pasteRules of `Bold`, `Strike` and `Italic`
marks respectively to prefer our Embeds. Who is copy+pasting from one
tiptap editor to another tiptap editor anyways?
- when a user clicks on the logo or changes pages, the filter is reset, but the active button didn't update
- still a bug with the active categoryIds since it's not so easy to set the state of an array in vuex
- dry out code for toggleFilters
- fix bug where user clicks on filter by users followed, then filters for categories of those users, then clicks to remove category filter
