Forem: Kate Bennert

Managing Multiple Users: Single Table Inheritance and Role-Based Authorization in Rails

Kate Bennert — Sun, 13 Aug 2023 01:48:25 +0000

One of the things about web development that keeps me coming back for more is the fact that there are so many different ways to solve a single problem. (This is also something about web development that I find incredibly overwhelming depending on the day, but that day is not today!) The problem of how to handle multiple types of users in Rails is no exception.

I tend to approach challenges like this with an "experiential education" mindset in that when I experience a problem, I educate myself on how to fix it. This is probably the same thing as "trial and error," but I feel like there is more nuance to it.

My personal journey with creating an application that catered to multiple types of users started with a decent understanding of how my data was interrelated, but ended up with not only a much better understanding of my entire database but also a streamlined organizational structure that made sense for my project.

That said I am very much still learning and this is what made sense to me at this point in my career and learning journey. I always welcome comments and suggestions!

The app I'm working on is designed to create a space for event planners (think weddings and large corporate Events) to collaborate with clients on events that they are planning together.

To manage this User/Client/Planner relationship, I used:

Single Table Inheritance to create to subclasses of the Users class
Role based authorization to ensure that Planners had access to "admin" features that clients did not
Some front-end manipulation so that Clients and Planners see a different app when they login

Understanding Single Table Inheritance (STI)

Single Table Inheritance is a way of organizing your Rails application so that different models (in my case the Client and Planner model) can inherit from the same model (Users) and share the same table (also Users) in the database. The benefits of using STI in your application are mainly to:

Keep your code DRY by grouping models with similar behavior into one category
Help you (the developer) keep things clearer by allowing the separate classes to be called independently of the User class. For example, STI made it possible to call Planner.all or Client.all to pull up all the instances of those classes (as opposed to User.where(role: 'planner')
Simplify associations between types of Users

Implementing Single Table Inheritance

Here's how to set up STI in a Rails application using the Users: Clients/Planners example.

Set up your database so that your table has a column for variable classes

You'll need a type or role column to identify each instance of the User class as either Planner or Client.

class CreateUsers < ActiveRecord::Migration[6.1]
  def change
    create_table :users do |t|
      t.string :role
      # other table columns

      t.timestamps
    end
  end
end

Next we'll tell Rails how to use that column.

Set up the models and inheritance

In this case I had a parent model User and two subclasses of that model Client and Planner. Both Client and Planner will inherit from the User model which means they will share any associations or methods in the User model.

class User < ApplicationRecord
   # any common associations or methods

   # establish the column that will define the classes
   self.inheritance_column = :role
end

class Client < User
end

class Planner < User
end

Querying and retrieving data

When you retrieve data from the database, Rails will use the role column established as the inheritance column to return an instance of the subclass. For example,

User.first # returns an instance of Client or Planner depending on the role column

Using data

You can now call on the subclasses just like regular models on your routes. Client.all will return all instances of the Client subclass and Planner.new will create a new instance if the Planner class (which is also a new instance of the user class with the role Planner.

Using Role Definition in Other Aspects of Your Application

Setting up the database for your different roles is only the first step in setting up your application for role-base usage. One of the other big aspects of a role-based application is how your different types of users can interact differently with your app. In my project, Planners have more permissions than Clients and can interact with more of the app. To handle this, I implemented role-based authorization.

Role-Based Authorization in Rails

There are three simple ways to start to implement role-based authorization in your Rails application (amongst some helpers and gems like CanCanCan or Pundit).

1. Set up roles in your database using a "role" or type column like the STI table outlined above

2. Implement a `before_action` filter in your application controlled

class ApplicationController < ActionController::API

  before_action :planner_auth

  def planner_auth
    render json: { errors: ["Not Authorized"] }, status: :unauthorized unless session[:user_role] == "Planner"
  end

end

This filter remains in place for all controller actions that aren't explicitly skipped: skip_before_action :planner_auth.

3. Use Conditionals in Your View to Limit Access to the App

Although this is important for a smooth user experience, it can't be the only way that you manage that access. Step 2 is important so people without the correct access can step through your app by accident or in a malicious way. In my project, I used conditional rendering to hide certain aspects of the NavBar from Client users.

Role-Based access is a key part of the way web applications are used and maintained. I'm excited to learn more about how developers use these strategies in more complex applications.

Building a RESTful API with Ruby on Rails (and Getting Some Rest Yourself 💤)

Kate Bennert — Tue, 13 Jun 2023 01:01:02 +0000

This past two weeks I've been working on my first full-stack application with a RESTful API I made using the Ruby on Rails framework. This project (more than the three I've worked on before this) felt absolutely HUGE to me when I was getting started. As a Ruby on Rails newbie, I had only worked with Rails applications with 2 to 3 models that mostly had a one-to-many relationships. Plus, these apps were school assignments that had a bunch of starter code!

After brut-forcing my way through getting this project off the ground (and losing a lot of sleep in the process) I eventually emerged on the other side in a state of coding zen. Below are some tips for building your own Rails API and some things I'm very happy to have learned in my process.

Pre-Planning Strategies 🗓️

The most important part about starting to build a Rails API is understanding the relationships between your models. In my opinion, everything else is secondary. I am a huge fan of regular old analog pen and paper when it comes to mapping out my database! This way I can look at it in whatever layout is pleasing to me at the time. (Sometimes my brain wants to see things vertically, sometimes horizontally. 🙃) That said, everyone is different and sometimes we'll need to collaborate on our preplanning. I have also used dbdiagram.io which is a great tool for helping to visualize the schema of your db.

Something else that I employed in this project management planning was what I've called a workflow grid. The guidelines for our project suggested to work on the project in "vertical slices" in that each function should be seen through from start to finish and then each additional function build on top of that. For example, work on the sign-in flow and see it through from migrations to client side styling before you move on to another function that might involve another model/migration.

(Something that is also really important for me is to not spend too long on the planning side of things. While it's good to have a solid plan in place and a solid understanding of where you want to end up, it's equally important to get past the initial hurdle of just getting something down on the screen! You will end up learning so much about your data while you're working - even some things that you didn't plan for. I think this is especially true when you are a beginner!)

Getting Started (For Real) 🏁

When you're ready with your models and relationships, it's time to generate some resources. You can always generate the models, migrations and serializers separately if you prefer a little more control. I considered this when I was starting. Generating a whole resource felt to permanent - like I had to have my whole life planned out in order to use it. But this is a fallacy!

Using a generator, in particular the resources generator does not mean you have to keep everything it generates! You can always go in and edit the migration file (before running the migration), you can go into the routes file and specify the routes you need, and you can choose not to use the serializer if you don't need it. Even after running the migrations, you can still add or take away or rename columns! Remember: the models and migrations and seeds make up a set of instructions for creating the database.

(A brief note on this way of thinking in general: nothing is ever "unchangeable." We go to great lengths to make sure that that is not the case. This is why we use version control software like git and structures like Active Record and Rails I used to be so scared of doing something wrong that I would agonize about doing it right the first time. Thankfully this thinking fell by the wayside about 3 days in!)

Here is an example of a resource generator for a basic Users model:

rails g resource User username password_digest image_url bio:text

(I chose to add relationships to my models directly - but you could add them to the generator too)

This will generate:

A model: user.rb
A migration with the specified columns (remember to add a foreign key (belongs_to) relationship to your migration before you migrate if necessary)
A controller: users_controller.rb
A serializer: user_serializer.rb
A route in the routes.rb file: resources :users

Hooray! We're in it!

Models and Migrations and Serializers (Oh my!) 🦁

So what do we have here?

Model: The model represents the data stored in your server for your application. It corresponds to a specific database table and provides any relationship information and a script for how to interact with the data.

Make sure your relationships are mapped our correctly in your model by using has_many, belongs_to, or has_many, through statements. Though this doesn't affect the schema, this will affect the way the database stores and reads the data!

Migration: Migrations are used to manage changes to the database schema. They provide a way to create, modify, or delete database tables and columns. Again, this is set of instructions for the database to be created. Remember not to edit the migration files without first rolling back the database. OR write a new migration to make edits!

Serializer: Serializers transform model data into a suitable format (such as JSON) for sending over the API as responses. They allow customization of the data representation and control what attributes to include or exclude. You can include relationships in the serializer to handle nested data too. For example:

class UserSerializer < ActiveModel::Serializer
  attributes :username, :image_url, :bio, :location

  has_many :offerings 
  has_many :bids
end

This serializer will send back a nested user object with associated offerings and bids. Note that the attributes do not include the password_digest column. That is not info we'll need to pass from the backend ever.

Lastly we have a controller: The controller handles the incoming HTTP requests from clients, performs necessary actions, and generates responses. It serves as the middle-man between the client and the model. This is how your frontend communicates with your backend.

Each model has it's own controller but you can also choose to outsource some reusable actions to a parent application_controller such as error handling.

Route. Route. (Let it all out) 🛣️

These are the things I can do without...

The resources generator will automatically add the 'resources' route to the routes.rb file for that particular resource. However, be sure to remove the routes you won't need. Having extra routes can cause security issues, slow down your application, and make it harder to test your routes that you do need.

Make sure to use Postman to test your routes and error handling while you're building them. I literally forget that Postman exists every time I sit down to work on routes. But when I remembered, boy did it help! Having (or choosing really) to use your frontend to test a simple route really slows things down.

Validations and Error Handling ⚠️

Validations are the best way to protect your database and make sure that only the data that is supposed to be saved is saved! Even if it is just a presence: true validation. I would recommend validating almost every piece of information that the user is asked to input.

I choose to put my error rescue in the application controller along with the authorized method to keep my code DRYer.

class ApplicationController < ActionController::API
  include ActionController::Cookies

  rescue_from ActiveRecord::RecordInvalid, with: :render_unprocessable_entity_response

  before_action :authorized

  def authorized
    render json: { errors: ["Not Authorized"] }, status: :unauthorized unless session.include? :user_id
  end

  def render_unprocessable_entity_response(exception)
    render json: { errors: exception.record.errors.full_messages }, status: :unprocessable_entity
  end

end

And don't forget to use the bang(!) operator in your controller methods when you create! or save! to the database. The bang operator will raise an exception if the creation of the record fails (because of validations) which will allow for the custom error handling in your render_unporcessable_entity_response method.

byebug 👋

Don't forget about byebug! Sometimes I'm guilty of trying to debug my application by using only the front-end. But the more I needed to debug, the more the front-end only method wasn't cutting it. Using a byebug in your controller action can let you explore what is happening after each step before that response is sent to your frontend.

In the same vein, don't forget about the console! Using the command rails c in your terminal and exploring your data from time to time to make sure that everything looks ok. You can always write some class methods in your models to help with data exploration too.

Ask for Help! 🆘

Sometimes learning requires us to struggle through some challenges from time to time. However, sometimes the most valuable lesson can be to ask for help on something that really has you stuck. (I always need this reminder!)

Get Some Rest 💤

That's it. That's the tip.

I found that there were times where my brain stopped making sense and I would spend hours on one bug. I can't tell you how important it became to recognize when I had reached a point of diminishing returns while working on this size of a project and needed to call it quits for the day. Almost every time I woke up fresh in the morning and fixed the bug right away!

Good luck out there! We've got this.

Server Take the Wheel: Bridging the Mental Gap Between Front-End and Full-Stack WebDev

Kate Bennert — Mon, 20 Mar 2023 20:57:11 +0000

Where were you when you learned that the backend could do the work of a thousand frontends?

I'll tell you where I was. I was at (what I thought was) the end of (what I thought was) a very simple project where we were asked to create a backend with two relational models that had at least a one-to-many relationship, plus a React frontend to interact with it.

The models that I chose to work with were Jobs and Freelancers in that one Job would have many Freelancers. What I didn't realize at the time, was that my plan to create full CRUD capabilities for my Job model, would A. teach me so much about how the backend and frontend can work together and B. save my project from itself.

Up until this point I have been learning how to be a frontend developer. Our projects had consisted of a frontend that could interact with a static backend. In other words, in order to get any sort of functionality out of your app, you had to make requests from the frontend to predetermined endpoints that we couldn't manipulate.

Having quite a bit of practice at that sort of workflow, I very wrongly assumed that that was it for web development. Even after reading and learning about SQL, Object Oriented Ruby, and ActiveRecord, the idea that I had in my head was that backend tools like ActiveRecord were there to do all the heavy lifting of creating a backend while the end result would still be a static API with familiar but sometimes unhelpful routes.

I am very pleased to report that this is not the case.

After "completing" my project, I reread the directives we were given. I couldn't shake the feeling that I was really missing something - this didn't feel all that different than any of my frontend projects. Sure enough this line in the rubric caught my eye:

Don’t force the front end to do the work of the back end.

I took a look at my code again and did a lot more research. I was most definitely forcing my frontend to do ALL the work. For example, one of the functions I built before this realization focused on what I wanted to happen to the freelancers who were previously assigned to a specific job. I knew that I needed two things to happen: 1. the dependent job_id needed to reset to null and 2. the freelancer needed to be updated to available again.

How would a frontend thinker make that happen if they had not yet seen the light on how to make the backend do this work?

Answer: they would write PATCH requests. Which I wrote out below.

if (deletedJob.freelancers[0]) {
   deletedJob.freelancers.forEach(freelancer => {

  fetch(`http://localhost:9292/freelancers/${freelancer.id}`, {
    method: "PATCH",
    headers: {
        "Content-Type": "application/json",
    },
        body: JSON.stringify({
            is_available: true,
            job_id: null
        }),
  })
       .then(r => r.json())
       .then(updatedFreelancer => {                            
          freelancersToUpdate.push(updatedFreelancer);                           
          onUpdateFreelancerAfterDelete(freelancersToUpdate);
        })
     })
  }

Exhausting!

At this point I started to think there must be a better way. Did I listen to that gut feeling? No I did not. Onward!

Note that this approach was making a fetch request for EACH freelancer that was assigned to that job we just deleted and each time we were getting a response back from the server. Imagine if there were hundreds of freelancers working on a single project that was deleted? Not good!

Not only does that require a lot of pointless work from the developer, it takes WAY too much time. Especially for larger applications.

So how do we fix this problem?

Before we get there, just because I realized that this WAS a problem, did not mean I fully understood how the server could do this work for you. Despite studying class methods in Ruby and built in ActiveRecord methods, there was still a pretty big gap in my understanding when it came to how the frontend should interact with the backend.

If you really think about it, the server is there to communicate with the frontend. The frontend makes a request for data, the server sends a response. Simple. HOWEVER, what I was really missing is that magic that can happen with retrieving that data before the server sends back the response. Therein lies the solution to my earlier problem.

We don't need to force the frontend to do stuff with our backend data. That's what the backend is there for! Look back at those PATCH requests I was trying to make before and consider this "conversation" between the backend and the frontend:

Frontend: Hello I would like to delete this job please.
Backend: Ok I deleted it.
F: Ok I would also like you to now update the first freelancer on this job.
B: Updated.
F: Ok I would also like you to now update the second freelancer on this job:
B: Updated.
F: Ok now I would also like you too...
B: ...

Horrifying.

Now let's look at how that conversation should really go:

Frontend: Hello I would like to delete this job please.
Backend: Ok I deleted it. I also updated the freelancers associated with this job.

Wow so much better!

So how does that conversation look in the context of this application?

When you frontend makes a delete request to the backend 'jobs/:id' route here's what we'll need the server to do:

find the requested job
loop through the freelancers associated with that job and update them accordingly.
delete the job
send back the response

Here then is what that looks like in the controller:

delete '/jobs/:id' do
    job = Job.find(params[:id])
    job.freelancers.each do |f|
      f.update(
        job_id: null
        is_available: true
      )
    end
    job.destroy
    job.to_json
  end

So. Much. Better.

To take this one step further, ActiveRecord also has a way of telling the server what to do with an associated object's foreign key once that instance is deleted. This takes place inside of the model when establishing the relationship. In my case, I wanted to nullify my dependent foreign key:

class Job < ActiveRecord::Base
    has_many :freelancers, dependent: :nullify
end

By including those two words, I can do away with the job_id: null inside of the update.

WOW! We've come such a long way since we started!

For me this exercise was a gateway into learning how the server could do soooooo much more than I was asking it to do, but I know this is still only scratching the tiniest bit of the surface.

I look forward to learning more about how to manipulate the backend in future projects!

How to Make React Bootstrap Work For You (and Not Against You!)

Kate Bennert — Mon, 21 Nov 2022 19:59:23 +0000

I want to start by saying that I found Bootstrap to be an extremely helpful tool while building my project for Flatiron School - a single page application that uses data from a RESTful API to display curated menus and recipes. I chose to incorporate Bootstrap so I could focus on the Javascript functionality while also creating a finished project that was nice to look at. This was my first time creating a React app from scratch and I enjoyed getting to learn and use different Bootstrap components.

While experimenting with Bootstrap in the context of my project I encountered three challenges (and found three solutions!) that I wanted to detail for others who might be new to React Bootstrap.

First, a little about Bootstrap and why I chose to use it for a simple React app

Bootstrap, or React Bootstrap in particular, is a library of styled components that is easy to learn and use in simple react application. It also looks very clean, streamlined, and professional.

When faced with a totally blank slate for my second project for Flatiron School and a looming deadline, I researched some UI options that could help me with the styling so I could showcase my understanding (and passion for) the JSX side of things. I decided on Bootstrap after reading the documentation and looking through all the components. In particular, I liked the Carousel component for my homepage so that I could showcase featured images.

After I decided on Bootstrap, I got started by watching this awesome YouTube video by Adrian Twarog.

After getting everything up and running, I needed to figure out how to make React Bootstrap work for what I was trying to do. This brought me to challenge No. 1:

Using the React Router tag negates the Bootstrap CSS

This challenge turned out to be a simple fix. Here is a helpful blog post by a React Developer on the subject.

If you want to use react router with the Bootstrap styling, you need to install react-router-bootstrap in addition to react-router-dom. After, installing you can then import { LinkContainer } from react-router-bootstrap.

The key here is that you can now use the <LinkContainer> component to wrap the component you are trying to route to (instead of the react-router-dom <Link>. The result will be a router link that is styled nicely like the rest of your Bootstrap component.

Here is an example from my simple Menu Makr project:

import React from "react";
import { Container, Nav, Navbar, NavDropdown } from 'react-bootstrap';
import { LinkContainer } from 'react-router-bootstrap';

function NavBar({ handleNavClick }) {
  return (
    <div>
      <Navbar bg="light" fixed="top" variant="light">
        <Container>
          <LinkContainer exact to="/">
            <Navbar.Brand>MENU MAKr</Navbar.Brand>
          </LinkContainer>
          <Navbar.Toggle aria-controls="basic-navbar-nav" />
          <Navbar.Collapse id="basic-navbar-nav">
            <Nav className="me-auto">
              <NavDropdown title="Browse Menus By Occasion" id="basic-nav-dropdown">
                <LinkContainer to="/menus">
                  <NavDropdown.Item onClick={e => handleNavClick(e.target.innerText)}>Holidays</NavDropdown.Item>
                </LinkContainer>
                <LinkContainer to="/menus">
                  <NavDropdown.Item onClick={e => handleNavClick(e.target.innerText)}>Birthday Celebrations</NavDropdown.Item>
                </LinkContainer>
                <LinkContainer to="/menus">
                  <NavDropdown.Item onClick={e => handleNavClick(e.target.innerText)}>Pool Parties</NavDropdown.Item>
                </LinkContainer>
                <NavDropdown.Divider />
                <LinkContainer to="/menus">
                  <NavDropdown.Item onClick={e => handleNavClick("")}>All Menus</NavDropdown.Item>
                </LinkContainer>
            </NavDropdown>
              <LinkContainer to="/new">
                <Nav.Link>Create New Menu (Admin Only)</Nav.Link>
              </LinkContainer>
            </Nav>
          </Navbar.Collapse>
          </Container>
        </Navbar>
    </div>
  )
}

export default NavBar;

The resulting Nav bar will look like this. Styling still in tact!

The next challenge I encountered was that I thought I couldn't add any CSS rules of my own. I was wrong.

Using custom CSS in conjunction with built-in bootstrap CSS

This challenge was a classic case of me over thinking something. After, reading the documentation on customizing Bootstrap CSS, I walked away from it thinking that I would have to use SASS to style my custom components. This was not the case.

About halfway through the project, I became frustrated by the positioning of my main Carousel component. I decided to try grabbing the element in my index.css file and see what happens. Sure enough, after grabbing the Carousel by it's class name, I was able to position the component exactly where I wanted it:

.carousel {
  position: absolute;
  top: 5%;
  left: 10%;
}

Much better!

Disclaimer: I am still so new to Bootstrap that I do feel like some of the solutions I came up with are work arounds for me not knowing something. Suggestions of other solutions are VERY welcome!

The last challenge I encountered was understanding the React Bootstrap grid system.

Making the React Bootstrap Grid System Make Sense

On it's most basic level, the React Bootstrap grid system is made up of two separate components: <Row/> and <Col/>. Building a simple 2 x 3 grid would look like this:

<Row>
  <Col/>
  <Col/>
  <Col/>
</Row>
<Row>
  <Col/>
  <Col/>
  <Col/>
</Row>

Easy! But what happens if you don't know how many things there are? In my case, I was trying to arrange separate cards into nice rows and columns. My data was fetched from an API that could have X number of menus that needed to be displayed. After trying to squeeze <Col/> components inside my .map() that renders my menu cards (and subsequently struggling with trying to come up with a unique key for each column), the solution turned out to be the simplest one: just leave the number of columns up to the browser/React.

This was a live and let Bootstrap moment for me. Bootstrap is a wonderfully responsive UI system, one of the props of the <Row/> component let's you dictate that you want the widths of the columns to be "auto". It even let's you specify what you would like the grid to look like in different size browsers. (I specified only for medium (md) windows.)

Here is what that code looks like in the wild:

<Row md="auto" >
  {menus.map(menu => <MenuCard key={menu.id} menu={menu} />)}
</Row>

I was very happy with my decision to integrate Bootstrap with this project. My biggest takeaway from this was learning that there is no one-size fits all version of Bootstrap, but there are tricks to making this library do the work for you.

I think the result for me at this stage in my learning process was a cleaner, more streamlined and responsive front end in less time than it would take me to write custom CSS.

Plus, I really enjoyed the process of learning a new skill to complement what I have learned in my school curriculum.

It All Comes Back Around to the for Loop

Kate Bennert — Tue, 09 Aug 2022 19:05:29 +0000

Growing up my dad's favorite movie was I, Robot. "It all comes back around to I, Robot" he'd often say when other movies touched on similar themes or if interactive technology got a little too smart.

It's an adage that I've never forgotten and one that I also often find myself repeating. But why I, Robot? What is it about that story that make it so easy to refer to over and over again?

Perhaps it's a just a good allegory - a cautionary tale for the future of machine learning in a world that seems to get closer and closer to a robot revolution everyday (looking at you, Alexa). But - and before this becomes a book report - I'd like to think that the pervasiveness of this story (at least in my and my Dad's lives) really goes back to the fact that Asimov's Three Laws of Robotics raise an essential and basic ethical question that is so simple it can be applied over and over again in so many great stories: can morals be taught or - in this case - programmed? In fact, I, Robot is great to refer back to over and over again because it functions (for me at least) as a gateway to understanding and talking about more complex moral and philosophical concepts.

Or maybe it's just that anyone can find a way to bring up their favorite movie?

Either way, this blog post is meant to address what I see as the I, Robot of programming: the for Loop. More than anything else, this is a love letter to the simple for loop and how it has helped me work through so many puzzles as a brand new programmer.

So why the for loop?

First of all, this is not a post about choosing the for loop over the while loop. The while loop is great for when you don't know what your end point will be yet. I'm talking about choosing the simple for loop over some of its more advanced cousins including: the for...of loop, the for...in loop, and the array iterator method forEach().

There are two reasons why I always go back to the simple for loop when I am stuck. The first is that I know the simple for loop will always work. If I'm dealing with a more complex problem, I always start with a regular old for loop to get to a working solution. After I have a working solution, I'll look to refactor my code to include another version of the for loop that might be more suited to the task at hand.

The second reason is that the built-in iterator variable is always a number and numbers are easier to manipulate than other data types.

For example, let's look at an array of strings: const myWords = ["dog", "cat", "cow", "pig", "chicken", "fish"];

Say that we want to write a loop that will console.log each word of the array. Easy. Each element in the array will be accessed and used once:

for (let word of myWords) {
   console.log(word);
}

But now let's say we want to access another element of our array inside of our loop. What if I wanted to write a loop that joined every other word together. If we were to start off with a for...of loop, we'd have to define the other element we need in terms of the position of the current element in our iteration or add in a counter variable (essentially making it like a regular for loop anyway). For the sake of argument lets look at the former:

for (let word of myWords) {
   console.log(word + myWords[myWords.indexOf(word) + 2]);
}

Ew. Not only is that not great to write out, it doesn't leave us with very many options when we encounter the fact that the loop will keep executing even after we run out of words to concatenate. When we execute the code above we get:

dogcow
catpig
cowchicken
pigfish
chickenundefined
fishundefined

Not exactly what we're going for. If we had just started from a regular for loop, not only would it be easier to access the other elements in the array by defining their position relative to i, but also we'd be able to correct our "chickenundefined" problem no problem:

for (let i = 0; i < myWords.length - 2; i++) {
   console.log(myWords[i] + myWords[i + 2]);
}

Much better. Having the ability to manipulate the end point of the loop and use the iterator/counter variable gives us so much more flexibility. I find this flexibility to be so helpful when working through a new problem.

As I've gotten more fluent in JavasScript, it's been easier to tell more immediately which type of for loop is necessary and most efficient in a given scenario (psuedocoding helps!), however I find myself always returning to the familiarity and flexibility of the basic for loop to gain a little bit more understanding.

It all comes back around to the for loop.