Ok, so here are multiple issues:
1. In cypher, `NOT NULL` will return `NULL` not `FALSE`. If we want
`FALSE` to be set in the database import, we should use `COAELESCE`
to find the first not-null value.
See:
https://neo4j.com/docs/cypher-manual/current/syntax/working-with-null/https://markhneedham.com/blog/2017/02/22/neo4j-null-values-even-work/
2. I removed the `disabled` and `deleted` checks on the commented
counter. With `neo4j-graphql-js` it is not possible to filter on the
join models (at least not without a lot of complexity) for disabled or
deleted items. Let's live with the fact that the list of commented posts
will include those posts, where the user has deleted his comment or where
the user's comment was disabled. It's being displayed as "not available"
so I think this is OK for now.
3. De-couple the pagination counters from the "commented", "shouted"
etc. counters. It might be that the list of posts is different for
different users. E.g. if the user has blocked you, the "posts" list
will be empty. The "shouted" or "commented" list will not have the
posts of the author. If you are a moderator, the list will include
disabled posts. So the counters are not in sync with the actual list
coming from the backend. Therefore I implemented "fetch and check if
resultSet < pageSize" instead of a global counter.
The latest commit has some cypress tests failing when only a few posts
are visible on the index page. If this explicit default fixes the tests,
the documentation cannot be quite right in saying that it's the default.
FYI: @mattwr18
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.
@MoldaB here's how you can register plugins in a frontend test. Pro tip:
You can run `yarn run test --run-in-band` to find out where the
console.errors come from. Jest, by default, runs in parallel which makes
it a little difficult to debug errors that don't fail the test.
