I spent the majority of the day drawing out my models — Category, which is essentially the vision board itself, and Items that will be added to the visual inspiration board. My user story for this project is this: A user should be able to read and create vision boards based on categories.
The project instructions really emphasize understanding the project requirements and aiming for a MVP ASAP (Minimum Viable Product, As Soon As Possible). With the added complexity of separate backend and frontend repositories, I’m sticking to simplicity and focusing on what features are required.
I’m also trying to heed the advice to “build vertically, not horizontally,” aka not building all the migrations or models or controllers at once. Rather, I’m building one feature at a time.
To start, I’ve generated an Item model and created namespaced routes and controllers. I have set up my has_many and belongs_to associations and have double-checked that my associations are working by implementing seed data.
This time around, I want to be *extra* diligent with my commits and descriptions of the features I’ve added and git pushed.
Without following these order-of-operations guidelines, I would have blindly started coding. There are so many possible entry points so having a clear-cut option saved me a lot of grief. Should I set up the front end or back end first? Just I work on both at the same time? The answer is to work on one thing at a time — and not to move onto something else until you need to in order to progress the feature you’re currently working on.
Then I set up my frontend separately. From there, I worked on my get fetch request after setting up an event listener with a DOMContentLoaded event. The guide helped me practice working one feature at a time, and not following patterns of building all the migrations at once or setting up all the routes or controller actions all in one go.
I’m learning so much from project mode. Having debugger practice from the labs has been invaluable.
JS MANTRA: When some event happens, I want to make what kind of fetch and then manipulate the DOM in what way?
It’s a great way to think about the order of operations that adding an event spurs. You have to think about the three pillars of front-end web development: manipulating the DOM, recognizing events, and communicating with the server. When you’re coding, you’ll want to add event listeners to incapsulate when a user will do something like click a button or submit a form. The next step is thinking about whether you’re getting data (get fetch request), sending data (post fetch request), changing data (patch fetch request), or deleting data (delete fetch request). Then you want to thinking about appending information or taking a feature away.
I’ve found it super helpful to think about the three pillars of front-web programming in this way. Hope sharing a helpful mantra shared in a study group helps you too!
5/22/2021 | Hello hello! Last night I finished around 8:30 p.m., which is typically an hour earlier than I would have called it quits for the day but I had finished refactoring my get and post fetch requests in my ItemApi class so it was the perfect stopping point.
I watched a documentary called Some Kind of Heaven on Hulu last night. It focuses on a sprawling retirement community called The Villages in Florida where some senior citizens thrive while others flail. Although it has nothing to do with coding, which is what I needed after a long day, the incredible imagery and colors were incredibly inspiring for my coding/font-end design. One of the things I look forward to most as a full-stack web developer is creating beautiful web interfaces.
Yesterday, I was able to refactor most of my code into object-oriented classes having started with functional JS. There are so many ways to write JS that I find it kind of overwhelming. For instance, with an Api class, you can write the functions as static class methods or instance methods. I decided to go with writing all the methods as instance methods kind of arbitrarily. I can’t wait to become more proficient in JS so I can develop preferences and opinions about app design. Right now, I’m guided by patterns I’ve seen in labs and in study groups.
Goal for today: Make a category class and a categoryApi class that writes a get fetch request to my Category index action. Then I anticipate adding edit and delete buttons for my items and get those working with patch and delete fetch requests.
Another good dev habit I started with this project is working in separate branches. This way, I can keep the main/master branch clean with working code. I’ll only merge and make a pull request after the feature I’m working on is done and working. I had a heck of a time trying to find the last commit where everything was working before breaking everything while working on my Rails final project.
Hoping this will save me some time and anxiety.
I’m so nervous for the live coding part of my project assessment. Mostly because as I code, I Google everything — I also consult my notes every five seconds and watch study group videos when I can’t remember what to do next. They’re my safety net. Hopefully, after a big study sesh of the concepts I’ll feel my confidence build.
This morning, I solved a pretty minor bug without too much panic or Googling. The issue: I was able to successfully filter vision board items by category by clicking on each of the buttons corresponding with each of the categories but I couldn’t un-click the button to revert the DOM to showing all items. Adding one conditional (if the button does not have class “active”) did the trick. Once it checks for the conditional, it drops down into the else (assuming it has the class “active”) to then removes it. Once removed, the CSS magically reverts to back to a normal button.
Yesterday’s big win was adding a lot of basic CSS to style the page and adding a PATCH fetch request to delete the item from the DOM pessimistically (before the fetch request actually happens) and deleting the item from the database.
Today’s main goal is to finish the edit/update fetch requests and manipulating the DOM on both counts. I’ll most likely do a refresh on CSS flexbox to style the rest of the content. So far, I’m super happy with how it looks. All things are lookin’ up. I think I’m a day or two away from finishing up this project.
I’m excited to start the React and Redux portions of the course — the program finale. Finishing the rest of the lessons means I’ll be good to work on my final portfolio project. Ahh, I can’t believe I’m actually on schedule to finish by June 30, the deadline of my program.
After enduring a global pandemic (worrying about whether going to the grocery store possibly meant exposure to covid) and being a full-time caretaker for a parent all the while ticking off program requirements, I feel awesome to land here. Thanks for reading.