Building The Comments Feature
Today I'm adding comments to this blog.
I'm going to write a post about this process while I do it.
A comment (currently) has the following properties (a.k.a. columns in the database)
|id||The comment's unique identifier|
|body||The text of the comment|
|user_id||The person that wrote the comment. This will allow me to find the member's username to display by the comment, and eventually their photo|
|commentable_type||The type of thing the comment is made on. (E.g. a post, page, someone's profile, etc...)|
|commentable_id||Which specific object of the previous type the comment has been made on|
|timestamps||The time the comment was created/updated at so they can be displayed in chronological order.|
The most confusing part is the "commentable" term.
Since comments are going to be supported on a lot of different things around the site I need to know the ID of the object, as well as it's type. (I need both since a blog post and a profile could have the same ID but are not the same thing).
This is called polymorphism (many forms) i.e. a comment can be attached to many different forms of objects.
Sidenote: You'll notice the comment has a user_id assigned to it but not a user_type. Since I know that only users can create comments I only have to store the unique user identifier, therefore no polymorphism.
Ordering in Views
Every post will display all of it's comments in one view, with oldest on top and newest on bottom. A form to add new comments will be at the bottom of this list.
|Consideration:||Oldest on Top:||Newest on Top:|
|Order||It's more natural to read chronologically down the page||Not natural if a comment references a previous comment (see indentation).|
|Indented Responses||Not necessary. Responses follow parent comment.||Most necessary. Responses shouldn't be above the parent so you need to make them indented children.|
|General UX||Not as good, you have to scroll to bottom to view the new comments||Preferred, new activity is the most visible.|
|Pagination||Doesn't make sense||Works well to hide older comments|
This is a problem I will revisit when I actually have comments, so for now I will move on. (Please help me out by commenting!)
Sidenote: if you have good examples of how ordered comments are displayed around the web I'd love if you shared them below.
Only members can comment, and for now they are published right away (with no spam protection).
Guest readers can view comments but instead of the comment submission form they are shown a message that invites them to log in or create their own membership.
Sidenote: The authentication links will take them to the login or registration page and they will have to navigate back to the post they want to comment on. It's possible to have the auth forms inside the comment thread, or use a query parameter to redirect the user back to the post they were reading, but for now I won't build that.
Right now a user cannot delete their own comments. Since no one is commenting I don't see why would I build out a way to uncomment.
As an admin I can delete any comment using my admin dashboard.
If/when I support deleting comments I'm still undecided if I would make the comment vanish from view (as if it was never there) or show a message that a comment has been deleted (e.g. reddit does the latter, I probably would too).
This is even less of a priority than deleting comments.
A member can post a second comment correcting themselves, or, in the future when deleting is available they can delete and try again.
Eventually I'll have to support locked Commentable objects (where comments are no longer allowed, but existing ones are shown).
This will be easy to ship in the future by adding a column to to the Commentable's tables in the database with a default "locked" value of false, and any individual item could have it's locked property set to true. Then in the view it will check if the post is locked before showing the comment creation form.
There is a comment count in the sub-heading meta for each post when viewing all posts in the blog roll (alongside the publication date and the author's name).
Counter String Grammar
You'll notice on the blog roll that the comment counter phrase ends in a period, but on an individual post page (if it has comments) it ends in a colon. ('10 comments.' vs '10 comments:').
It's just a personal preference to only use a colon for a heading if there is a list of items under it, because otherwise the sentence is just a fact.
I achieve this distinction by extracting a counter phrase view partial which I call from the index or show views, making it easy to pass the appropriate suffix. Additionally, the counter partial is where the logic for singluar vs. plural form of "X Comment(s)" is housed.
Nothing yet. Users have to create an account to comment, which might cause a deterant to spam. Soon I will require email accounts to be verified ("click the link in your email...") before an account can comment. I might have to integrate real spam protection someday but please don't make me build this out of necessity.
Thanks for reading, please leave a comment!
Please Login or Register to Comment