If we always choose `0` as the default value for `endVal` in case it is
not given (maybe apollo assigns null when the request is in flight) then
just make `0` the default.
- was throwing an error when trying to update commentsCount because of new implementation by @roschaefer which uses countResolver, but there was no related for commentsCount, it was r... also commentsCount is no longer needed anywhere in the code base, it is commentedCount now
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
* Add target="_blank" (on embeds only!)
* When pasting a link, the cursor position is moved after the paste
* Can't reproduce a link slipping into the embed in front of it
@Tirokk it is an unpleasant side efffect that mentions + hastags appear
differently on Edit+View. That's because they don't get parsed from
HTML, it's a one way, they are write only. So, when viewing content,
hashtags and mentions appear as plain links. I don't think I can do
anything about it.
Regarding some links not being embedded: Only those links that have an
oembed provider in this file:
f44d0f1f96/backend/src/schema/resolvers/embeds/providers.json
...will be embedded. Your example `http://backreaction.blogspot.com` and `https://de.wikipedia.org/wiki/Yin_und_Yang`
have no embed provider and won't be embedded.
We would have to add oembed providers to this list if we wanted to embed those
links, too.
Our build server failed because of frontend tests. However, all our
fullstack tests are passing... So maybe an issue in our test setup, not
reproducible in a real browser?
This commit:
ee4f132b0f (diff-0806c5f3fdae5e139222967601c7faca)
adds MutationObserver to their test setup. Adding it to our test suites
that touch the `editor` directly fixes our tests, too!
From what I can tell is that prosemirror is calling
`this.observer.takeRecords()`. Probably `tiptap` updated its
dependencies at some point and that's where `this.observer` was
introduced? Hard to tell. It really looks just like an issue only
present in test environments, so I think it's safe not to investigate
any further.
