I don't know where the bug originates. But it can only be that either
`previousResult` or `fetchMore` result is sometimes undefined. This
should make the function bullet-proof for these situations.
- we still add the imageAspectRatio for new posts, but we don't do
anything with the layout until we figure out how to add
imageAspectRatios for every post with an image in the database without
causing a big downtime
by setting up localVue with all required plugins (such as styleguide and vuex)
in a separate testSetup file we can avoid doing this individually in all component tests
the testSetup is executed before each test suite, so each test file gets a fresh
instance of localVue
I also removed one frontend test. The test case was checking an edge
case. We use `hasMore` as the single source of truth so I think it's
safe to remove this test case.
- we were asked to hide the shouts from other users by Dennis Hack, he
believes people will be more likely to shout a post if it is anonymous.
This only works from our UI to our backend... further steps would need
to be taken to truly make it anonymous. Also, we were asked to implement
it in such a way as to give the user the choice to show their shouts to
others.
Co-authored-by: Alina Beck <alina.beck@mail.com>
- Add pin/unpin post to content menu
- Update apollo cache to reactively unpin
- Update apollo cache in root path to re-order Posts
- Order with pinned post first
- Start setting up filters, so that the pinned post is always the first
post visible
- we do not display a load more button when there are clearly no more
posts to load... if there are at least 6, the pageSize, we display it
because there might or might not be posts to load
- Position adjustment of the news feed plus icon in hight, because in desktop browsers it intersects the footer.
- Added shadow to plus icon on the user page.
It seems that `this.$apollo.queries.Post` can be undefined sometimes.
Honestly I don't know why but I could imagine that it might happen on
subpages and when the cypress test triggers the infinite loader, we
face this bug.
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
