DEV Community: Josh Blengino

Uploading files in a React/Rails App using Active Storage

Josh Blengino — Tue, 28 Sep 2021 05:23:41 +0000

Uploading files is a common thing that we do on the internet. Uploading images to Instagram, uploading audio files to SoundCloud, uploading videos to Youtube, uploading images to this blog, etc. If you are looking to integrate a feature like this into your React/Rails application, I got you. In this blog I will be using postgresql for the database and I will be dealing with audio files such as mp3, wav, etc. Thanks to Active Storage, the process for doing this is not as complicated as you might think.

Backend setup

Run this in your console:



rails active_storage:install

This will create 2 tables that you can view in your ./db/migrate folder, then run:



rails db:migrate

If you check your schema this is what you should see:

Don't worry too much about these for now, I will be linking other helpful blogs at the bottom that explain more in detail about how these tables work under the hood if you want to know more.

has_one_attached macro

This macro will magically associate a file attachment to whatever model you apply it to. In the context of this example, I want a user to be able to upload beats with an audio file attached. You can name the macro whatever you want I just decided to call it :audio_data (e.g. :audio, :audio_file, :image, :picture, etc) I recommend naming it with a description that matches the type of file you are going to be working with:

Controller

Make sure to add it to your controller params:

Serializer

Your serializer should look something like this, make sure to include line 2 and just replace audio_data with whatever you named it:

Frontend setup

Now that our backend is ready to handle the upload from the frontend, let's create a basic form:

State

The form

input's accept attribute - we are setting the value to "audio/*" which allows a user to upload all audio file types. Use "image/*" for images and "video/*" for videos.
onChange - with file uploads, they are going to be stored in an array called files. Because we are only uploading 1 file we just access our file at the [0] index.

Making the POST request to our backend

Files require different packaging than your typical JSON.stringify(). We need to send the body as formData by creating an empty formData object and then appending our state to it. The right side of the comma is our state we had at the top, make sure the left side of the comma matches what you have in your schema. Don't bother trying to console.log the formData object either, you will just get an empty object.

Rest of the code

Just fetching a user and setting it in state to provide a user_id, also fetching from beats to use in the audio player.

Testing it out

Making a GET request in Postman

BOOM!! After submitting, you can now make a GET request to your server and see that your upload was successful!

Enjoy the fruits of your labor

Clicking that play button is a great feeling. Now go sicko mode and unleash your new file uploading powers!! Below are resources that really helped me accomplish this, please let me know in the comments below if there is anything important I may have left out.

Resources

HTML input accept Attribute - W3Schools
FormData() - MDN
Using FormData Objects - MDN
Active Storage
How to upload mp3s to your rails backend using active storage
React File Uploads to Rails
Upload images to your Rails API from React the easy way
React Audio Player

Polymorphic Associations in Rails

Josh Blengino — Wed, 08 Sep 2021 18:32:56 +0000

When setting up an API in Rails it is crucial to establish how all of your models are going to be connected to each other using Active Record Associations. Polymorphic associations are a little more advanced but can be very useful when your application becomes more complex.

What is Polymorphism?

This is a new concept for me and so far I have learned that polymorphism is a core concept in Object-Oriented-Programming that can be used in many different contexts. This blog will be focusing on this concept in the context of building a Rails API. We can get a more clear understanding of this concept by breaking it down into its Greek roots:

If something is polymorphic it has many forms. For example, numbers in Ruby can be integers(whole #'s), or floats(decimal #'s). A polymorphic association in Rails allows you to associate a single model with multiple models through one association declaration (instead of having multiple belongs_to associations).

Where could this be useful?

Let's say you are building an app that allows users to post content, comment on other posts, and like other posts. Pretty common features that we are all familiar with. Now you want to extend the like feature to comments allowing a user to like individual comments. Your ERD might (or might not) look something like this:

Something like this would work fine, but if you wanted to extend the like feature throughout your app to potential new models in the future you would need to create a separate likes table to the database for each new model you introduce. Overtime this could unnecessarily crowd your database and will end up becoming a repetitive task.

Polymorphic associations

With polymorphic associations we can create a poly_likes table that will act as an interface between other models we want to associate likes to. This isn't the greatest looking ERD but it is looking a little better. Now everytime we want to introduce a new model, we don't need to create a separate likes table to go with that model.

Creating a poly_likes table

To create our new model in the terminal we are going to include an interesting column/value pair.

What does the migration show us?

Lets run the migration and check out the schema

What about the model?

If you're seeing all of this for the first time the syntax might seem a little weird. Why are our associations named with "-able"?

Naming convention for polymorphic associations

If you're familiar with Rails you know that sticking to naming conventions is part of Rails' magic. To make all of this work, Rails uses "-able" with the class name to name polymorphic associations. Basically what we are doing here is making a comment and a post "likeable". Let's make sure the rest of our models are set up to make all of this work:

PLEASE correct me if I am wrong, but I left out the "as: likeable" from the user model because that would make a user likeable which is not what I want in this situation (who knows maybe you want to allow a user to be liked). In this situation I just want a poly_like to be associated with a specific user.

Testing it out in the console

If you take a close look at the query being generated it is looking for a poly_like that has a user_id which is what I wanted. In these examples I did not create any poly_like seeds so we are getting back an empty array, but we can focus on the queries to see how these associations are working.

Now let's check a comment and a post

If we look at the queries again we can see that the likeable_id matches the id of the respective object and the likeable_type references the model type in the form of a string!

Pros

Keeps our code DRY by not having to use a bunch of repetitive belongs_to or has_many associations across all of our models.
Prevents you from needing to modify existing models and/or adding new join tables to create associations with newly introduced models. (Ex: we did not have to add a separate likes table for the comment & post models like we did in the first ERD.)
Makes it easier to add new relationships.

Cons

Syntax could take some getting use to at first.
No foreign keys.

Conclusion

Polymorphism might be a little tricky to wrap your head around at first, but it is really just a fancy word for saying an object can be related to many different types of objects. In my short experience with polymorphism I can see why this a powerful concept but it is probably not necessary for every situation. I am not an expert on this topic and I used this blog as an opportunity to learn an important concept. Please let me know in the comments below if there are any corrections I need to make to this post or if there are some other practical use cases where polymorphism could really come in handy. Hopefully this post made polymorphism more approachable for you. I linked some very helpful resources below that really helped give me a fundamental understanding.

Resources

https://www.youtube.com/watch?v=pTB0EiLXUC8
https://www.youtube.com/watch?v=SjUVEUCMoX8
https://www.youtube.com/watch?v=5EidzTqsw-E&t=620s
Polymorhpic associations
freeCodeCamp blog on polymorphic associations
Stackoverflow polymorphism

Halftime: Trusting the Process during a coding bootcamp

Josh Blengino — Wed, 25 Aug 2021 20:01:49 +0000

The purpose of this blog is to share my experience @Flatiron School so far, for anyone out there who is new to coding and seriously considering applying to a coding bootcamp. I am writing this in hopes of helping you decide if a coding bootcamp is the right option for you. If you are reading this or another blog post like this, that shows that you are serious and care about what you do, which is a step in the right direction and something you should feel good about while navigating through the uncertain territory of a potential career switch.

If you haven't heard it by now, a coding bootcamp is a serious commitment. It's going to require everything: time, energy, and money. Why would you make a sacrifice like this if you weren't at least a little serious about it? Making a move like this could be really impractical based on your situation. So, Why?

Knowing your "Why?"

Defining your "why" is one of the first things that Flatiron School really challenges you to think about when going through the application process. This is something that I genuinely appreciated because it showed me their intentions to make students a priority. They force you to really think about it before handing them all of your hard earned money. Admissions gave me a whole week to think about it before sharing it to them during a non-technical interview. I don't remember the colleges that I attended ever asking me to look within myself like this before asking me for my money. 🤔

A little bit of background about me

I am from the Bay Area in Northern California, and have no background in computer science. Before making my switch into tech, I graduated with a BS in Kinesiology with the intention of pursuing grad school. I am currently enrolled in Flatiron's full-time (online) Software Engineering program which is broken up into 5 phases over 15 total weeks.

Prework

After going through the application process, Flatiron is going to give you access to material that is going to be your foundation of knowledge going into Day 1 of the bootcamp. I highly recommend giving yourself atleast 2 full months (maybe even 3 months) to go through the prework to give yourself time to let the material sink in. The prework will introduce you to the terminal, Git, GitHub, HTML, CSS, and Javascript.

Week 1 (Phase 1)

The first week was the by far my toughest week and really tested my "why". I was already asking myself, "what did I get myself into?". Lectures were moving fast and we were assigned a ton of homework for the week. I knew the coding bootcamp was not going to be easy, but man... they call it a bootcamp for a reason!

During this phase I really struggled to keep up with the pace of the program. I found myself feeling very behind not only by the amount of assignments that needed to get done, but also in my understanding of the concepts. There was a lot of information to take in, and a lot of moving parts to that information. The imposter syndrome that Flatiron warns you about during the application process leading up to Day 1 was getting REAL.

My first coding challenge (week 2)

Each phase is 3 weeks, and there is a coding challenge at the end of the 2nd week of each phase. A coding challenge is basically a test. It's their version of a midterm. You are given some tasks, and about 3 hours to execute those tasks in code.
I did not pass the first coding challenge, and this is exactly how I felt. This was a critical moment for me, I was extremely hard on myself after receiving my results, doubtful thoughts were crowding my mind: "I should have been good enough!", "Am I smart enough for this?", "Maybe my brain isn't wired for this type of stuff.", "Will I have to be held back?". This was one of the few times in my life I genuinely contemplated quitting, and I am pretty stubborn about finishing anything that I start.

Bouncing Back

After allowing myself to let those negative emotions and thoughts pass, I knew that quitting was not an option. The next day I noticed on our Slack channel that a some of my classmates had DM'd me yesterday right after class to check in on me and make sure I was alright. My frustration was probably written all over my face.

The sense of urgency to DM me literally right after class ended that day really uplifted my spirits because it showed me the amazing support system I have around me and most importantly, that I am not alone. Our main instructor also helped to put things in perspective by reminding all of us that, "this is only your second week of coding EVER in your life". For most of us this was true, the majority of my cohort also comes from non-tech backgrounds. Sometimes you just need to take a step back and look at the bigger picture which helped me realize that everything I was experiencing at the time was absolutely normal. Once again, Flatiron warned all of us that this would happen!

Where I'm at

Thanks to the amazing support system that is my cohort, I have made it to phase 3 and am on my way to phase 4. As the program has been progressing, material started sticking faster, I developed a rhythm for completing labs, and making time to study outside of class. Some of my classmates were even asking me for help 😱. Despite the workload gradually increasing and becoming more difficult throughout different points of the program, I have been able to stay afloat, I just needed some time to adapt.

Where I'm headed

A lot has happened since phase 1. So far we have learned Javascript in phase 1, React (a Javascript framework) in phase 2, and Ruby in phase 3. Phase 4 we will be learning Ruby on Rails which is a Ruby framework. Phase 5 we will all be on our own to build our own fullstack application (frontend & backend) applying everything Flatiron has taught us.

Major Takeways

Coding is a very difficult skill to learn: don't get too hard on yourself, if you are feeling stressed out by a particular problem, sometimes you just need to walk away from your desk for 5 minutes.
Don't fall into the trap of comparing yourself to your classmates: it can also be easy to discourage yourself when the material is coming easier to others than it is for yourself, or you might have a few people in your cohort who have some programming experience or a computer science background which can also be intimidating. EVERYONE has different SPEEDS and STRENGTHS. Just focus on you.
Your cohort is your greatest resource: you are not alone in all of this. Everyone else in your cohort is going through similar, if not the same emotions and struggles as you. You are all tackling the same material. DO NOT isolate yourself and be afraid to ask for help in fear of "looking dumb". Take advantage of the opportunity to grow and collaborate with your classmates because you are all in it together anyways.
Get comfortable being uncomfortable: you will surprise yourself when you see how quick you start to digest the material.
Remember your "Why": anything in life that is worth it is going to be difficult. A coding bootcamp is going to push you if you come from a computer science background or not. There is going to be many challenges thrown at you in many different forms. It's in these moments that remembering your "why" will help you to push through.

Conclusion

My experience so far at Flatiron School has been a lot of ups & downs. There has been a ton of growth! Besides all of the coding knowledge I have learned up to this point, I have also learned a lot more about myself. I have learned more about HOW I learn and what works best for me (self-awareness is a major 🔑) and most importantly, I have learned the importance of community. I have been blown away by my experience with my cohort. The level of comradery that we have developed up to this point has been far beyond what I imagined it would be. Overall, there is so much more to be gained from a coding bootcamp than just the technologies they teach. Hopefully I have helped you get a better idea of whether or not a coding bootcamp is a good option for you or not. Just know that it will be a journey and remember to TRUST THE PROCESS.

The spaceship operator <=> in Ruby

Josh Blengino — Wed, 11 Aug 2021 20:41:02 +0000

If you're a Ruby noob like me, you probably saw the "spaceship operator" and thought of Space Invader or Darth Vader's infamous TIE fighter. I am currently on day 2 of learning Ruby going into day 3 and I had trouble understanding what this interesting looking operator does and what you could use it for. Hopefully by the end of this post, you and I can both take away some practical use cases for this method.

Ruby Comparison Operators

Before we start experimenting with the <=> operator, let's take a look at more common comparison operators.

 1 > 0     #=> true     (Greater than)
 0 < 1     #=> true     (Less than)
 1 >= 0    #=> true     (Greater or equal than)
 0 <= 1    #=> true     (Less or equal than)
 1 == 0    #=> false    (Equals)
 1 != 0    #=> true     (Not equals)

Pretty straightforward, they all return a boolean value. An important takeaway from one of my readings was to remember that all Ruby operators are actually methods. This is because the behavior (return value) will depend on the type of class (object) it is called on.

<=> Operator

It's technical name is the combined comparison operator. The major difference compared to the other comparison operators is that it returns 3 different values: (-1), (0), or (1).

1 <=> 1     #=> 0
0 <=> 1     #=> -1
1 <=> 0     #=> 1

For Integers: (0) if right side = left, (-1) if less than, and (1) if greater than.

"string" <=> "string"     #=> 0     (contents are the same)
"string" <=> "stringg"    #=> -1    (length of string)
"string1" <=> "string2"   #=> -1    (string integer)
"STRING" <=> "string"     #=> -1    (capital)

For Strings the behavior is not as straight forward. It looks like uppercase letters are given a lower value than lowercase letters. Why?

The Ruby Enumerable <=> operator and #max vs. #max_by

Sylvia Pap ・ Feb 12 '20

#beginners #ruby #codenewbie #computerscience

Another great post on this topic mentions how characters in strings are compared with binary values under the hood, which helps to better understand the above return values.

fighter1 = {type: "TIE Fighter", owner: "Darth Vader", affiliation: "Galactic Empire", id: 1}
fighter2 = {type: "X-wing", owner: "Luke Skywalker", affiliation: "Rebel Alliance", id: 2}

fighter1 <=> fighter1     #=> 0
fighter2 <=> fighter1     #=> nil
fighter1 <=> fighter2     #=> nil

For Hashes it's even less clear...

fighter1 = {type: "TIE Fighter", owner: "Darth Vader", affiliation: "Galactic Empire", id: 1}
fighter2 = {type: "TIE Fighter", owner: "Darth Vader", affiliation: "Galactic Empire", id: 1}

fighter1 <=> fighter1     #=> 0
fighter2 <=> fighter1     #=> 0
fighter1 <=> fighter2     #=> 0

Here the contents are exactly the same with expected results.

fighter1 = {type: "TIE Fighter", owner: "Darth Vader", affiliation: "Galactic Empire", id: 1}
fighter2 = {type: "X-wing", owner: "Luke Skywalker", affiliation: "Rebel Alliance", id: 2}

fighter1[:owner] <=> fighter1[:owner]     #=> 0
fighter2[:owner] <=> fighter1[:owner]     #=> 1
fighter1[:owner] <=> fighter2[:owner]     #=> -1

Here it looks like the string length comes in to play after changing fighter2 back to normal.

fighter1 = {type: "TIE Fighter", owner: "Darth Vader", affiliation: "Galactic Empire", id: 1}
fighter2 = {type: "X-wing", owner: "Luke Skywalker", affiliation: "Rebel Alliance", id: 2}

fighter1[:id] <=> fighter1[:id]     #=> 0
fighter2[:id] <=> fighter1[:id]     #=> 1
fighter1[:id] <=> fighter2[:id]     #=> -1

Even though these examples do not showcase every possible scenario for these data types, we now know that the behavior of the <=> operator for Arrays and Hashes is a little unpredictable depending on their respective contents. Even Ruby's documentation mentions how unpredictable the return value could be based on the objects being compared.
That's still not very helpful for how we could use this in a practical way.

Using <=> with Ruby's `sort` method

star_fighters = [
  {type: "TIE Fighter", owner: "Darth Vader", affiliation: "Galactic Empire", id: 1}, 
  {type: "X-wing", owner: "Luke Skywalker", affiliation: "Rebel Alliance", id: 2},
  {type: "Jedi Starfighter", owner: "Obi-Wan Kenobi", affiliation: "The Republic", id: 3}

]

sorted_star_fighters = star_fighters.sort do |fighter1, fighter2|
  fighter1[:id] <=> fighter2[:id]
end
puts sorted_star_fighters
#=> {:type=>"TIE Fighter", :owner=>"Darth Vader", :affiliation=>"Galactic Empire", :id=>1}, {:type=>"X-wing", :owner=>"Luke Skywalker", :affiliation=>"Rebel Alliance", :id=>2}, {:type=>"Jedi Starfighter", :owner=>"Obi-Wan Kenobi", :affiliation=>"The Republic", :id=>3}

In this scenario, our hashes are being ordered from lowest to highest because based on how our id's are set up, fighter2's id will always be greater than fighter1's, which will return -1.

star_fighters = [
  {type: "TIE Fighter", owner: "Darth Vader", affiliation: "Galactic Empire", id: 1}, 
  {type: "X-wing", owner: "Luke Skywalker", affiliation: "Rebel Alliance", id: 2},
  {type: "Jedi Starfighter", owner: "Obi-Wan Kenobi", affiliation: "The Republic", id: 3}

]

sorted_star_fighters = star_fighters.sort do |fighter1, fighter2|
  fighter2[:id] <=> fighter1[:id]
end
puts sorted_star_fighters
#=> {:type=>"Jedi Starfighter", :owner=>"Obi-Wan Kenobi", :affiliation=>"The Republic", :id=>3}, {:type=>"X-wing", :owner=>"Luke Skywalker", :affiliation=>"Rebel Alliance", :id=>2}, {:type=>"TIE Fighter", :owner=>"Darth Vader", :affiliation=>"Galactic Empire", :id=>1}

In this scenario, our hashes are being ordered from highest to lowest because in this case, fighter2's id will always be greater than fighter1's id, which will return 1.

Takeaways

Return values are integers: (-1), (0), or (1)
Return values can be unpredictable with Strings & Hashes depending on their contents which makes Integers a more attractive option to work with.
The <=> operator can come in handy when using sort to order your data from ascending or descending order in a cleaner way instead of doing something like this:

star_fighters = [
  {type: "TIE Fighter", owner: "Darth Vader", affiliation: "Galactic Empire", id: 1}, 
  {type: "X-wing", owner: "Luke Skywalker", affiliation: "Rebel Alliance", id: 2},
  {type: "Jedi Starfighter", owner: "Obi-Wan Kenobi", affiliation: "The Republic", id: 3}

]

sorted_star_fighters = star_fighters.sort do |fighter1, fighter2|
  if fighter1[:id] == fighter2[:id]
    0
  elsif fighter1[:id] < fighter2[:id]
    -1
  elsif fighter1[:id] > fighter2[:id]
    1
  end
end
puts sorted_star_fighters
#=> {:type=>"TIE Fighter", :owner=>"Darth Vader", :affiliation=>"Galactic Empire", :id=>1}, {:type=>"X-wing", :owner=>"Luke Skywalker", :affiliation=>"Rebel Alliance", :id=>2}, {:type=>"Jedi Starfighter", :owner=>"Obi-Wan Kenobi", :affiliation=>"The Republic", :id=>3}

Conclusion

Based on my short experience with the <=> operator, it seems to be most useful in tandem with the sort enumerator. I would love to hear if anyone else knows any other use cases in the comments below. Hopefully this post gave you a slightly better understanding of the <=> operator. I am definitely going to continue to experiment with it. Other languages that use the <=> operator include: Perl, Apache, Groovy, PHP, Eclipse, Ceylon, and C++. Having a good grasp on how and when to use conditional operators to compare values will allow you to control the flow of your data like a jedi controlling the flow of The Force.

Resources

Ruby equality
Ruby operators
Ruby sort enumerator
HTML Encoding (Character Sets)
https://www.youtube.com/watch?v=tpsdxtf01po
https://www.youtube.com/watch?v=f4NItw7r33E

Destructuring in Vanilla JS for Beginners

Josh Blengino — Tue, 20 Jul 2021 17:22:52 +0000

Destructuring is a very useful way for accessing multiple properties within an array or an object in Javascript. Learning this technique is going to be essential if you are planning to learn React in the future. Even if you do not plan to learn React, this technique is also a great way to make your code cleaner and easier to work with.

What is Desctructuring?

When you destructure an array or object you are converting it to a smaller array, object, or variable.

Array Destructuring

Below we have two arrays to work with:

const jedi = ['Yoda', 'Qui Gon Jinn', 'Obi Wan Kenobi', 'Luke SkyWalker']
const sith = ['Emperor Palpatine', 'Darth Vader', 'Darth Maul', 'Kylo Ren']

If we wanted to access each jedi we would have to do something like this:

console.log(jedi[0])
console.log(jedi[1])
console.log(jedi[2])
console.log(jedi[3])

In our console we would get:

Yoda
Qui Gon Jinn
Obi Wan Kenobi
Luke SkyWalker

This is a tedious way of accessing each jedi in our jedi array.
Instead, let's destructure our jedi array:

const [firstJedi, secondJedi] = jedi
console.log(firstJedi)

In our console this would print:

Yoda

We took the array we wanted to destructure and put it on the right side and assigned it to some variable names. Each variable's position will correspond with each element in the array we are destructuring. For example:

const [firstJedi, secondJedi] = jedi
console.log(secondJedi)

Will print:

Qui Gon Jinn

What if we wanted to combine both the jedi and the sith arrays? To do this we can use the spread operator (...):

const jedi = ['Yoda', 'Qui Gon Jinn', 'Obi Wan Kenobi', 'Luke SkyWalker']
const sith = ['Emperor Palpatine', 'Darth Vader', 'Darth Maul', 'Kylo Ren']


const jediVsSith = [...jedi, ...sith]

console.log(jediVsSith)

Our console will print:

Yoda
Qui Gon Jinn
Obi Wan Kenobi
Luke SkyWalker
Emperor Palpatine
Darth Vader
Darth Maul
Kylo Ren

Destructuring allows us to access elements within our arrays in a way that is easier to read by assigning each element to a variable name of our choosing without having to use bracket notation.

Object Destructuring

Destructuring an object is going to be very similar to an array only we will be using curly braces {}. Below we have two objects:

const darthVader = {
  age: 45,
  lightSaber: 'red',
  famouseLine: 'I am your FATHER!!'
}

const yoda = {
  age: 900,
  lightSaber: 'green',
  famouseLine: 'Fear is the path to the darkside.'
}

If we want to access yoda's age and lightsaber:


const { age, lightSaber } = yoda

console.log(age)
console.log(lightSaber)

Our console:

900
green

Instead of our variables being based on position like it was with arrays, they will be based on the name of the key instead. The names of the variables must match the names of the keys.

What if we want to use a different variable name?

const { age: yodaAge, lightSaber: yodaLightSaber } = yoda

console.log(yodaAge)
console.log(yodaLightSaber)

Our console will give the same results:

900
green

What if we want to add a default value to a key that yoda does not already have?

const { age: yodaAge, lightSaber: yodaLightSaber, anotherYodaQuote = 'The greatest teacher, failure is.' } = yoda

console.log(yodaAge)
console.log(yodaLightSaber)
console.log(anotherYodaQuote)

By doing this our console will show our added default value but does not actually add the key/value pair to our yoda object:

900
green
The greatest teacher, failure is.

Using the spread operator(...) with object destructuring:

const {age, ...rest} = yoda

console.log(rest)

Console:

lightSaber: 'green'
famouseLine: 'Fear is the path to the darkside.'

Using the spread operator we accessed the rest of yoda's properties except for the age property because we already declared it. The variable rest to the right of the spread operator can be a variable name of your choosing.

Combining objects using the spread operator(...)

Let's remove some properties to each object and see what happens:

const darthVader = {

  lightSaber: 'red',
  famouseLine: 'I am your FATHER!!'
}

const yoda = {
  age: 900,
  lightSaber: 'green',

}

const newJedi = {...darthVader, ...yoda}

console.log(newJedi)

Console:

age: 900
lightSaber: 'green'
famouseLine: 'I am your FATHER!!'

Notice how when we combined our objects, properties from the second object (yoda) were added to the first object (darth vader) if they were not already there and would also override the first object's property if they both had the same property.

Conclusion

There are many more use cases for destructuring arrays and objects within functions. If you are a beginner like me, it might take some time to wrap your head around this topic, but that is OKAY! Check out the links below if you want to dive deeper into this topic.

If you plan to learn React, becoming more comfortable with this technique will make life easier when you start working with props and components. Stay tuned for Part II of this blog topic where we will destructure some props and components within functions in React!

Resources

MDN Destructuring Documentation
freeCodeCamp Javascript Object Destructuring

DEV Community: Josh Blengino

Uploading files in a React/Rails App using Active Storage

Backend setup

has_one_attached macro

Controller

Serializer

Frontend setup

State

The form

Making the POST request to our backend

Rest of the code

Testing it out

Making a GET request in Postman

Enjoy the fruits of your labor

Resources

Polymorphic Associations in Rails

What is Polymorphism?

Where could this be useful?

Polymorphic associations

Creating a poly_likes table

What does the migration show us?

Lets run the migration and check out the schema

What about the model?

Naming convention for polymorphic associations

Testing it out in the console

Now let's check a comment and a post

Pros

Cons

Conclusion

Resources

Halftime: Trusting the Process during a coding bootcamp

Knowing your "Why?"

A little bit of background about me

Prework

Week 1 (Phase 1)

My first coding challenge (week 2)

Bouncing Back

Where I'm at

Where I'm headed

Major Takeways

Conclusion

The spaceship operator <=> in Ruby

Ruby Comparison Operators

<=> Operator

The Ruby Enumerable <=> operator and #max vs. #max_by

Sylvia Pap ・ Feb 12 '20

Using <=> with Ruby's sort method

Takeaways

Conclusion

Resources

Destructuring in Vanilla JS for Beginners

What is Desctructuring?

Array Destructuring

Object Destructuring

What if we want to use a different variable name?

What if we want to add a default value to a key that yoda does not already have?

Using the spread operator(...) with object destructuring:

Combining objects using the spread operator(...)

Conclusion

Resources

Using <=> with Ruby's `sort` method