Posts

Final Tweaks

Image
After a peer-review some issues have come to my attention. I had not fully implemented recursive deletion of children when deleting their parent, as well as this, the application has been known to leave orphan images. The list of issues to iron out are as follows: Replies deleting on deletion of a comment Image and all comments deleting on deletion of a post All images, posts and comments deleting on deletion of a subweddit When a user is deleted, their posts and comments delete with them Replies deletion - For this I entertained many ideas within the Comment controller 'delete' method. Getting an array of the children and deleting the array, looping through the children deleting each individually, then deleting children of children.  None are as simple as this - a simple 'on delete cascade' relationship attached to the parent_id field on the comments table. As the parent is deleted, the child associated is deleted. This starts a chain reaction and cascades down to the ...

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.

Conclusion

Image
This being my first unguided Laravel project, it has forced me to plan my application and visualise a flow of data through the application, from a route to a controller, to a blade document, to sending a request. Though with the beginning stages of any language there is a lot to learn from the process. Weddit has been a wild ride, but very enjoyable. I have learned a lot about Laravel, MVC architecture, php, and frameworks as a whole. I have learned that making a database structure before you make an application is very, very valuable . that being said, for beginners like me, its hard to get the structure perfect, but that doesn't matter. I have also learned to read the docs . It's almost a joke how every StackOverflow article reply contains 'its in the docs.' or 'per the documentation'. Well, there's a reason. Once you familiarise yourself with them, Laravel has some of the most user-friendly docs out there, and have saved me from insanity quite a few times...

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...

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...

Creating a Following Feature

Image
To make a personalised home feed, the user must be able to follow a subweddit to recieve its recent posts.  The same thought process for creating a seperate 'comments' table went in to the follow feature of the site, I will create a Follows table containing the a user's id, and the id of the subweddit they follow. A user follows a subweddit. So, a subweddit can belong to many users. that is our relationship another relationship which will be handy to know is if a user is following a subweddit or not, it will take in the subweddits id and the user id to check the follow table, and return a true or false. From here, we could also create a follow and unfollow method and call them seperately, but we would require two forms on the site, thus two buttons. Not very clean, so a more efficient way of creating this functionality would be to create a button, or form, that does both in the form of a toggleFollow method. This method would check if the user is following the subweddit, if...

Creating a Nested Comment thread

Image
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 user_id (the creator of the comment) post_id (the post on which the comment is posted) 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 @...