Forem: LaurenTyson🕶

Authenticating Users in Rails

LaurenTyson🕶 — Sat, 14 Jan 2023 03:27:36 +0000

Logging in.

All websites do it, and as internet users, we don't think about logging in or logging out or weird things like creating a "user session." 😵‍💫

But all of that goes on in the backend in Rails.

Think of websites like the club; they use a "stamp." You arrive, and the bouncer checks your id and gives you a stamp. If you leave and come back later (...maybe after visiting that White Castle), the bouncer doesn't recheck your id; they just check for your stamp. You can get a drink at the bar because your stamp proves you're old enough and have already been checked in.

Website example of the stamp pattern ✋🏽:

You log in at etsy.com. Etsy's servers authenticate you.

If your credentials are correct, Etsy's servers issue a cookie to your browser.

If you visit another protected page on Etsy, your browser will show the cookie to the server; the server verifies the cookie and lets you load password-protected info and browse in a logged-in state.

As developers, we describe this process as authentication. When we talk about authentication in our applications, we're describing how an application can confirm that a user is who they say they are.

How to authenticate users in Rails:

For a Flatiron boot camp project, I created a rails app called dogGo! which allows you to view and review dog walkers.

At the core of this app is authentication. We don't want someone walking in the front door of this app without signing up and logging in. So this is how I built that functionality:

The user navigates to my homepage, which in my case is React.
The user enters their username and password.
POSTing to /login or /signup on the Rails backend
If the user is signing up, then we are going to CREATE a new user with a secure password. If the user is logging in (checking their stamp) then we are going to CREATE a new session with a cookie:

Sign up:

Login:

IMPORTANT: Typically, your create login method will look up a user in the database, verify their login credentials, and then store the authenticated user's id in the session.

What the component might look like on the frontend

When the user submits the form, they'll be logged in! Our callback function would handle saving the logged in user's details in state.

Staying Logged In

We've shown our ID at the door (username) and gotten our stamp (session[:user_id]) from the backend. So our backend has a mean of identifying us with each request using the session hash.

Our frontend knows who we are, because our user data was saved in state after logging in.

BUT - what happens if we refresh the page in the browser? Well, the frontend doesn't know who we are anymore since we lose frontend state on page refresh, but the backend know who we are - so we need a way of getting the user data from the backend into state when the page firsts loads.

First, we need a custom route to retrieve the user's data from the database using the session hash:

And a controller action:

Then we can try to log the user in from the frontend as soon as the application loads, else return a login screen:

Logging Out

It's simple to make a log out flow:

Add a new custom route for logging out:
Add a new action in the session controller, which will clear the username out of the session

Add the code on the frontend. A button in the navbar perhaps:

In this example, setUser callback function would handle removing the information about the user from state.

Ok, lets all go enjoy those White Castle burgers while we wait in line to get back into the club 🍔

Using the Faker Gem to Populate your Database

LaurenTyson🕶 — Tue, 01 Nov 2022 21:23:02 +0000

When building an application, using realistic data is a good idea. But where should you get that data, and how should you add it to your database? There are a few different gems that accomplish this, but Faker is the gem I like and used for a recent Ruby project. Let's walk through how to use it.

What is Faker 🤔

Faker is a Ruby gem that generates fake data that you can use in your database. Per Faker's GitHub page, the gem is a "library for generating fake data such as names, addresses, and phone numbers." You can even use the gem to randomize boolean values, Lorem text, and dates - it's convenient if you need a quick way to get your database going.

To use Faker in your app, follow the instructions in the gem's README, but I found it straightforward. Just install it in your project's folder via your command line like this:

After installing, you'll see Faker included in your Gemfile, which you can group like I did with the other gems needed to run your app! You're good to go.

Seeding your database 🌱

Adding data to your database is called seeding. I think of seeding as planting data into my empty tables. Remember 👉 creating and defining your database tables is called migration, but those migrated tables start empty, so seeding is how you add data to the tables.

The code used to seed is in its own file called seeds.rb. There is where you write your Ruby methods to plant your Faker data.

I needed Faker data to create my app, Hipster Hire. A fun "job board" that lets users post a job and hire a hipster. I had a ton of fun building this, mainly because the fake hipster data I got was hilarious. A bunch of buzzwords used to make a "hipster bio."? LOL, yes, please.

My app had two Ruby models, a Job model, and a Hipster model - a Job belongs to a Hipster, and a Hipster has many jobs. My database needed fake but realistic job information like title, company name, position, etc., and Hipster information like name and bio. I also wanted to start with some Hipsters already employed and some jobs open and ready to hire a hipster!

Planting your seeds 🪴

It was easy to pick out the Faker data I needed; the gem's GitHub page lets you drill down into the different fake generator categories to see the available methods. I picked the information I wanted and added it to my seed file; more on that in a minute. In GitHub, each Faker line is written, for example, as Faker::Hipster.sentences. This format means that Faker has a static inner class called Hipster that you're extending. And the information after the dot is the specific method called:

Faker::Hipster.sentences #=> ["Godard pitchfork vinegar chillwave everyday 90's whatever.", "Pour-over artisan distillery."]

From there, how you construct your seed file depends on your table structure and your plan for your app. Once you decide, use the seeds.rb file to add data to the database, all you need to do is write code that uses Active Record methods to create new database records.

In my app. I needed 25 open jobs, so the hipster_id foreign key starts as nil:

I also needed ten hipsters with anywhere from 1-3 jobs. Fortunately, in Ruby, the rand() method accomplishes that - it's a class method that generates a random value between the numbers specified. In this nested method, I'm saying, "generate ten hipsters, and for each hipster created, generate for each of them between 1-3 jobs":

Pretty cool!

Fake it until you make it 🤭

One tip I learned in my coding bootcamp, Flatiron, is to add...

puts "🌱 Seeding..."

[seed code here…]

puts "✅ Done seeding!"

...at the top and bottom of my seeds.rb file because seeding your database doesn't inherently produce anything in your terminal. So to know when the seeding starts and when it's finished, add some simple output like this 👆

The final steps ✅

In my app, I'm using Sinatra, a lightweight framework written in Ruby. It's simple but powerful and flexible, so to populate my database, I ran this command after migrating my tables:

bundle exec rake db:seed

Pro-tip 👉 if I ever need to remove all the data from all my existing tables and rerun the seed command, I have this command:

bundle exec rake db:seed:replant

That's it, and my database tables turned out great! Perfectly randomized fake hipster data. Rad 🤘

PS. this is a snippet of how my Hipster Hire app turned out.

Constructing Search & Filter Functionality in React 🦄

LaurenTyson🕶 — Tue, 30 Aug 2022 18:49:08 +0000

Search and filter functionality is straightforward, yet I often need to refer back to documentation. The biggest thing to remember is the information flow between the components - where does state live, where it's passed, and sending data from a child component to its parent via a callback function. At first, this functionality can feel like a confusing loop, but after you construct components like these a few times, the basic steps get easier to remember.

Recently I built a React app from scratch as a coding Bootcamp project. The app is called Scientific Foodie, a database that shares scientific information about all different types of food, such as fruits, vegetables, grains, gourds, and more:

Because I was building a database, I decided to have search and filter functionality so users could interact with the database to the fullest.

In this app, my Search and Filter components work in tandem, so below, I walk through the steps of constructing each component and how I, and here's a hint, chained them together.

And since my Search and Filter components are siblings and children of my FoodContainer component, I determined that FoodContainer would hold state and handle the callback functions. Why? Because sibling components can't pass data to each other directly. Data can only flow up and down between parent and child. Therefore their parent component, FoodContainer, will hold state and handle the overall functionality.

Making your Filter Component 📌

Once you have the basic JSX written, i.e., what you're filtering by, it's time to construct the functionality. The value of your filter options should match the data key you're filtering. My app filters my food by group.

In your parent component, create state that will capture the user's selected filter. I like to set default state for my filter to "All," which is the first option in my Filter component. "All" ensures everything displays upon page load, and while filtering, the user can return to seeing everything at any point.
Next, we'll create a simple callback function to handle capturing the event.target.value, which is the filter change, and updating state. Initially, I always set my helper function to console log the selection, just so I know my callback is working — more on this in a minute.
Pass the helper function as props from your parent component to your child, the Filter component. This allows the callback to be owned by a different component than the one invoking it.
Filter functionality takes an onChange event. Simply assign the helper function as props to onChange. Each time a filter option is selected, the value is passed up through our helper function to our parent component.
Try this out to make sure it works! How will you know? Remember, we have a temporary console log in the helper function in our parent component. In your app, select a filter option and see the value logged in your console. Again, make sure your option values match your data.
Now that you know the callback works remove the console log and replace it with your state's setter function. And add one more temporary console log to check the value of your state variable. In your app, select a filter again, and you'll see your state capturing the change in filters in the console! Finally, remove the console log.

Making your Search Component 🔎

Leaving the Filter component aside, for now, let's construct our Search.

Set up state in the top-level parent component, in my case FoodContainer. The default value for your search state should be an empty string.
Create a simple callback function to handle what's typed in the search bar. As we initially did with our filter helper function, set your search helper function to console log the text in the search bar. We want to make sure it works.
Next, your Search component should take two props, the search state variable, and the helper function. We're passing state down as props because we're constructing a controlled component.
In your Search component, the value should take the search state variable as props, and your onChange takes the helper callback as props. Your helper is capturing the event.target.value.
Try this out to make sure it works! With the temporary console log in our search helper function in our parent component, type something into your search bar. In the console, you'll see each keystroke logged as a single letter at a time. That's ok! We're not updating state just yet; we're only console logging to ensure the callback is working correctly.
Next, remove that console log and replace it with the search state's setter function. Then add one more temporary console log to check that your state is updating correctly and type again in the search bar. You'll see the text in the console and the word forming in the search bar. Cool! Because this is a controlled component with state assigned as the search value, the letters appear in the search bar as you type, aka the user is watching state update in real-time.
Finally, remove that last console log.

Chaining Filter and Search together ⛓

The last step is updating the items displayed on the page based on what's being searched and filtered. In my case, I want my users to search for a specific food in the database based on the food's common name, filter by food group, and do these actions together.

My parent component FoodContainer handles displaying my food on the page, so that's where I added the following code:

Declare the variable that holds the array you'll map over. I originally mapped my entire foods array, but that array didn't have my search and filter logic built in. So, I created a variable that handled my search and filter; this array will be mapped to display my items instead.
Write an if statement. If the selected filter is "All," then all of the elements in the array will return. This is written as return true. Otherwise, return the elements that match the user's selected filter.

We could stop here; however, we want search and filter to work together so the user can utilize both. A couple more steps:

Next, chain on another filter. Now our variable, foodsToDisplay, takes both the filter and the search code into consideration instead of one or the other. Chaining methods is essentially calling methods one after another in one statement, allowing your code to be concise and the logic to continue.
In my case, I'm allowing users to search for foods by common name. includes is added because I want to return partial matches as the user types. Finally, I'm converting the common name and the search to lowercase so capitalization doesn't get in the way.

TLDR 😎 - either the user searches through all the foods or searches a filtered selection.

Now, finally, let's map over the new array! Once done, try out search and filtering in your app. It's pretty cool.

So how did it go for me? Here's how my React project turned out:

Utilizing a Nested GET Request

LaurenTyson🕶 — Sun, 03 Jul 2022 21:57:07 +0000

I'm a Flatiron Bootcamp student, and at the end of my first bootcamp phase, I was tasked with building a one-page web app with JavaScript, HTML, and CSS utilizing a pubic API. I decided to create a cocktail recipe generator from the API The Cocktail DB, but the data I needed from my API was at two different urls; the second url being dependent on the first one. What to do 🤷‍♀️

As a beginner, fetching data from a server can feel intimidating. Fetch requests default to GET requests which fortunately is pretty straightforward - you're sending a request via a URL to the server for data. The basic syntax for a GET request is something like this:

But if you're like me and need data from two urls then that's done with a nested fetch. Let's walk through the process👇

Nested fetch has entered the chat

To start, dig into your API urls to see what data is accessible and how you'll be able to request it. When looking at The Cocktail DB's urls, I found I needed one url that returned a spirits array based on the user's spirit selection, but that array didn't give me the complete ingredients for a specific cocktail. A different url returned the full recipe accessible via the drink ID. The drink ID was in my first url, which meant my second url was dependent on my first - 😅 whew!

snippet of first API url:

snippet of second API url:

Fortunately, the path of a url can be interpolated to dynamically get what we need based on an input. This is the starting point to building a nested fetch; the code that set's up your second fetch is inside your first fetch's second .then. I'll show you in a code snippet below.

Adding logic to your second `.then`

My app generates a random cocktail based on the user's mood and spirit choices. Mood is just for fun; my app is primarily built on spirit selection. So for example, lets say my user selects vodka as their spirit. My first fetch makes a request to the server and returns an array of objects of all the vodka cocktails on the server. Each object in that array has a cocktail name, an image url, and drink ID. I need the drink ID for my second fetch because my second url requests a cocktail by its ID to return the full recipe details.

url of my first fetch interpolating the user's spirit selection:

A cool thing about my app is that it generates a different drink each time the user makes their selection. By utilizing Math.random I'm able to grab a different drink id from my first array every time my code block runs, even if the user selects the same spirit multiple times 😲:

selecting random drink id from my array after first fetch:

✅ To put it together, here are all the steps I took to build my nested fetch:

My first fetch returns an array of drinks array based on a user's spirit selection
I map over that drink array to return a new array of just the drink ids
I select a random drink ID from that array by using Math.random
But - I need the value of that random drink ID, so I access that value using bracket notation
That value is the server's drink ID that I need for my second GET request. I interpolate that value as the path of my second fetch url.
My second fetch returns a complete recipe for a single cocktail.

my total nested fetch code:

And if you want to refactor your nested fetch so it's a little more readable, you can break out your second fetch into it's own function, like this 👇

my total nested fetch code with second fetch as separate function:

To build a nested fetch you don't need to randomize your results as I do with this app. You can do whatever you like with your data. Just know that your second fetch depends on the data you receive from your first fetch and utilizing interpolation allows the path of your fetch url to be dynamic.

Once my full recipe returns from my second fetch, my app continues to run. The code in my last .then invokes my functions that render my user's cocktail to the page.

🍹

A couple of things to watch out for with nested fetches

Watch your logic when interpolating the path of your second url. Can you actually request what you specifically want with this path? Test all the possible paths in your browser.
Fetches are asynchronous code, so double-check the rest of your JavaScript outside of your fetches. If you don't want specific code to run until your second fetch returns, then put that code in a function(s) only to be invoked at the end of your second fetch. Like this:

Add console logs to your fetches to double-check that the data you're returning from the server is actually what you want. Remove those console logs once you know what's being returned is correct.

That's it! Nested fetches aren't that intimidating once you spend some time with your API to know where your data is and how to access it. Then walk through your code logically and check along the way to ensure you're returning what you expect.

So how did it go for me? Here's how my project turned out:

How to learn something really fast: the life of a bootcamp student

LaurenTyson🕶 — Sun, 19 Jun 2022 16:58:20 +0000

Learning to code in a bootcamp is the hardest thing I've ever done.

I'm a Flatiron bootcamp student. Since I work full-time and don't live near one of their campuses, I opted for their part-time online program, Flex. Graduation date: Feb 2023 🙌

I've always considered myself a person who can learn anything, especially when I set my mind. As a kid, I taught myself how to paint and draw. As an adult, I taught myself data analytics after I got a job as a data analyst.

Honestly, Google can teach anybody anything.

So when I decided to pivot my career to software development and joined a 10-month bootcamp knowing that it'd be fast-paced and challenging, I approached this challenge like I have others. Inner me was like:

But now, about six weeks into the program, I've realized a new truth - learning something new very quickly is hard and uncomfortable. I wasn't at all prepared for those feelings.

Typically when learning something new, like a language, cooking, or even knitting, you have time to review documentation, practice your developing skill as much as you like, and maybe take a day, or several, off from that skill to give yourself time to breathe. Over time your ability to quickly recall how to do that new thing becomes faster and better.

What's different about learning to code in a fast-paced bootcamp is that the pacing is so quick that I don't have time to go back and review lessons or practice as much as I like. I don't have time to make myself more comfortable. Instead, I have to trust that the information is in my brain (waves around)...somewhere. The bootcamp experience feels like I'm in a constant state of motion, running on swaying ground. I never feel solidly grounded.

So when I say learning to code in a bootcamp is the hardest thing I've ever done, it's not necessarily the concepts I'm learning that are hard; it's how fast I have to learn them.

Now, I'd still recommend learning to code in a bootcamp like Flatiron. The lessons are solid, the teaching method is practical, and my engineering friends tell me that I'll come out of the program probably knowing more than them (haha, awesome).

Tips for learning how to code really quickly👇

Code every day. Seriously Every. Day. Even if all you have is 30-60 minutes to work through your lessons. Repetition is essential, especially when learning something technical. Coding every day will help reinforce those developing brain pathways.

Ask for help when you're stuck. Whether it's asking Google, another bootcamp student, or your teacher. When learning fast, you don't have time to wallow too long in "figuring it out on your own" or feel shy or defeated for asking for help. It's best to keep learning and moving through the material. So when I'm stuck getting my tests to pass a lab or when a new concept is challenging to wrap my head around, I give myself about 30 minutes to figure it out on my own before seeking help. The help nudges me in the right direction then I can figure the rest out. It's also a confidence boost because sitting alone at my desk with no movement is defeating. Reach out to others when you need it so you can keep going.

Make flash cards. A tried and true method, I love flashcards. Why? Because as I said before, repetition is key to learning something quickly. I keep my flashcards with me and work through them throughout the day while cooking, cleaning, and working my full-time job.

Evaluate your priorities. Once I realized how uncomfortable learning to code this quickly would be, I realized I needed to prioritize the bootcamp and deprioritize other activities because there's only so much time in the day. I made a list of what I was doing with my time outside the bootcamp and work and deprioritized things like TV, podcasts, and sleeping in so I could spend more time coding. It was hard to drop some of my favorite activities, but it's only temporary while I'm focused on learning code. Then I communicated my new focus and priorities to my husband and friends, so everyone is on the same page.

Confidence and self-love. I have to tell myself out loud daily that everything will be ok. And I've been working on believing that I know more than I do. It's hard, but filling your head with constant positive reinforcement will help you tremendously to have the confidence to keep going. Here is one of my favorite Ted Talks on self-confidence and the importance of repetition; check it out! The skill of self-confidence | Dr. Ivan Joseph | TEDxRyersonU

Alright, that's it. Get out there and learn something new. With repetition and some self-love, you'll be able to do it even if the pace is fast.

JavaScript typeof null likes to play tricks

LaurenTyson🕶 — Sat, 21 May 2022 14:02:04 +0000

As a newbie coder, everything is confusing. I'm always like, wait - what? That was precisely my thought when I asked JavaScript typeof null, and it told me object.

Huh?

If null is an object, and objects are a collection of properties, that would mean null has some value. But we know that's not true; therefore, this is JavaScript playing a trick on us. Let's break down why.

`Null` isn't an object.

Null is just, null. In JavaScript, null is a structured root primitive value. It stands by itself. It's the absence of value, unlike undefined which is an empty value—two different things.

Then why does JavaScript return object? Because according to MDN, JavaScript values are represented as a type tag and a value, and the type tag for objects is 0 thus lumping null in as an object.

As we can imagine, representing the absence of value is tricky; as an aside, in other programming languages, null is represented as the null pointer 0x00. Reference.

In an effort to fix this bug, in 2015, when JavaScript went through its rework it was proposed to change to typeof null === null. Unfortunately, that fix was rejected, but honestly, for a good reason. ES Wiki, the web archive for the ECMAScript programming language, says:

"This proposal has been rejected. It was implemented in V8 but it turned out that it broke a lot of existing sites. In the spirit of One JavaScript this is not feasible."

Check out the ES Wiki page I'm referencing, the full explanation is fascinating.

Since developers have always known of the typeof null bug, many people wrote their code to account for it. And while the proposed fix would have fixed our brains, it would have broken our apps.

So now we newbies know of this bug too! Don't let this break your brain as it did mine. It's just one of the many fascinating oddities of JavaScript programming.