Closed ekzyis closed 1 year ago
Mhh, just tested with this comment on my local machine.
reply on another page
correctly links to that comment such that the reply also is beneath that comment ...
so we need to find a way to reproduce this bug, else i think this is going to be really hard to fix, lol
Since this happened to three stackers now, I think we can rule out user error, lol
Maybe if two people use reply on another page
, this happens.
We were able to reproduce it with and without reply on another page
...
also, nemo was able to trigger the bug replying to this without reply on another page
: https://stacker.news/items/246286
If a comment has the wrong parent, that means the comment is upserted with the wrong parentId so this bug involves some deviation in the way we pass parentId
Mhhh, yes. For some reason, I wrote here that I think it's a backend thing even though I have looked at the code and did see that we don't change the incoming parentId
in any way, lol
Not sure anymore what I was thinking
It's very my likely frontend if it's related to reply on another page
because reply on another page
is just a link to an item as far as the backend is concerned.
Can you described how this bug appears in more detail. Is it:
reply on another page
yes, but for some reason the bug isn't triggered always like that. as mentioned above, nemo was also able to trigger the bug without reply on another page
so maybe it has nothing to do with reply on another page
, lol
but i think it has to do with the comment depth
Okay, forgive for double checking, but being clear on this is important to us solving it. It appears to be sometimes recreated as follows:
yes. additionally, i think it's always 10 parents above. so basically, if you click "reply on another page" and then reply, the comment may show up below the top root comment. so as a reply to someone replying to a post.
When this happens, it eventually shows up as a reply to the root (and not some other ancestor)?
Second question: When this happens, what does the person submitting the reply see? Does the comment initially appear in the right spot then later they see it on the root?
okay, sorry that I've been lazy to create a detailed description, lol
I think an example will help:
marked comment in screenshot is this one: https://stacker.news/items/245763
however, the comment didn't end up as a reply to the marked comment in the previous screenshot, but here: https://stacker.news/items/245771
it eventually shows up as a reply to the root (and not some other ancestor)?
i think it immediately shows up as a reply to the root. and i think we only reproduced that comments from the first reply on the next page show up as the root comment as described in this screenshot:
When this happens, what does the person submitting the reply see? Does the comment initially appear in the right spot then later they see it on the root?
Yes, my experience is that you first see it (because of optimistic responses) but when reload, it's gone and you find it at the root comment
I think I found it https://github.com/stackernews/stacker.news/blob/e6ffeb8f763303de9ac881507809c0fdc6cc2053/components/reply.js#L93C1-L97C32
ParentId is not listed as a dep so whatever has been cached is being used.
If we want to be fancy and cache. We. Must. Always. Specify. All. Deps. (Saying this for me as much as I am for you.)
Ohh, hehe, yes, I think that's it
Nice catch! Didn't look out for missing deps
We should probably also check all other callbacks deps that I changed for anon stuff now
If we want to be fancy and cache. We. Must. Always. Specify. All. Deps. (Saying this for me as much as I am for you.)
I don't know about the standard
linter that we use, but I know there is an eslint plugin for react that can highlight issues like this one (missing dependencies in deps array) to help avoid it via static analysis.
Yes, good point. :) I am currently working on integrating eslint
into our CI pipeline. I think there are some other, similar bugs. For example, I think scrolling collapsed comments into view no longer works consistently:
/home/ekzyis/programming/stacker.news/components/reply.js
36:40 error 'onSuccess' is defined but never used
no-unused-vars
43:6 error React Hook useEffect has missing dependencies: 'parentId' and 'replyOpen'. Either include them or remove the dependency array. If 'setReply' needs the current value of 'replyOpen', you can also s
witch to useReducer instead of useState and read 'replyOpen' in the reducer react-hooks/exhaustive-deps
93:41 error 'amount' is defined but never used
no-unused-vars
97:6 error React Hook useCallback has missing dependencies: 'parentId' and 'replyOpen'. Either include them or remove the dependency array. If 'setReply' needs the current value of 'replyOpen', you can also
switch to useReducer instead of useState and read 'replyOpen' in the reducer react-hooks/exhaustive-deps
102:6 error React Hook useEffect has a missing dependency: 'replyOpen'. Either include it or remove the dependency array
react-hooks/exhaustive-deps
The error at 97:6
is causing the bug of this ticket. And the ones at 43:6
and 102:6
may be related to scrolling not working.
edit: Okay, no, I was wrong. replyOpen
has nothing do with scrolling, lol. It's only about opening the text input to reply or not.
I just saw something with .focus()
and thought maybe that's related. But it's not
I noticed the same but I thought I made a mistake. However, another stacker also noticed this now: https://stacker.news/items/245783
So maybe this is a real bug. Creating this ticket to investigate