-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create comment object #147
Comments
The first step to the bootleg Google Docs commenting system is recognizing when an abstract's text is highlighted, and what text in particular. Using the web api `Window.getSelection()`, in the way that was suggested by Dasari Srinivas, one can highlight text and have it show up elsewhere. Right now, highlighted text is in a tentative spot in the comment div as a single comment that is not stored in any way, nor even tied to the `comment` field of `Submissions`. Issue #147 (Create comment object) Epic #131 (Submission Card View)
The vision of comments is that users either quote something directly from the abstract (optional `quotedSnippet`) via highlighting a passage, and/or making general comments (`commenterInput`). Submitters will have commenter names that are not fellow submitters made anonymous. Top level comments (TLC's) can be resolved or not (defaults to `false`), and comments on TLC's may or may not need to be resolved but for now they are optionally resolvable with the idea that they only contribute to the TLC being resolved. Resolved comments can either be hidden, or perhaps hidden from the normal comment space and shown in some sort of `Resolved` area like a dropdown for posterity, or crossed out in the normal comment sidebar? Perhaps if the TLC's exigence is argued to be relevant again then the Resolved TLC could be toggled to be an active, unresolved comment? All TLC's and subcomments should be timestamped. Issue #147 (Create comment object) Epic #217 (Comment on Abstracts) Comments are subset of: Epic #131 (Submission Card View)
…seed I thought that perhaps subcomments would best be `Array<Comment>`, if that is possible. Following up with that, the `commenters` field is more apt to be a singlular `commenter` field. Added an example seed that I spent too much time having fun with. Reference: https://www.youtube.com/watch?v=rvh0uaR7cd8&feature=youtu.be&t=193 Issue #147 (Create comment object) Epic #217 (Comment on Abstracts) Epic #131 (Submission Card View)
This was a lot of fun to do. Added faux (hard coded) functionality to the "New Comment" button that makes a comment entry text box open up. Highlighting the abstract hides that comment box for the highlighting/quoting comment textbox, and that box is hidden with the "New Comment" button. Added hardcoded template for comments and subcomments. Updated seed with an inside joke from My Brother, My Brother and Me about "Sleep Jeans" @ https://youtu.be/rvh0uaR7cd8?t=178 Seed doesn't have the actual comment field. Issue #147 (Create comment object) Epic #217 (Comment on Abstracts) Epic #131 (Submission Card View)
Click "Comment on Comment" on a TLC, enter text into a field that pops up, click "Submit Comment on Comment", and comment is "saved" temporarily. Like the other comment buttons, hides other types of commenting. Issue #147 (Create comment object) Epic #217 (Comment on Abstracts) Epic #131 (Submission Card View)
Comments should be linked to an abstract via Mongo's aggregation command. https://mongodb.github.io/mongo-java-driver/3.10/driver/tutorials/aggregation/#perform-aggregation Example from Paul: https://github.com/UMM-CSci-3601-F17/interation-1-drop-table-teams/blob/master/server/src/main/java/umm3601/deck/DeckController.java#L60 Basically, submissions' comments would just be IDs referring to comment objects. Aggregation links the two into one flat file. |
Another update: I won't push this up now but Nic and Paul were concerned about the way comments might nest with subcomments. They propose the following: import {User} from "../user";
export interface Comment {
_id?: {
$oid: string
};
commenter: User;
quotedSnippet?: string; //generated by highlighting abstract... may not always be needed
commenterInput: string;
resolved?: boolean; //Top level comments (TLC's) resolvable, comments on TLC resolved via TLC resolution
timestamp: string;
}
export interface TopComment extends Comment{
subComments: Array<Comment>;
} With that change, toplevel comments are an extended version of Comments, with the addition of having an array of comments as |
Based on Nic and Paul's feedback, Comment have been broken up into `SubComments` and `TopComments`. `TopComments` extend `SubComments` as well as including an array of subcomments. The comment seed has been split up into two seeds, respectively. Issue #147 (Create comment object) Epic #217 (Comment on Abstracts) Epic #131 (Submission Card View)
The topComment field in abstracts can now be retrieved from the seeds. The `topComments.seed.json`, which is now seeded into the DB, is referred to in the backend via the new version of `getSingleAbstract`. The method now grabs a single abstract as an aggregate and looks up topComments by their `$oid`. They are effectively joined together. An example of this working is on the single submission. The toplevel comment is now actually pulled from a seed. The subcomments are still hardcoded. Co-authored by: Paul Friederichsen <[email protected]> Issue #147 (Create comment object) Epic #217 (Comment on Abstracts) Epic #131 (Submission Card View)
The fields of the top level comment and its respective subcomments are still hardcoded into the seed. They need to be retrieved from other seeds by ID like the last commit's aggregate apporach. However, this is a nice proof of concept. Issue #147 (Create comment object) Epic #217 (Comment on Abstracts) Epic #131 (Submission Card View)
I can join topComments into abstracts. However, I cannot join objects from inside of a topComment into the topComment. For example, I would like an abstract to have an array of `topComment`, and each `topComment` would have a `commenter` field that should refer to a `user` by the user's `_id`. This can be done with the commented out code in the controller... EXCEPT the `topComment` array is no longer an array but instead a malformed object. This is a side-effect of the `Aggregates. unwind("$topComment")` that is needed to be able to join individual `user` ids to a topComment's `commenter` field. If the `topComment` field could be reverted to an array again, this wouldn't be a problem. Issue #147 (Create comment object) Epic #217 (Comment on Abstracts) Epic #131 (Submission Card View)
Almost all of a topComment is now nested in an abstract, using IDs to join other objects. The last piece is getting users to be able to joined inside of the `subComments` field `commenter`. The `group` method needs to re-add all fields via `first`, but for now it's easier to debug without all of those there. Issue #147 (Create comment object) Epic #217 (Comment on Abstracts) Epic #131 (Submission Card View)
Comments in abstracts right now are just a single string. Due to multiple comments being possible, with different metadata such as timestamps or submitters, comments should likely be considered to be objects in their own right. My thought is that submissions/abstracts should have comments be comment objects nested in them.
Thoughts?
The text was updated successfully, but these errors were encountered: