MoviRevu: A Rails React Project
Coding is a series of easy successes and impossible failures both of which can be caused by a comma.
An early struggle with the project was learning how to use BrowserRouter again. I have previously used the feature in other applications but upgrading to the new version involved learning new verbiage. The biggest change was the elimination of the Switch feature. They changed the command from Switch to Routes and instead of loading the route that matches the url first it loads the route that matches the url best. This was added to avoid accidentally making routes unreachable. With more usage I am sure these features will be greatly appreciated.
An easy part of this project was the central GET request. This is something that has been drilled into me from the first phase of this course. It is a repeated requirement and something that feels very natural now. Communicating with a backend to bring something to the front end for the user is a central component of what I have learned. Whether communicating with an API of someone else’s creation or one that I have developed myself it is something that has been made a comfort.
A struggle was my error handling of my create function. Going back through my curriculum to relearn how to properly use the create! was the first step. It is built to handle errors and I had given it no way to handle errors. I learned the backend rescue ability and had to add an overall exception
rescue_from ActiveRecord::RecordInvalid, with: :render_unprocessable_entity_response
this will automatically run the function render_unprocessable_entity_response when you get an error with either create! or update!. I am sure there are many other use cases but those are the two that were outlined going back through curriculum. Then you have to define that function to actually produce an error.
def render_unprocessable_entity_response(invalid)
render json: { errors: “Invalid Entry. Please include a title and at least 10 characters for your review” }, status: :unprocessable_entity
end
I chose a specific custom error message to handle the errors.
After this, I had to discover that I wasn’t handling an error in anyway on the front end so my back end error handling wasn’t being enforced. I created state for errors and set errors and added conditional logic to the rendering of the front end POST.
Something I enjoyed learning with this project was proper use of serialization. Telling the data not to display certain things as a base use was valuable and helped remove the unnecessary creation date and time from my visible backend and allows me to select exactly what I want to user to see. But much more useful it allows me to have access to reviews through the specific movie that they belong to. Using a serializer to tell Rails that reviews belong to movies now when I look up a review I can see the movie it belongs to. It gives me the backend data that I included in my movie serializer. This also allows for specific routing. Now I can go to movies/movie_id/reviews and see every single review associated with that movie and only those reviews associated with that movie. This helps with the GET call for my reviews so the proper reviews are displayed under the proper movie.
Sometimes I see something in code as I am learning and I add it to my own code without a full comprehension of what I am doing. In authenticating users I used a .authenticate method that I knew worked as I had used it during lessons but I had not grasped what it actually did. It goes through the saved hashed password to check that the password passed through params matches the password created. Vocabulary struggles and distinct definitions are a weakness of mine and I have to improve there or I’ll never be able to properly discuss what I am doing or what my peers are doing.
Becoming comfortable is all about repetition and evolving myself as I continue. Rejection and failure are inevitable but learning and moving on is the only way to be better.
