I built an online, minimal note-taking app called “Jot” for my Rails API w/ Javascript project. This project was both a huge learning experience and struggle for me, one filled with many trials and tribulations, burnouts, rabbit holes, and tangents. But before I delve into it, I would like to preface that I originally transferred from the in-person program, so the requirements I followed for the project are slightly different from the online one in that I had to create a Rails API backend with no user authentication/passwords. Also, instead of just adding Javascript on top of an existing Rails app, I essentially had to build out the frontend and backend from scratch and have them communicate with each other via requests and responses.
In order to explain what the app does, it’s crucial to first state its two models, which are note and user. The relationship that both models have is that a user has many notes and a note belongs to a user. A user is able to create (“add” is used in this case), read, update, and delete many notes. Multiple users can also be added with validations and selected from. Not to mention, a user can either have those notes be unassociated with them by default or associated with them by selecting on their corresponding user name to see their notes. However, it is really important to note that since there is no user authentication, the notes are not private and secure in a way that they would be if each user had their own personal log-in account. Then again, the app is deliberately meant to be a fun and sandbox-y way to take notes online. It essentially works like online text editors but with notes instead.
Throughout the course of this project, there were many challenges, both minor and major, that I encountered and eventually mostly overcame along the way of building out the necessary functionalities of my app that prove to be a tall order. I can drown you in minute detail about every single challenge, but I’m just going to focus on a few of the major challenges. On top of that, I often had a habit of deviating from initial tasks and approaches to try and find better ways to figure out certain problems, which led me down many rabbit holes and tangents. I learned a ton from these but at the same time, they sometimes caused some serious and frustrating setbacks, which in turn really burned me out.
The first challenge I encountered was trying to figure out why a newly-added note wasn’t associating with a particular user. Right off the bat, I knew that I would have been able to easily fix this issue if this was a regular Rails app with user authentication by getting the user id from the user’s session information. I initially thought it was a backend issue with my Active Model Serializer not properly associating my models because the value I kept getting back from my API for both the user id and user of each newly-added note was “null”. But that didn’t seem to make total sense because the associations for my seed data were correct. With the help of some awesome Slack peeps, I came to the realization that I just had to find a way to pass in a user id to each note on the frontend. I did just that by getting the user id from within my selectUser() function then passing it to my addNote() function. Now every time a user adds a new note, that note gets associated with them.
Another challenge I came across was trying to figure out how to get a newly-added user to stay on the dropdown menu after a page refresh. Specifically, after a post request is submitted, a new user is successfully added on the backend and displayed on the frontend, but the issue was that upon a page refresh, the user would just suddenly disappear from the page. My thought process for this was since after a page refresh, the user would still persist on the backend but disappear from the frontend, so that must mean that the issue lies on the frontend. This thinking led me to believe that, for some reason, I needed localStorage to store data on the browser, so that even after a page refresh, all the users would still be there. To do that, I figured I needed to store the users in an array. So, my logic for doing that is if localStorage data exists, convert it into an object, then retrieve it. If not, create an empty array, then push each user into the array. Finally, convert the array back into a string (localStorage only saves strings) in order to store it. Even though my array of users was showing up and working fine, it unfortunately didn’t solve the issue of the user disappearing from the dropdown menu after a page refresh. Thankfully, with the advice and hints from my project coach, Dalia, I connected the dots together and finally managed to figure out how to fix the issue through a get request for all the users. This means that everytime a new user is added to the page, my get request will retrieve ALL the users, including the new user, even every single time the page gets refreshed.
The last major challenge that I faced was trying to figure out how to get all of the notes to only display for each corresponding user it belongs to. By default, a user can have notes be unassociated with them. If a user wants to have notes be associated with them, they either have to add a new user and add new notes to them or select an existing user to view their existing notes. So, the issue I was having is everytime a new note is added under a user, that same note is also added to the main page of unassociated notes. After fiddling around with my code for a while to no avail, I got frustrated and realized I needed a fresh pair of eyes. It only took a brief moment for my boyfriend to figure out and suggest that I needed a conditional statement right before the list of unassociated notes are rendered. Since unassociated notes have a user id of “null”, the conditional statement will check if each note with a user id is “null” and essentially filter out those notes if they are true.
There were features/functionalities that I wanted to fully implement in this project but wasn’t able to though due to it ended up being too much of a hassle, difficult, and time-consuming, and ultimately, not being high-priority enough. For instance, I have tried messing with the history API to modify a website’s URL without a full page refresh when clicking on a different user to see their notes, but it turns out I didn’t really need it. I have also tried changing my database from SQLite3 to PostgreSQL, but that proved to be headache-inducing and I thought I can just take a crack at it again when the time comes of needing to deploy it on Heroku. Last but not least, I have also tried reorganizing and restructuring my code and files entirely by adopting the module pattern, but I haven’t completely wrapped my head around it, so I’m going to put it on the backburner for now. I hope to revisit and apply that design pattern again when I start learning React. As I didn’t get the chance to do this as often as I should during my project, due to getting caught up in building out the requirements and ironing out the technicalities, I also plan on writing better commit messages more often, specifically in the present-tense, imperative-style, for future projects to come. Other things that I eventually want to build out in my app include but are not limited to a search bar, pagination, and the option to add style to text (such as bold and italic).
In retrospect, the solutions I came up for all the major challenges I discussed were relatively simple and easy. I tend to overcomplicate and overthink them and that’s something I want to get better at, but at the same time, I understand that that’s part of the process of getting better at problem-solving. If I want to be able to come up with the quickest, most efficient, and concise way of solving something, it usually starts off first as being the slowest, clunkiest, and longest way. If you are like me, it initially may seem really tempting to bite off more than you can chew, but don’t give in to that discomfort. Bite the bullet and focus on just building out your mvp in the best way that you can. Going down programming rabbit holes and tangents have both their drawbacks and benefits, but it’s always more important to try and set out to build out the task that you had in mind to begin with. All in all, this project really helped deepen my understanding of the DOM and async JS and greatly expanded my view on the possibilities of creating in vanilla JS, and I hope to continue adding on to this project and making it into something I would be proud of to showcase as part of my portfolio.