DEV Community: NicolaiGorden

Active Storage and React

NicolaiGorden — Wed, 29 Nov 2023 23:13:48 +0000

Let's say you want your user to upload files from your react application, and have it be saved to a table in your rails back end. Thankfully, there's a rails library just for this, and the process is quite simple. Active Storage allows you to upload files (either locally, or to a cloud service like Amazon S3 or google cloud), and attach them to Active Record objects. Today, we'll be using images as an example, and saving them to a user 'profile' object, but Active Storage's uses go far beyond image uploads.

Installation

Once your application is ready to implement file uploads, in the terminal, navigate to your application folder and run:

rails active_storage:install

Then:

rails db:migrate

The first command will add a few new tables to your migrations. Once you migrate these, you should notice that these tables have been added to your schema. These are join tables that you won't directly interact with, but will assist in connecting uploaded files to your models.

Make models accept files

In our example, we have a 'Profile' model, which belongs to a 'User' model. Our Profile model contains a bio, and we want to add a profile picture to it. Normally, you'd create a migration and add a new column, perhaps for an image url. Here, all we have to do is navigate to our profile model, and call the has_one_attached declaration, which functions similarly to other join table declarations like has_many. We'll follow this declaration with the word we intend to use as a reference for our files. This could be something like 'track', 'document', or 'photo', but in our case, we'll call it 'avatar'.

class Profile < ApplicationRecord
    belongs_to :user
    has_one_attached :avatar
end

We'll add :avatar to the permitted parameters in the profile controller, and then move on to the front end. But first...

Quick aside to discuss validations

While we're here, let's also write a validation. If we're paying to host these files on a web service, we don't want users to upload files that are too big, as that would drastically inflate the amount of storage space your app is taking.

validate :acceptable_image

def acceptable_image
    return unless avatar.attached?
end

We start our acceptable_image method with a guard clause that breaks out of the method if there is no image attached to our POST/PATCH request.

Let's look back at the schema for a moment. You'll find a table called "active storage blobs". Imagine this as a hash that contains all relevant information about the file being uploaded. We can use the information in this hash to create our validations. In fact, once you've added the POST/PATCH request to your front end, try temporarily adding the following to the top of your model:

ActiveStorage::Blob

and then enter the debugger of your choice within the controller's POST or PATCH method. Call your file with .blob at the end (in our case, profile.avatar.blob), and you should see your upload's filename, content type, byte size, and more.

With this knowledge, we can write the following:

def acceptable_image
    return unless avatar.attached?

    unless avatar.blob.byte_size <= 3.megabyte
        errors.add(:avatar, "is too large")
    end
end

Ensuring our application won't accept avatar images greater than or equal to 3 megabytes.

With this knowledge, we can make another validation! Upload form we're adding to the front end should only accept images, but we should really limit the file type in case someone finds a way to bypass this and add malicious data to our application somehow (can never be too safe!). Maybe we want to limit the types of image files our users can add too! If you were able to check an upload's blob data, you might see that the image_type column denotes the file's type using a string formatted as such:
'category/type'
for example: "image/jpeg" or "audio/mp3". with this knowledge, we can add the following to our acceptable_image method:

def acceptable_image
    return unless avatar.attached?

    unless avatar.blob.byte_size <= 3.megabyte
        errors.add(:avatar, "is too large")
    end

    image_types = ["image/jpeg", "image/png"]
    unless image_types.include?(avatar.content_type)
        errors.add(:avatar, 'must be jpeg/png')
    end

end

Front End Form

In the front end, we already have a fetch that uploads the profile's bio as json data, but now that we've added image uploading capability to our back end, we're going to need to adjust some things. Here's what that fetch request might look like beforehand:

function handleProfileUpdate(e) {
    e.preventDefault()
    fetch(`/profiles/${id}`, {
        method:'PATCH',
        body: JSON.stringify({
            bio
        }),
    })
}

This function would a receive a bio saved in state; one theoretically edited by the user through an HTML input. However, now that we've presumably added an html input that accepts images, and saved that image data to state, we can no longer simply turn it into a json. Instead, we'll send it as Form Data, like so:

function handleProfileUpdate(e) {
    e.preventDefault()
    const formData = new  FormData()
    if (imageData) {
        formData.append('avatar', imageData)
    }
    if (bio) {
        formData.append('bio', bio)
    }
    fetch(`/profiles/${id}`, {
        method:'PATCH',
        body: formData
    })
}

As you can see, here we create a new, blank form, then check state for our image and our bio, appending them to the form data if they exist. Then, we send the data within the body of our fetch request. This should result in a successful upload! After this, we can implement the validations we defined previously, and pass them as errors to the frontend.

Custom Validations and Methods in Rails

NicolaiGorden — Thu, 09 Nov 2023 00:03:42 +0000

I've been using Ruby on Rails for a few months now, and despite the fact that I have much more experience with frontend tech, doing backend logic has genuinely been a lot less stressful; mostly because Rails streamlines so much of the workload. And not only just for the backend! In the couple projects I've been able to do, it's been very noticeable how much of my (model-based) logic has moved from ReactJS to Rails' controllers and models. (mainly because the elegance of ruby's syntax makes writing logic ever-so-slightly more understandable, to me.) Let's go through some custom validations and methods to see what kind of workload we can offload to the backend.

Something important to remember is that, because we don't want to spaghettify our code on either ends, we have to write methods that we know are necessary. We and to keep our code as clean as possible so managing state in the frontend is less of a pain. Rails already gives us A LOT of flexibility, so it's important to peek at the documentation every now and then because usually, something you need to do is covered in some method or validation there.
In one of my projects, specifically an auction building site, I have three models connected through a joins table in Rails. There are 'users' which own 'bids' for 'items'. These tables all have very basic, standard data tables, name, price and such. However, for this particular project, I wanted to make sure that, for a given item, the user:

Cannot place a bid worth less than the highest bid on the current object.
Can very readily see the highest bid on any given component an item lives in. This means I want my item model to be have some kind of 'highest bid' field or method, which would requires custom logic that can knab data through join tables from within the item model. Thankfully, Rails can do this!

  def highest_bid
      if self.object.bids.length > 0
        self.object.bids.map{|bid| bid.amount}.max()
      else
        self.object.start_price
      end
  end

I have this method saved in my ItemSerializer (through active_model_serializers). We map through an array of bids connected to the object (if there are any), returning the highest bid. If there are no bids, we return the starting price (remember to account for any possible state of your backend data, as to avoid errors). Not only do we now have a highest_bid key-value pair we can pass to the front end, it's also dynamic, eliminating the need to do much of that data handling on outside of our database. Avoiding repeating code is always good, especially when you can keep that frontend clear.

Of course, this all comes at the cost of having to juggle performing CRUD actions in the backend while also dynamically updating the frontend. We need to either be selective about how we build our models and how much data is stored in their tables, or we need to make use of custom rendering and associations. A lot of this is where pre-planning and pseudo code becomes useful, especially in larger-scale applications where data is more complex and specific. It can be quite easy to overcomplicate your database, and your greatest tool is preplanning; avoiding creating unnecessary code can sound daunting, but it's usually a side-effect of doing things without a solid plan before hand, trust me, I would know. Rails provides tools that expedite the completion of projects, if you use them right; this means not writing custom methods for every single little piece of logic, a lot of this can be handled on the front end. In my opinion, it becomes much more pertinent to create alternatives when your application has something specific and encompassing it requires to work, or at least, function in a satisfying way.

One last quick one, a validation this time.

    def must_contain_uppercase
        if password != nil
            unless password.match(/[[:upper:]]/)
                errors.add(:password, message: "must contain an uppercase character!")
            end
        end
    end

A lot simpler, but just know you don't have to stick with the validations Rails provides (even though they're incredibly useful, in fact I'm sure this exists already. Seriously, people. Docs.) Here, we're just checking if the password response in a create(or update) method contains an uppercase character. Then, we pass a custom error message to the frontend, for us to save in state for later.

At the end of the day, it's still Ruby, and you can quite easily write your own logic. Rails makes things easy, but you can make them even easier, just make sure to write your backend logic where it's absolutely necessary

Flatiron Phase 3 Blogpost - Learning new languages, and syntax simplicity.

NicolaiGorden — Mon, 06 Mar 2023 17:03:54 +0000

Despite knowing for a while now that object-oriented coding languages share a lot of similarities, I had been afraid of learning new ones. Before I learned JavaScript and Ruby for the Flatiron School, I had spent a month trying to learn C#, as it's a very useful language to know if you want to get into game development. As I'm writing this, I still know very little about C#; nothing really ended up sticking. For a while now, I've wondered why that was. Of course it was easier for me to learn Javascript because I was doing a guided course for it, but I feel like even without that boon, the language is just more accessible to a beginner (this doesn't mean I think it's THE BEST language, I don't have enough context to say such a thing). After learning Javascript, I was pretty anxious about learning Ruby. My prior experience with C# made me scared that the knowledge I had wasn't going to carry over. In my head, all I could remember was being incredibly confused while watching tutorials on Youtube. Well, turns out pretty much all of the things I had learned from Javascript still apply to Ruby, with some slight variations on rules. The only thing that really took a lot of brainpower for me, was learning new syntax.
I'm very early in my coding career, so I'm not exactly qualified to explain to others what good teaching practice is when it comes to coding. Regardless, I think it's imperative (at least, for someone like me) to learn with a language that has descriptive, easy syntax. I now have the experience of learning a language for the first time, and learning a language with some general coding experience under my belt, and those two learning experiences are incredibly different. In my opinion, the first language you learn should make it easy for you to learn coding fundamentals without overcomplicating things. Throwing terrifying words like "public static void" at a beginner can be deceptively overwhelming, even if you tell them to "ignore it for now". Let's look at what a function declaration looks like in a few different languages.
Here's a very simple function/method written in C#, Javascript, and Ruby (C# experts please forgive me if there's a cleaner way of doing this, I wrote it after looking at W3schools for about 4 minutes). It does the same thing in all languages; takes in a string as an argument and prints that string to the console.

Alright, so this is C#, and (pretending I have absolutely zero clue what I'm looking at) I've got to be honest, even with a little bit of experience this code snippet is a little much compared to what I'm used to. I still don't know exactly what "static" and "void" are doing, but with more knowledge I can actually make some educated guesses now. Maybe static means this is immutable? Or maybe it's some kind of pointer to...something. Could be totally off the mark. Also not sure why we're putting this in a program class. Still, I can tell this is a method/function based on the fact that we're clearly defining "PrintMessage", which takes in an argument. Then we call that function in the second block of code, re-enforcing that this is definitely probably a function. Maybe. I can only come to these conclusions now because of my experience so far.

Let's take a look at Javascript and Ruby at the same time, since these two functions look very similar. The difference I want to focus on here, is that in Javascript, we define a function using the word 'function'. Amazing. Unceremonious, but very helpful to a beginner, whereas in Ruby, we use def. As someone with at least a little bit of experience, this is pretty cool! That's only because, however, I know what a function looks like regardless of the keyword. I can tell it's a function simply due to it's contents and the fact that it takes in parameters as arguments. Despite Ruby's visual simplicity, I'd still probably start someone off with a language like Javascript, even if it's just to introduce some basic coding concepts. This all seems pretty minor at the end of the day, but I do really think it's important to consider what context you have as a learning coder, and how best to learn based on that context. I've focused a lot on just functions/methods today but I want to clarify that I do think this extends to other parts of these programming languages. In Ruby we define constants by giving them uppercase names, but in Javascript we literally use the word Const. It's helpful for beginners to have labels before building the ability to recognize coding patterns that don't have those labels.

Flatiron Phase 2 Blogpost - React

NicolaiGorden — Sat, 03 Dec 2022 06:40:04 +0000

The past few months have been pretty rough in all honesty. I've had to face a lot of physical and mental health issues, and doing so while studying and working hasn't been the easiest thing in the world. Despite all this, I've actually been having a blast learning React, and I feel really lucky that it's the subject that I've been assigned to study for Phase 2. It's very intuitive, and it really boosted my confidence when it comes to coding in general. I've experienced a lot of imposter syndrome up to this point, and I still have some trouble considering myself a "programmer", but when working in React, everything goes so smoothly that it almost feels natural. Obviously I studied quite a bit to get to my point of understanding now, so I won't say some of the credit doesn't belong to me (haha.), but it's seriously easy to learn if you already have solid fundamentals in JS and HTML. Coding a website in react feels easier and more streamlined than doing so in vanilla JS, and there's a few reasons why.

First of all, components are BEAUTIFUL. They're great for many technical reasons; they're fast to write and render, they're reusable, and they're pretty simple to visualize and understand, but my absolute favorite thing about them is that they naturally lend themselves to clean, effective organization. This, to me, is invaluable. I, personally am very easily overwhelmed, and have trouble breaking down big tasks into smaller ones. This seriously effects my workflow a lot of the time. React is great for this, because it literally forces me to split my work into little bits and tackle them one at a time, rather than constantly going back and forth through the same JS file to find out why my code isn't working. JSX is also really helpful for this, because it seamlessly integrates HTML into JS files, and makes it feel less like I'm juggling two things at once. I can just play with the JSX like I would any other variable.

The example above is a very common application of this. If I want to render multiple of the same component with different data, all I have to do is map through an array of that data, and make a new component for each object in the array. This can all be done within the JSX, and in one line at that! Doing the same thing in vanilla JS, while easy, feels a lot clunkier and hard to read/keep track of. Manually editing the innerHTML, getting elements, and adding event listeners all feels really unnecessary in the face of React, which is much more modular.

Using the React hooks has been really fun too, and I plan on learning what other hooks the library has to offer. so far I've only really been using useState and useEffect, but they're so useful that I'd be surprised if some of the other hooks weren't just as handy. useEffect in particular is EXTREMELY powerful. I feel like I don't even really have the knowledge or experience to fully explain why it's powerful, just because the scope of it's usage is so vast. Within a component, you can literally have any sort of effect happen at the execution of any trigger you set thanks to useEffect and it's required dependency array.

Here, I'm using useEffect to fetch the data for my project. With the dependency array I can force the function to only run once, and then I can use it in tandem with the useState hook to save my data to a convenient, easy to access variable that I can change at any time. Let's say I wanted to have my program fetch a different set of data when I click on a button on the page. All I'd have to do is add a useState that switches between two booleans, and have that state change whenever the button is clicked. Then, in my useEffect function, I'd just have to add that state variable to the dependency array, and It'd ONLY update when that particular variable is changed.

The toolbox React has provided me with is just incredible; every piece of knowledge feels like it fits with the last perfectly. Knowledge of hooks build upon knowledge of components, which builds upon knowledge of vanilla JS and HTML in general, and using all these tools I've learned has felt super natural, which is a huge relief. I was honestly really afraid I wouldn't "get it" after phase 1, and I think learning in this phase has been intuitive enough to dull that imposter syndrome I've been feeling when it comes learning something new going forward, even if only by just a bit.

Flatiron Phase 1 Blogpost - Codewars

NicolaiGorden — Thu, 28 Jul 2022 16:24:44 +0000

As someone who plays a lot of video games, I've heard the term "spaghetti code" used to describe a game that has had so many people work on it that the code is borderline unreadable. This never really made sense to me, until I truly learned how many different ways you could code a solution to one problem.
I've tried to get into coding many different times throughout my life, (all met with failure) so I was pretty nervous about diving into javascript for class. I knew that compared to languages I had tried to learn previously, the syntax was much simpler, but learning new things can still be stressful, especially for me, as I have a habit of giving up easily.
Thankfully, it also turns out I have a habit of getting distracted and playing around with codewars, something I actually think really helped me understand the basics of working with variables through the use of array manipulation and iteration methods. Not only did it do this, but I also found that looking at the solutions from other, smarter coders had motivated me to do even more research and implement new methods that not even the Flatiron School had told me about into my code. I was developing my own way of coding things.

For example, the Array.from() method has become one of my go-to tools for creating arrays with values derived from variables outside of the scope of whichever function I'm calling it in. Not only that, but it's also great for making reference arrays, the length of which can be dynamically altered based on pre-existing variables.

I think refactoring code has become something that's way easier for me to do specifically because of codewars; you can code a solution to a problem, look at other solutions, and use the new knowledge you gain from research to write an even better solution. As an example, here's a task a did a few months ago:

Here was my first solution:

In this solution, the first thing I do is create a reference array as a tool for later code by using a spread operator on the text argument, which has all been converted to uppercase. I call this array "refText". I then create another array, one which we will be pushing strings into, and then returning as the solution. I simply call this array "arr" and initialize it with one variable, the text argument (set to uppercase) because I know that no matter what, the first item in that array will be the text argument set to uppercase. Finally, I call a for loop that iterates over the length of the text minus one. For each iteration, the loop uses .shift on the "reftext" to remove the first item (the first letter), and pushes it onto the end of the array. After that, the loop simply joins the array, and pushes it onto the end of "arr".
Now this works, and it uses some pretty simple methods to get the job done, but as I said, one of the main draws of codewars to me is the way the website incentivizes you to refactor code, so here's my second, shorter solution:

In this solution, all I'm really doing is returning an Array, but since I'm using an Array.from, I can do quite a lot to this array that I'm returning, all in one line. The first argument is an object that Array.from uses to dictate the length of the array. Since I know that the solution array will always be the length of the string it's being fed, defining that length is as simple as using text.length. Array.from can also take in a map function if you need to iterate over the array, so I use a little trick I learned after looking at other solutions to the problem. Instead of meticulously removing elements from the beginning of a string and pushing it to the end, I combine the text argument with itself, thus creating a string that is just the text repeated twice. Now all I have to do is return a string that samples from the repeated string, using the map function's index element to slice the repeated string at different points for each iteration. If that's confusing, this image should provide a visual indication of what I'm basically doing to the repeated string. (the text in red represents what part of the string is being added to the array at each given iteration):

This is just one of many examples of things I learned with this approach.
Through this entire phase, I've felt my confidence when it comes to learning new languages improve dramatically, which is great because as someone who wants to eventually dive into game development, one of the biggest barriers for me has always been learning new syntax. I've come to find out that the internet has an abundance of resources that not only teach you, but paint a picture of the broader coding world that I had not had before, that being one of individuality and collaboration. After seeing how many solutions there can be to one problem, it really hit me that this is an art form. Like drawing (a frequent hobby of mine), the product of a programmer is something that not only embodies their specific way of coding, but also what they've learned from others.
I guess that's why spaghetti code exists.