DEV Community: Brennan Davis

Tailwind, Flowbite, React, oh my.

Brennan Davis — Thu, 06 Oct 2022 16:48:36 +0000

If you are familiar with CSS, you probably have found it slightly frustrating to troubleshoot your styling. You made your styling code in your css file, you double check your names or ids, then you open your browser to see if anything has changed. It's a laborious workflow. Fortunately, their are styling frameworks to help you style your front-end with ease. Specifically, Tailwind is a styling framework that can speed your up your workflow so you can worry about more important things.

Tailwind is a framework for css that uses class names to style your projects. The documentation on their website is very clear and concise.

To install Tailwind for React:

Make a new project:

npx create-react-app my-project
cd my-project

***It's important to be in your react directory when you install Tailwind.

Next install Tailwind:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

These commands will install taildwind, postcss, and autoprefixer. These allow you to use tailwind's classnames for your styling.

Next in your tailwind.config.js, add all these paths to your tailwind template file.

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./src/**/*.{js,jsx,ts,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Last step is to add these directives in your main CSS files (usually it's in './src/index.css'):

@tailwind base;
@tailwind components;
@tailwind utilities;

And that's it! Tailwind is installed. Let's go through some examples in how to implement this styling framework...

You Shall Not Pass: The Ins and Outs of Authentication

Brennan Davis — Sun, 18 Sep 2022 21:01:02 +0000

As I was finishing up my fourth phase at Flatiron School

we learned about how to make a login/signup feature on web applications using an authentication process. This phase in my software development program is centered around the fullstack framework Ruby on Rails. It's quite a power language that can do both frontend and backend programming.

The process to make a website secured through an login or signup authentication process can be very complicated. I definitely had some trouble getting this process down, so I decided the best way to climb this mountain was to write a blog about it to fully conquer authentication.

If you are familiar with Ruby on Rails, you probably are know about Gemfiles. They are project dependencies, similar to node modules, that have pre-made code that does a lot of heavy lifting for you, so you can focus on other aspects of your project. We will be using BCrypt.

BCrypt is a hefty gemfile that uses hashes and salts to encrypt passwords in your database. Hashes are a fixed-length value that will always produce the same output for the same given input. The output can be a 32-bit or 64-bit number. What BCrypt does, is add a salt to this hash, which is an additional 29-bit number that generates a new salt every time you login with your password. This method makes it incredibly difficult to hack into the database to reveal the actual password to a user.

Additionally, this gem adds three methods that the user model can use to read, write, and encrypt passwords:

password=
password_confirmation=
authenticate

As there are many ways to authenticate,

this is the method I have found to work (after a lot of troubleshooting). There is a lot to set up, but there is flexibility in how you implement your ruby methods and display your data in the front end. For this example, I am using Ruby v.2.7.4, Rails v.6.1.3 along with React v.17.0.2 and React Dom v.5 for my frontend framework.

Setup Work Flow

Install gemfiles

If you are starting a new rails project, these are some important gems to include in your Gemfile:

gem 'bcrypt', '~> 3.1.7'
gem 'rack-cors'
gem 'pg', '~> 1.1'

Something of note is that I use PostgreSQL for my database, and rack-cors as middleware. Rack-cors is usually needed when you are deal with separate frontend and backend projects that work through different domains. Theoretically if you are working on a mono-template, where both ends are in the same parent directory, you won't need rack-cors. When working through this demo, if you encounter any issues related to AJAX or CORS, I would recommend installing rack-cors in your gemfile.

bundle install to install all of your gem files. Additionally, don't forget to npm install all your node modules for your frontend (Use this command in your React folder if your local environment combines both frontend and backend in a parent directory).

Next,

we will need to configure Rails to create cookies and sessions (I highly recommend learning about sessions and how Rails interacts with, more info through the Rails Docs). Inside the configure/application.rb file include the following:

module MyApp
  class Application < Rails::Application
    config.load_defaults 6.1
    config.api_only = true

    config.middleware.use ActionDispatch::Cookies
    config.middleware.use ActionDispatch::Session::CookieStore

    config.action_dispatch.cookies_same_site_protection = :strict
  end
end

The last line that starts with configu.action_dispatch is important to include so that cookies are only shared in the same domain.

Moving on,

we need to add a line of code to our app/controllers/application_controller.rb file:

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

Create

a user model. I prefer using a resource generator to fast-track some of the coding. In your terminal in your project directory, use this command:

rails g resource User name email password_digest

This will create a user controller, model, serializer, and all CRUD routes in your config/routes.rb file. The column in your user table can be whatever you would like, but the password_digest column is vital to interact with bcrypt.

Add

this to the User Model file:

has_secure_password

This allows up to have proper validations for the password.

Whew, that was a lot to set up. Let's start writing some methods.

Sign Up Work Flow

Frontend display a signup form.
Client submits form, initiating a POST request to a create method.
The backend will make sure the data is properly validated. If it is, it will serialize a newly created object (a user row in the User table). If invalid, the server is provide error messages.

Before we talk about the frontend, let's deal with what the server side will do.

Although not necessary, it is advised to create a custom route for your users#create method, like this:

post '/signup', to: 'users#create'

Using a custom route will allow to continue to use the create method for the user controller if you ever need to.

In your User Controller

create your strong params, to control what the client can send to the database. In a private method, write:

  def user_params
      params.permit(:username, :email, :password, :password_confirmation)
  end

Then write your create method:

  def create
    user = User.create(user_params)
      if user.valid?
        session[:user_id] = user.id # this is the piece that logs a user in and keeps track of users info in subsequent requests.
        render json: user, status: :ok
      else
        render json: user.errors.full_messages, status: :unprocessable_entity
      end
  end

Let's breakdown this method:

We first declare a variable, that creates and saves a new User object with the user_params.
If the user takes in the valid parameters, it will create a new session, using the id of the newly create user variable. This session will allow the client to stay logged in throughout their entire experience using the web application.
If the user is NOT valid, it will render a json object of error messages that can subsequently be rendered by the frontend to display.

On the Frontend

this is how I used my frontend to control a form, use State to create a new object with the form data, and to make a fetch request on submit:

import React, { useState } from "react";

function Signup() {
  const [currentUser, setCurrentUser] = useState({})
  const [formData, setFormData] = useState({
    name: "",
    email: "",
    password: "",
  });

  const { name, email, password } = formData;

  function handleChange(e) {
    const { name, value } = e.target;
    setFormData({ ...formData, [name]: value });
  }

  function handleSubmit(e) {
    e.preventDefault();
    fetch(`/signup`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify(formData),
    }).then((res) => {
      if (res.ok) {
        res.json().then((formData) => {
          setCurrentUser(formData);
        });
      } else {
        res.json().then((errors) => {
          console.error(errors);
        });
      }
    });
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="name">Username:</label>
      <input
        id="username-signup-input"
        type="text"
        name="name"
        value={formData.name}
        onChange={handleChange}
      />
      <label htmlFor="email">Email:</label>
      <input
        id="email-signup-input"
        type="text"
        name="email"
        value={formData.email}
        onChange={handleChange}
      />
      <label htmlFor="password">Password:</label>
      <input
        id="password-signup-input"
        type="password"
        name="password"
        value={formData.password}
        onChange={handleChange}
      />
      <button type="submit">Submit</button>
    </form>
  );
}

export default Signup;

Important Note:
When I used the fetch in React, I had issues actually creating a session. What fixed this issue was using back-ticks for the URL in your fetch. I would recommend using these back-ticks as precaution.

One additional note about the front end is in the onSubmit function: after the POST request, this function uses a callback function called setCurrentUser that will set state to the newly created user object. That way you can use a useEffect hook to call this state upon initial render of the application. That way your front end will know if the current user is logged in when navigating through the webpage.

To Display User Information

We need to verify that the current user id matches the session id.

In your Application Controller, write a method to check if these two ids match:

    def current_user
        User.find_by(id: session[:user_id])
    end

Great, now let's focus back on the User. Create a new custom route:

get '/me', to: "users#show"

Inside your User model, add the appropriate show method:

def show
  if current_user
    render json: current_user, status: :ok
  else
    render json: "No current session stored", status: :unauthorized
  end
end

Because the current_user method in the Application Controller can be inherited in all children controllers, this method is using the current_user method to create a boolean return of either true or false. If true, then render a json object of the current_user's data.

Log In/Log Out Workflow

This is a similar workflow to the Sign Up process:

Write custom routes for the create and destroy for your Sessions Controller
Write the appropriate methods in your Sessions Controller.
Write the frontend code that practically mimics the Signup component.

If you don't have sessions controller already, use this command in your terminal:

rails g controller Sessions

Logging In...

In your config/routes.rb file:

post "/login", to: "sessions#create"

In your Sessions Controller, write a create method that would create a user variable that uses :params from the form in the frontend to find the appropriate user in the database. If the credentials match up, render a json object of the user variable. If they don't match up, render error messages:

  def create
    user = User.find_by(username: params[:username])
    if user&.authenticate(params[:password])
      session[:user_id] = user.id
      render json: user, status: :ok
    else
      render json: "Invalid Credentials", status: :unauthorized
    end
  end

Then write your front end to take in data from a controlled form and use a POST request to the /login endpoint. This code should look almost identical to the signup component.

Logging Out...

In your config/routes.rb file:

post "/logout", to: "sessions#destroy"

In your Sessions Controller, write a destroy method that will delete the current session:

  def destroy
    session.delete :user_id
  end

Your front end will fetch a DELETE request to the /logout endpoint.

AND THAT'S A WRAP. Take a couple deep breaths, it's as complicated as you think.

Final Notes

Go through this process slowly. Make you sure you understand every part of the code before moving on.
Think about work flow process for each feature. Go step by step, from the client side to the server side, to write your code.
If you get errors, use Google. Errors are your friend, you WILL debug your way through it.

Hopefully this blog has provided a little bit of clarity to authenticating. Thanks for reading. 'Til next time!

Everything In Its Right Place...

Brennan Davis — Thu, 25 Aug 2022 15:15:00 +0000

Hello again!

This is a going to be quite a departure from the usual technical post that I commonly sift through online trying to find the right syntax or how to properly use a Ruby method. I'm going to more or less be talking about, well, about a little band called Radiohead.

Full Disclaimer This post is a doozy, and I begrudgingly talk about myself so strap in...

This band has gotten me through many of my formative years and my relationship with their music has only aged like a fine wine. I was immediately hooked when my best friend in high school showed me "In Rainbows" back in 2008. He put on Weird Fishes/Arpeggios, and it was like Phil Segway himself gave 4 counts to kick off my entire obsession with this band.

From Thom Yorke's wispy, yet powerful soaring falsetto melodies, to Jonny Greenwood's arpeggiated strumming, Ed's backup vocals, Phil's drive on drums, or even how almost oxymoronic the spelling of the title was, I was invested.

I always found inspiration from Radiohead, no matter what avenue in my life I've been lead to. Music has been such a strong part of my life, essentially as far as I can remember (strong enough to make a career out of it). I played violin in elementary school, but only realized my true passion was playing drums at the end of the 5th grade. Once I "discovered" Radiohead (perhaps about 20 years into their career), they ignited an even more intense musical flame. I loved their used of rhythm, how they can use rhythm as their song structure, adding melodies that soared on top, how they used texture to drown you. They always produced music that no one else could conceive.

Throughout high school and even college, I used Radiohead as motivation and inspiration to perfect my craft as a percussionist. It never left me that no matter how technical you try to be, it's the emotion in music that makes it impactful.

Being a previous band director and life-long musician, I've played percussion ensemble literature inspired by Radiohead, I've play arrangements of their pieces, I even WROTE arrangements of Radiohead tunes for groups I've taught (most recently at the last concert I directed before moving to Colorado). I would watch movies that members of the band had written the scores for. Jonny Greenwood, with his immense knowledge of music theory and compositional techniques, has written soundtracks for Paul Thomas Anderson's films, must notably, There Will Be Blood and Phantom Thread. Drawing inspiration from 20th century Polish micro-tonal composer, Krzysztof Penderecki, the work that Greenwood has produced is, in my opinion, worthy of a Nobel Price.

Thom Yorke composed the score to the 2018 remake of Suspiria, using an entire orchestra at times, without having no knowledge of how to read or write music. All this to simply drive home the fact that I look up to Radiohead, but not only as musicians, but as creative types...

Leaving the music education field was definitively the hardest decision of my life. As you might have gathered, music has been a part of my life for as far as I can remember. Both of my parents are musicians and this is all I've know until very recently. It took a lot for me to accept that I can still keep my identity as a musician and not make it my day job.

Turn to now, I am finishing up my 3rd project at Flatiron School, studying to become a Full Stack Developer. I am LOVING all the new skills I am learning as a software developer. Not only technical, but how creative you can be with developing apps is fascinating.

On my drives to school

I will often listen to podcasts to pass the time (and to keep my mind off traffic on i25). I recently started listening to a podcast called "What is Music? A Music Podcast about Music" hosted by Adam Scott Glasspool, Steve Murphy, and Lucas Way. Hm, a music podcast talking about music, sounds like something I could get behind.

The latest season is discussing all things Radiohead. They go through their ENTIRE discography, song by song, and pick it apart. I have struck the gold mine. I've skipped ahead to their breakdown of the 2000 record Kid A, it's one of my favorite records of all time. This podcast is practically an academic research report, enriched with Radiohead lore and analysis.

They talk about things I never even heard of before; Radiohead was Internet pioneers back at the turn of the century. They were the first to stream their music on their website. Members of the band would blog during the recording of Kid A (back in 1998?!?), they would leak songs of this new record online, before their LP release, to give fans a taste to what to expect when they toured with the new album. They concocted an "anti-marketing" strategy, not promoting their new album through interviews and photo shoots, but through digital art manipulations with the help of Stanley Donwood, distorting paints and pictures of the band. They curated their own marketing campaign, to counter the global commodification of music.

They knew the Internet was going to blow up back, even as early as the 90's when they started releasing their music to the public online. I mean, they were Napster before Napter was NAPSTER. This wasn't the only time they used the internet for promotion. For the release of their In Rainbows, they set up a "set you price" store on their website for the record. Fans would purchase a digital copy at whatever cost they deemed fit.

Radiohead reinvented themselves through Kid A. Once known as a 90's grunge band, they all came to terms of Thom Yorke's visionary idea of relying heavily on electronics for this new record. Ed, the lead guitarist, is playing synths, Thom Yorke is using Protools to distort his voice in at least four songs, Phil is playing drum machines, Jonny using the Ondes Martenot on tracks, EVEN to manipulate Thom's voice! You'd think this was a John Cage inspired avant-garde group you'd see in a basement of a pizza shop in a college town (shoutout to J&J's Pizza in Denton, Texas, rest in peace).

Listening to this podcast, Radiohead gave me inspiration, but in a different way. Radiohead gave me the OK (Computer) to reinvent myself. It's a part of life, to change and grow and evolve. As I continue my education as a computer programmer, I'll use my background as a musician to help propel myself forward in the tech field, and to redefine who I am. Change is inevitable, and it's about what you do with that change that defines you. Everything is indeed, in its right place.

The KonMari method of JS: variables.

Brennan Davis — Wed, 03 Aug 2022 17:06:00 +0000

Have you ever

been in a mad-frenzy of code writing and you came back to it the next day and asked, "How does any of this make sense?" Have you ever looked at your code and thought it messy and unorganized? Well, there is a solution to all of your muddied code, and it's called variables.

Yes, variables are not a new concept for anyone who has even dipped their toes into computer programming, but variables are a huge helper in code consolidation. When writing out functions, think of variables as the your rooms to your home. Each room is typically dedicated to a specific purpose; the kitchen contains all your cookware, plates, silverware, while your bathroom contains all of your toiletries or self-care items. Essentially, rooms are containers for specific items with specific purposes. That's how you can start to think about using variables. If you have a function that can work on multiple features or event listeners, well then, use variables so you are not writing the same function over and over again. Let's get a closer look at this concept...

Say you want to display a collection of book information on a webpage. You want the user to be able to sort the books by different categories, either by book title, author, or publisher. So your book collection is set up in an array:

books = [
    {
        title: "\"The Hunger Games\","
        author: "Suzanne Collins",
        publisher: "Scholastic"
    },
    {
        title: "\"In Cold Blood\","
        author: "Truman Capote",
        publisher: "Random House",
    },
    {
        title: "\"Invisible Monsters\","
        author: "Chuck Palahniuk",
        publisher: "WW Norton",
    },
    {
        title: "\"Fight Club\","
        author: "Chuck Palahniuk",
        publisher: "WW Norton",
    },
    {
        title: "\"The Shining\","
        author: "Stephen King",
        publisher: "Doubleday",
    }
]

You want users to click different buttons to sort the collection by categories. After some simply HTML and DOM manipulation, with some CSS styling to pretty it up, here is what the webpage looks like:

Let's take a look at what the html code looks like for the buttons, this will determine how we write our functionality:

Notice that each button tag has its own id. This how we can grab each button in our JavaScript. We also added an in-line
onclick event listener function called "categorySort" that we will flesh out in a moment.

We could simply write a function for EACH button that uses the .sort() array method to sort the book array. For instance, our function to sort by title could look something like this:

const sortedArray = books.sort(
        function (bookA, bookB) {
            return bookA.title.localeCompare(bookB.title)
        }

This is fine and it will totally work, but this function will ONLY work for sorting by title. We will have to write two more functions that look exactly the same in order to sort by the other categories, the only difference is our dot notation will resemble the key we want to grab (book.author and book.publisher). What if we have more categories we wanted to sort? What if each object in our array contained 50 keys and we wanted our webpage to be able to sort by all of these keys? Our code would start to look unnecessarily long for one simple feature. That's where our friend variable comes into play...

Let's turn our key into a variable

so we only write ONE function for all three buttons. Now let's write our code for the "categorySort" function:

We first want to declare variable that takes the id name of whichever button we press:

function categorySort(event) {
    const category = event.target.id
}

We will need to pass the event as a parameter in the function declaration so we can use it for each button. The variable category returns a string which will match the proper key we are trying to sort by. We can use this variable in our sort function:

const sortedCategory = books.sort(
        function (bookA, bookB) {
            return bookA[category].localeCompare(bookB[category])
        }
    )

We declared ANOTHER that uses our previous variable to sort the books array. We will then pass sortedCategory to our bookDisplay function to re-render our display of books. The finished code should look like this:

Viola! We have successfully write one function for each button we created. If you are interested in looking at the full code, click this link to view my repo to this blog post.

As a more complicated example, we can also use multiple variables to write one function. If you are privy to React, we can write a function that will set state to multiple states. We would like to remove one item from an array, that is passed through as a parameter, and set state. So the code can look something like this:

function removeStateList(deletedItem, state, setStateFunction) {
    const updatedState = state.filter(item => item.id !== deletedItem.id)
    setStateFunction(updatedState)
  }

Now when we invoke the function we can pass whatever variables we want as arguments:

    removeStateList(selectedItemOne, stateOne, setStateOne)
    removeStateList(selectedItemTwo, stateOne, setStateTwo)
//etc...

We used three different parameters to write one function. It's coding MAGIC!

Takeaways:

Variables can be thought of as containers that can be used as a specific feature on your webpage.
We can use variables that make our code dynamic and to keep it DRY.
We can use multiple parameters in a function to avoid repetition.

Thank you for reading my post about variables. See you next time!

Say hello to my little (VERY helpful) friend: console.log()

Brennan Davis — Fri, 15 Jul 2022 19:25:08 +0000

If you are anything like me

you got into the tech field from switching careers. You wanted some different. You wanted a new challenge. You wanted to work in a field that is as inclusive as it's advertised. The start of my journey into software engineering was very exciting, but very daunting. You are welcomed with your first "Hello World!" and feel as if this new field will be streamlined, the learning will be a steady climb, and each new concept will be easier to grasp than the last.

...That was far from the truth. I was bombarded with new terminology, my progress was as uneasy as a sine wave, and every time I learned a new concept I felt like I was starting from scratch. Fortunately, it DOES get better.

The colloquial antidote "Practice Makes Perfect" is by far one of the best practice methods to learn a new language or concept in software development, but sometimes you can spin your wheels trying to solve a problem. I definitely encountered this numerous of times when I first started the Software Engineering program at Flatiron School (shout to Flatiron, if anyone is interested in a proven bootcamp, I would definitely recommend checking out their programs they offer.) I would learn a new topic, try to play around with the code, and attempt one of their labs. I would routinely be "stumped" and couldn't understand why I wasn't able to get my code to work. Fortunately, there was someone, or rather, something that was about to take me under its wing and show me the way of debugging.

Console.log()

is your friend! I use console.log CONSTANTLY when I am writing new code. It can help you uncover a wide array of errors, small and large. My golden rule when writing code is to console.log() almost every step of the process. Might be over the top, but I don't want errors to suddenly start popping up down the line when my code becomes much more complicated. Sometimes the error would be so small, and right in front of my face, I wouldn't be able to find it. That's where console.log() can really save you a lot of time and frustration 😅. Let me show you the method to my madness...

Let's say we want to use JavaScript to set up some event listeners to two buttons that when pressed, will either add or subtract a number by one in a

element. If you are interested in looking at the full code for this example, click this link. So here is my HTML code that I have set up for this example...

The image above is my HTML that wrote in VSCode. The two things to pay attention to are the id names and the location of my <script>. The id names for the p and two button elements are important because I will reference them in my JavaScript. The script tag is in my head element. If you are going to put your script in your head, it is highly recommended to use the defer attribute, so your JavaScript loads after the HTML page has been loaded. That way, JS can see what it's going to use its functional magic on.

Moving along, once we set up our HTML file, and we have our script in and ids, I was to first our FIRST console.log() to make sure everything is working. Write this line of code in your .js file:

console.log("I am connected!")

Next, open up your HTML file in your browser (don't forget to save your files!), open up your Dev Tools (right click > Inspect if you are a Mac user like myself), and see what the console has told you. Hopefully you will see this message below:

Congratulations! You have your first successful console.log()! What this console is saying to you, is that you have successfully connecting your .js file to your .index file. Imagine writing ALL your JavaScript code and just to simply get a message that reads "ERR_FILE_NOT_FOUND". You would pull out all of your hair.

Moving along, let's now target our ids and create variable names, using document.querySelecter (.getElementById will also work in this case!) After our variable declarations, you should...YOU GUESSED IT! You should console.log() to make sure you targeted the right elements.

let add1 = document.querySelector('#add1')
let subtract1 = document.querySelector('#subtract1')
let counter = document.querySelector('#counter')

console.log(add1)
console.log(subtract1)
console.log(counter)

Once your saved your change, refresh your browser, and your console should say this:

Your console has pinpointed your elements, you can hover over each to make sure it's the right element. I find this a necessary step, because if you misspell on of your target, or use wrong syntax, your console will tell you which line is disrupting the code.

Great, we have our variables, now we need to set up some event listeners to tell JavaScript to listen for a click to then invoke our functions:

add1.addEventListener('click', counterPlus)
subtract1.addEventListener('click', counterMinus)

Try to think ahead of my steps and you'll discover....yes I'm going to console.log() to check that my event listeners work. The functions I have written above simply have console.log():

function counterPlus() {
    console.log("I was clicked!")
}

function counterMinus() {
    console.log("I was clicked!")
}

Awesome! My event listeners work! Let's pick up the pace...

I've set up my code for the counter functions, but I stumbled into a problem. I'm getting an error message:

What? I was confident my code works. Let's click on the index line reference on the right side of the console that reads:

index.js.8

Take an extra close look at the function declaration, what do you notice?

No () in the declaration! How does JavaScript know it's a function without it? Thank you console.log(). After some slight edits to my functions we have:

function counterPlus() {
    counter.textContent = Number(counter.textContent) + 1
}

function counterMinus() {
    counter.textContent = Number(counter.textContent) - 1
}

And Voila!, our code works!

Takeaways

While console.log() is a simple tool that helps you log your code, it can be a powerful tool that can save you a lot of time and energy wasted on a small mistake like a syntax error. This blog post was a minute example of how you can use console.log(); it can expose what's under the hood that you might not initially realize. Console.log() every step of the way!

If you have made it this far, thank you for reading my 1st tech blog post.

'Til next time!