When doing #7 I stumbled across these questions: Why is a reply part of the comment and not a comment on its own? Can we unify the comment's author's data?
Problems / limitations as it is right now:
Each comment can only have one reply.
There can only be a flat list of comments (not a tree of replies).
Altering the fields of a comment (e.g. adding an avatar) needs to be done for replies as well.
A comment could instead consist of the following properties (simplified example):
id
replyTo (comment id | null) <--- comment tree
...
authorMember (member id | null)
authorUser (user id | null)
authorGuestEmail (string | null)
authorGuestName (string | null)
...
comment
date
...
There could than be an interface that wraps around the different author sources and provides additional meta info like isModeratorReply. If frontend and backend users will get merged some day this could be simplified further. The properties could be constraint to only contain a member OR a user OR anonymous author data.
A tree of comments could than be rendered as a tree, flat list sorted by replies or a flat list sorted by the actual date.
When doing #7 I stumbled across these questions: Why is a reply part of the comment and not a comment on its own? Can we unify the comment's author's data?
Problems / limitations as it is right now:
A comment could instead consist of the following properties (simplified example):
There could than be an interface that wraps around the different author sources and provides additional meta info like
isModeratorReply
. If frontend and backend users will get merged some day this could be simplified further. The properties could be constraint to only contain a member OR a user OR anonymous author data.A tree of comments could than be rendered as a tree, flat list sorted by replies or a flat list sorted by the actual date.
BC is the biggest problem I guess.