The Only Way Out of Coding Bootcamp is Through React and Redux

The final project for Flatiron’s Online Web Development Bootcamp is a React Redux project with a Rails backend. This project cumulates all of what we have learned in the course – Ruby, JS, HTML, CSS, AJAX, React, Rails, and Redux. React and Redux was tough for me to grasp. In addition to Flatiron’s curriculum I used Stephen Grider’s course on React and Redux: https://www.udemy.com/react-redux/. Stephen uses diagrams and analogies to help explain concepts, I highly recommend this course as he walks through building several projects from scratch.

The app that I built is called Daily Code Log in which you can document your daily coding progress. As a self proclaimed code newbie, I realize how important it is to document learnings, especially being aware of what you don’t know. Over time, as you seek out answers to your own questions, you will look back on answered questions and realize how much knowledge you’ve accumulated.

Now that I am on the other side, here are a few quick tips and pointers if you are thinking about tackling a similar project.

Map Out Requirements and a Schedule

The task at hand seemed daunting, so I decided to break the project into smaller parts. Here is my 9 day plan:

Saturday: Map project out- define relationships amongst objects and be clear about the question “What is the point of my app?”

Sunday: Create seed data, setup Rails backend of project.

Monday: Create entire (mockup) UI of project.

Tuesday: Hookup fetch get requests to fetch internal API data.

Wednesday: Hookup fetch post requests so API endpoint could be updated.

Thursday: Set up React routes.

Friday: Final touches/ squash bugs.

Saturday: Record video walkthrough of App/ write blog post on learnings.

Sunday: …Submit project!!!!

Setting a goal for myself each day was very helpful because each morning I knew exactly what I wanted to get accomplished. If I met my goal earlier in the day, I would move on to my next goal.

Use Semantic UI

I used Semantic UI for the web design of my app. Instead of a template, Semantic UI has many different elements- think buttons, cards, icons- that you can use in your app. Semantic gives you the different building blocks, but ultimately the final product can look original and custom made. In order to reference Semantic UI within your application you simply have to import the following link into the client/public/index.html within the <head> tag:

<link rel="stylesheet" href="<https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.4.1/semantic.min.css>">

I then used some CSS to reposition and style the elements further.

Here are some screenshots of the simple design of the app:

Form to create a Code Log
Display of all Code Logs

More Than One Way to do the Same Thing…

The trickiest part of the project for me was submitting forms to update my internal API endpoint. Doing a quick google search, most people suggested I use https://redux-form.com/, but my instructor helped me post data to my API without Redux Form. Instead, we used vanilla javascript. In the form’s handleOnSubmit function, we called on an action call addLog which made a post request to the API endpoint:

export const addLog = (log) => {
  return dispatch => {
    return fetch('/logs', {
      method: "POST",
      headers: {'Content-Type':'application/json'},
      body: JSON.stringify({log})
    }).then(resp => resp.json())
      .then(log => dispatch({type: "ADD_LOG", log}))
  }
}

The reducer, “ADD_LOG”, then adds the form’s data to the Redux store.

I’m looking forward to diving into Redux Form but it was worthwhile to learn the vanillas JS way. Now, when I learn Redux Form, I’ll have a solid idea of what Redux Form is doing behind the scenes.

I did it!

I am very proud of the way the project turned out. I have used the app daily to track my coding progress, and once I add authentication, I hope others use the app for their learning benefit as well.

P.S. Here’s a walkthrough of my project!

What’s an API?

Before attending Flatiron’s online coding bootcamp, I worked as an Operations Analyst for a clean tech company. Although writing SQL queries were the closest I got to actual coding, I was constantly surrounded by tech jargon. I remember hearing lots about API’s. They seemed fragile, complex, hard to define. However, after adding Javascript onto an existing rails project, and enabling internal API use, I have a clearer understanding of what an API is and its use.

What’s an API?

An API is an end point to request data. The data is typically in JSON (Javascript Object Notation) format, reading like a dictionary with its key value pairs, making it very intuitive to read. Data is processed from the endpoint through the browser and can be viewed in the console before it is added to the desired destination, or page. Viewing the data in the console is very helpful because you can play around with the data with Javascript in the browser’s console— testing code to access the points of data that are important to your application.

Internal vs External API’s:

I always thought as API’s as exclusively external. My goto example of an external API is Google Maps. For example, my local pizza shop has Google Maps embedded into the user interface of their website. Luigi’s connects to Google Map’s API so pizza lovers can see the restaurant location when they go onto the site.

However, in the context of my project, I wasn’t in need of external API’s, I wanted to render data that was available within my application. The theme of the project was to render data via AJAX. For example, after a user click ‘View Class Plan’ the class plan will be rendered from the API endpoint, and there will not be a page refresh.

The API endpoint looked like this:

I then wrote the following code in order to render the data from: http://localhost:3000/yoga_classes/6/yoga_class_data and append it to the yoga_classes index page: http://localhost:3000/yoga_classes

$(function() {
    $(".js-more").on('click', function(){
        let id = $(this).data("id");
        $.getJSON("/yoga_classes/" + id + "/yoga_class_data", function(data) {
        $("#body-" + id).append("<p>" + data["class_plan"] + "</p><p> Created by: " + data["user"]["email"] + "</p>")
      });
    });
  });

Breaking down the code:

  • Line 2: is saying for class “js-more”, which was assigned to the “View Class Plan” button, when the user clicks the button the following should happen…
  • Line 3: assigns a variable id to the yoga_class id so that in line 4 the yoga_class_data URL can be dynamic.
  • Line 4: is where the magic happens. The JQuery method $.getJSON takes two arguments the, the dynamic /yoga_class_data url and a function…
  • Line 5: that function takes in data (which represents JSON data of a yoga_class) as an argument and appends (adds) the class plan and user to the class ID body-[id], this case body-6, which is located underneath the yoga class title on the page http://localhost:3000/yoga_classes.

Note: I also used Active Model Serializers gem which grants the backend ability to serialize data with the necessary attributes and relationships. .

When Learning and Applying Something New, Pace Yourself:

At the end of each module for Flatiron’s Online Software Engineering Immersion course we are required to build a project which culminates everything we learned the 3 works prior. We cover so much material in 3 weeks that when project time comes around I don’t feel comfortable with the material initially. Each project week I look over the scope of the project and immediately the requirements seem daunting. The Javascript, APIs, and AJAX section was no different. Instead of remaining in a state of resistance I decided to breakdown the project. We had 5 requirements, so my goal was to complete a requirement per day, leaving two extra days for pesty bug fixes or more time in case a certain spec took longer to tackle. This proved to be a great method. I managed to finish my project in 4 days. If I was able to meet my requirement for the day, I continued working. I find that learning happens best when spread out over multiple sessions, so working on a requirement (each requirement tackles a slightls different concept) over 2 separate days solidified my learnings.

Learning a second language was tough, but I learned why it’s necessary. AJAX requests make it quicker for a user to interact with my app. It gives the user the ability to request more data without having to load a new page, which is the modern experience of the web. I’m looking forward to how the concepts of AJAX apply to Redux and React, the last module for the coding bootcamp!

P.S. here’s a walkthrough of the app described above!

Back to the Drawing (White) Board

The project I built using Ruby on Rails is a private group class tracker for a yoga studio.

Sounds like a mouthful, I know, but I noticed that the yoga studio I work for has a niche problem. Local organizations such as universities, non-profits, corporations etc. request for a yoga teacher to come onsite to teach a class. Most of the time, these requests are inconsistent. For example, an organization will want a class for their “Wellness Week” which only happens a couple of times per year. Since requests are inconsistent, the same client will have a different teacher each time. The teacher assigned for this offsite class has no idea what kind of class to plan. What kind of practice do the participants want? What is the space like? It would be nice if they could take a look at the class plan from the previous class, that was perhaps taught by a different teacher! That’s where my web application comes into play!

My enthusiasm for my idea fueled the creation of the project, however this was the toughest project yet. Here’s what I learned:

The importance of having a clear vision for your project before you get started.

I had to restart my project twice! I had to restart my project because both times my domain was not clearly defined from the get-go, which made building complicated (lesson learned!). However, each iteration of my project led to my final product, which I’m very proud of. While I shared with my friends and family about my tribulations, I compared my process to something they were familiar with, writing a thesis paper.

The first step is to clearly construct a thesis statement, in coding world this would be constructing our domain models and defining relationships. The thesis statement steers the ship as you’re writing the paper. Similarly, your models and relationships can create the backbone of your Ruby on Rails application. If you write a thesis paper without properly researching a topic, as you’re writing, you may have a change of heart with your beloved thesis statement. Now that you’re reading additional sources and are really diving into the topic, perhaps you want to change your stance. So you go back to the drawing board and rewrite a thesis statement that better represents your positioning now that you have new information. You have to start your paper all over again. Similarly, as I began to bring my project to life, I realized there was a better way to represent my project— different from the models and relationships than what I had set up. Since I wanted to change the infrastructure of my project, I had to restart my project.

Knowing when to let go if a certain idea isn’t working out.

It’s tough to abandon a project after spending a lot of time on it. I spent 4 days on my first iteration, knowing most of the time that I wanted to restart it and take it in a different direction. I was so resistant to restarting, but once I took action and restarted, I felt a surge of momentum because I knew it was aligned with my vision. To make myself feel better about my situation, I thought about how artists record entire albums that never get released and fall to the wayside. Authors write novels that never get published. Although these pieces never make it to the public, I bet these creative pursuits influenced other pieces that eventually did reach a broader audience. Similarly, my failed projects influenced the success of the final version of my project.

Get to know the gems you’re using.

Since I restarted my project twice, I can now set up Devise and enable Omniauth using Facebook with confidence. This was my first time using both Devise and Facebook Omniauth. Typically when I use a gem for the first time I find a blog or video to guide me through step by step. The downside of this method is that I blindly follow step my step without internalizing or completely understanding what’s happening. For this project I was able to set up Devise and enable Facebook’s Omniauth three times, so now it’s solidified in my brain. It got me thinking, that for future projects when I’m using a new gem I should make sure I really know what the gem is doing, so when if I run into a bug I’m better equipped to resolve the issue.

Nested resource show page

A feature of the app I was excited to implement was to view the history of classes by client. This would help the user zoom in on which templates to research and take ideas from.

Each class would be represented by a link that would then take the user to a nested resource show page, which would have all the available information about the class.

The code behind this feature was fairly simple, yet important to break down.

<p>History of Classes:</p>
<% @client.yoga_classes.each do |yoga_class| %>
  <%= link_to yoga_class.title, client_yoga_class_path(@client, yoga_class)%>
<% end %>

In my client model I defined the relationship that a client has_many yoga_classes. This then gave me access to call on an instance of a client and a list of their associated yoga_class objects which are assorted in an array. Then, I called an iteration on each yoga_class to create a link for the specific yoga_class. With link_to, the first part of the link is what the name of the link is, and the second piece is the path the link takes. So, I named each link the title of the yoga_class. Then, I used the route helper (route helpers are a piece of magic given by Rails) client_yoga_class_path(@client, yoga_class) so that a specific class would be nested underneath the client. @client was the first argument of the path because the helper needs to know which client_id will have all of its associated yoga_classes listed. Then, the url needs to know which yoga_class to route to based on the yoga_class id attribute. This helper is constructing the following template of the url: /clients/:client_id/yoga_classes/:id. As you can see in the screenshot above, the yoga_class has a client_id of 5 and an id of 4.

Just getting started….

Building the private group class tracker application taught me A LOT. I have a lot of ideas about what kind of future implementations I want to build for the app- like duplicating a template, since there should be a template representing each time a teacher taught a yoga class. Also, I’m looking forward to learning JavaScript and React to enhance the UI of my application. This is just the beginning!

I Completed My First Coding (Bootcamp) Project!

The training wheels have been removed…

Building my first project for my coding bootcamp was quite the experience. The challenge was to build a CLI gem and use Ruby to scrape data from a website. I decided to scrape https://www.codenewbie.org/podcast. The Codenewbie Podcast is my go-to resource to learn about different topics and different roles in the tech industry. It’s also my #1 resource for coding inspiration when I feel like giving up. Often times guests on the show are career changers and self taught developers I can relate to.

My program lists all of Codenewbie’s podcast episodes with each episode’s relevant information such as the episode’s title, guest, and air date. Additionally, a user can interact with my program through their terminal and retrieve the url link for any episode in order to listen to the interview.

The due date of the project coincided with the holidays, so I had a lot of friends and family checking in and asking me how school was. I repeatedly went back to my bicycle analogy.

I am swerving heavily and am wobbly yet defiant as I ride my two wheeler.

The training wheels which were removed:

  • Using learn.co as an editor. Learn.co is Flatiron’s built in house code editor and is extremely helpful. The platform runs tests and submits pull requests to GitHub using human friendly commands such as learn and learn submit, respectively. However, I used this project as an opportunity to work with building a program locally in order to replicate a more authentic developer experience. I successfully installed Atom and connected my local files to Github using the command line. Getting comfortable with the command line was not easy, as I was following Youtube tutorials and was memorizing what to do. I had to repeat the process several times to truly understand what was happening.
  • RubyGem setup. Prior to starting my project, I never had to set up a RubyGem. Our labs already had a neatly organized library to work off of. Also, we didn’t have a lab to practice how to fill out the relevant info needed to create a gem, but I followed this video https://www.youtube.com/watch?v=RrAOlk6qoiM which proved to be very helpful! However, like I previously mentioned, the issue with recorded videos is that I tend to go through the motions- copying the instructor without truly understanding what’s going on. I had to watch the video 3 times before I felt like it seeped in.
  • Labs. Before this project, I had a neat container to learn in. Most labs are heavily focused on just a few topics with clearly written tests. However, when I went to plan out my project, I felt overwhelmed thinking about all of the concepts my project had to include. I knew I needed a different strategy. I followed along with Avi’s method on how to build a CLI Gem https://www.youtube.com/watch?v=_lDExWIhYKI, and I really liked his method of tackling a project. Avi stresses the importance of only focusing on the task at hand (1 or 2 objectives), completing the task, and then the next step will reveal itself. It was a playful approach to a lofty project, and I was able to make steady progress. It was fun to react to the quick decisions I was making.

I have alluded to this, but the toughest part about this project was everything besides the coding. The coding was a process I was familiar with. Strategy and setup are new and less straightforward topics for me. I was able to talk over my struggles with RubyGem setup with my Cohort Lead in our 1:1, and the strategy to tackle the project with my classmates. Although this was a solo project, having help and support from my cohort made me feel like I wasn’t in this alone. Overall I’m proud of the work I did and am excited that this is just the beginning!

P.S. Here’s a walkthrough of the app!