Creating a Nested Comment thread

A massive part of Reddit is the 'forum' aspect of it, comments and replies, threads of conversations. In this post I will be attempting to make nested comments associated with my posts.
 
For this, I thought of two options, either running a migration to create a new field in the Post table holding all comments, but I thought it would quickly get messy, especially with replies. A more suitable alternative is to create a Comment table, which holds 3 important details

  1. user_id (the creator of the comment)
  2. post_id (the post on which the comment is posted)
  3. parent_id->nullable() (the id of the comment they are replying too (for replies only, hence nullable))
This solution allows for endless replies, in a more clean and efficient manner. The migration looks a bit like this:



40,000 characters for a body seems a lot, but that is supposedly Reddits comment character limit, so i'll stick with it.

in the blade file for a post we can now add an addition of a comment box by including @_snippets.comment-form



Which under the hood looks like this is just a post request form containing the body of the comment, the post id and the subweddit id. All the user is concerned with is the body of the reply, the rest is given to the post request through hidden form elements such as the post and comment id's.

once this is successful and we have successfully uploaded a comment, we can loop through them iteratively to display them.

@foreach($comments as $comment)
    [blade formatting]
@endforeach

To reply to a comment, the process is much the same, we add a 'reply' box in our @_snippets.comments-replies with the same post form, but now attaching the parent_id as the comment being relied to.



From here, I ran in to an issue. I could upload a reply, and the parent_id field was functioning correctly, so next it came time to displaying replies. The code for displaying a comment and a reply has massive overlap, so I thought I could just loop through the comments replies by calling @include(_comments-replies) - supplying the details of the reply.

The issue then would be that the original loop is displaying EVERY comment, replies and all. so, replies would be shown proceeding a comment, but are also shown at the bottom. I attempted to filter out these stray comments by including an if statement at the top of the blade snippet (if parent_id = null then continue) which removed the stay comments, BUT when it came to calling the comments replies, none would display, because obviously they DO contain a parent_id.

I settled on just creating two blade snippets with near the exact same code.. 

  1. _comments (includes if parent_id = null)
  2. _replies (excludes if parent_id = null)]
Which worked. But after letting it sit for a short while, I found this to be something I couldn't settle with. Maybe the issue could be solved in the blade - but I decided to do some refining in the postcontroller@show method. All comments are passed in by this piece of code here 




But does it really need the replies if they are being called blade anyway? I thought not. So, instead, the only thing passed to the blade are comments without parent_id's. like so:


This way, the comments looped through in the blade are only primary comments, and the primary comments themselves call their own replies.




To finish off comments, there must be a way to at least remove them, ideally comments could be edited, but for comments to be edited within the blade I would need to use some sort of javascript, which I was not willing to venture in to for the moment, but deleting a comment only requires a simple 'x' in the corner.. suitable enough.

This was my solution - a delete request masked as an icon - identical to the subweddit delete button.


And voila, working comments thread!


It was at this point I researched in to creating likes. I concluded It would require a Likes table, similar to Comments, with the user_id, and the thing being liked. For liking one entity, the relationships seemed simple enough.Though the relationships for liking two entities is where things get tricky, the likes table would have to have a polymorphic relationship with both Post, and Comments so that both are 'likeable', something I deemed beyond the scope of this application, but not impossible.


Comments

Post a Comment

Popular posts from this blog

Final Database Design

Image
This is a view of the tables at the end of the project: Subweddit: Subweddit includes an id, name, bio and logo for display and information purposes as well a mod_id, the moderator of the subweddit (the subweddit creator by default right now) Post: Post has a title and body, as well as an optional img field. slug is created from the title field being 'slugified' with underscores (_). As well as this, the author of the post is saved as user_id, and the subweddit the post belongs to is also present. Follow: The follow table is the simplest in the database. apart from the laravel created_at and updated_at fields, this table simply holds the user id and the subweddit id of the subweddit the user follows. Comment: Comment holds one text field as 'body', as well as the author (user_id), and the post it belongs to (post_id). Finally, there is a nullable parent_id column which would be used if the comment is a reply, holding the id of the comment being replied to.
Read more

Validation

Image
validation, both serverside and clientside, is essential  for a satisfactory user experience, and for security.  This application makes use of several forms, so it is important that the site be completely tamper-proof. Thankfully, Laravel takes helps the cause, with the @csrf tag, which prevents csrf attacks, or cross-site request forgery. (explain this). validation on the registration is handled largely by the livewire auth package, the only tweak made is validation for the username, which was covered in the auth blog post. which leaves 5 forms to validate: create subweddit create post edit post create comment create reply Client side, all of the validation can be handled by laravel's @error directive, which will quickly determine if there is a validation error in an attribute. The message can be displayed by calling the array $errors. With our Bulma framework, we can make things look a little prettier for the user by changing the form border to red and displaying the red err...
Read more

Views and Policies

Image
Although maximum functionality is achieved by being a logged in user, it is important to think of guest users browsing the site. Baring that in mind lets run through the abilities guests and users: Guest: Home feed showing most recent posts from all subweddits view subweddit and contents view post and comments sign up User: Log in Personalised home feed Create subweddit Follow Subweddit Create Post Post comment/reply to preface: guest and user views could have been achieved in a cleaner way by creating seperate routes in web.php and stating if the user is logged in, redirect to 'logged-in' views, or otherwise 'guest' views. As my AWS instance is running on micro I chose to slim my application down so as not to overload my tiny server. Thusly, I opted for utilising @auth and @guest in the blade file. Not very clean, but effective and 'cost' efficient Starting with the index page: if the page is viewed by a guest, then display all posts from all subweddits, filter...
Read more