DEV Community: hyunho98

Utilizing Delegated Types to Manage Multiple Types of Users

hyunho98 — Tue, 19 Dec 2023 23:39:31 +0000

In ActiveRecord, the Delegated Types approach is used to simultaneously interface with two tables with separate attributes. The Delegated Types documentation page poses that "pagination", or the grouping and division of code blocks, of two different tables was not possible before the inclusion of delegated types because the attributes of an instance of a superclass and its subclasses can only persist within their respective tables. Because of this, there's no way for us to easily retrieve and organize instances of subclasses without multiple queries. The addition of another subclass would only complicate this process further. Delegated types streamlines this process by allowing the superclass to share its attributes with any of its subclasses.

Practical Usage

Using my project AdSpace as an example, one way we can use delegated types is to implement different kinds of Users. In AdSpace, there are two kinds of Users. One of these is a Company that can create advertisements for a product that the other user type, the Advertiser, can then claim and run in their specific advertising market.

Initial Setup

Since the superclass in this case is the User, we implement delegated types in the User class file.

# app/models/user.rb

class User < ApplicationRecord
    delegated_type :userable, types: %w[ Agency Company ], dependent: :destroy
    ...
end

In this one line, we declare the delegated type as userable, which then accepts the different kinds of Users as an array of strings. Dependent destroy can also be added to also destroy any Agency or Company instances that are attached to a User instance that is destroyed.

# app/models/userable.rb

module Userable
    extend ActiveSupport::Concern

    included do
        has_one :user, as: :userable, touch: true
        accepts_nested_attributes_for :user
    end
end

We then create the Userable concern that, when included in our
company.rb and agency.rb files, establishes a has_one relationship with our User class.

# db/schema.rb

create_table "users", force: :cascade do |t|
  t.string "username"
  t.string "password_digest"
  t.string "userable_type"
  t.integer "userable_id"
  ...
end

The last thing we need to do is include userable type and id columns to our users table. These are used by delegated types to pull our user type by its type and id (eg. "Company", Company.id of 1)

NOTE: In AdSpace, the attribute "username" is given to the superclass so it can be validated as present and unique across all users while an attribute like "name" is given to the user types so they can be validated and compared amongst other instances of the subclass (An Agency and Company can both be named "brown_cow" but two Companies can't both be named "how_now".)

Controller Actions

Since we've established Companies and Agencies as different types of Users, we can handle any generic or shared controller actions in the Users Controller.

# app/controllers/users_controller.rb

def create
    company_agency = params.has_key?(:industry) ? (
        Company.new(company_params)
    ) : (
        Agency.new(agency_params)
    )

    user = User.create!({**user_params, userable: company_agency})
    session[:user_id] = user.id
    session[:user_type] = user.userable_type
    render json: user.userable, status: :created
end

In our create action, we create an instance of the userable depending on the received parameters (NOTE: If we add more user types, we could receive a "type" parameter and create a new type using a switch statement instead of a ternary operator.)

Entry.create! entryable: Comment.new(content: "Hello!")

The documentation uses this example to create a new record with a delegator and delegatee at the same time but I had difficulty implementing it in this way in the controller.

user = User.create!({**user_params, userable: company_agency})

I found that with strong params, using the splat operator (**) along with the userable attribute allows me to create, save, and validate the User instance in one line. This comes with the added bonus of also saving and validating company_agency.

We then save the user's id and the userable's type in the sessions hash to be used in other backend actions. Since we want to keep attributes like the password digest from being passed back into the front end, we only need to render the userable. NOTE: In AdSpace, I've opted to send back some User attributes like the username, user id, and userable_type to the frontend to filter or change views depending on the type of user (An Agency cannot reach the Ad creation page.)

# app/controllers/users_controller.rb

def show
    user = User.find(session[:user_id]).userable
    render json: user
end

In our backend, we can now query for and find a user based on the user_id stored in our sessions hash. If we wanted to search for a User amongst all Companies or Agencies without delegated types we would have to:

Add additional validations to make sure a Company and Agency don't share the same login credentials
Find a way for the front end to communicate to the backend what kind of User to look for (Open to user error)
Query through all Companies or Agencies for a match

# app/controllers/application_controller.rb

class ApplicationController < ActionController::API
    ...
    private
    ...
    def company_only
        render json: { errors: ["You must be a company to do this"] }, status: :unauthorized unless session[:user_type] == "Company"
    end
end

Since we can get the user's type from the userable_type column in the User's table, it is also easier to limit controller actions to the company.

# app/controllers/ads_controller.rb

class AdsController < ApplicationController
    before_action :company_only, only: [:create, :destroy]
    ...
end

We can add a before_action line to limit the creation and destruction of ads to a Users with a userable_type of "Company." This way of using delegated_types to distinguish User type in the backend is much more elegant than the alternative of storing an attribute of the Company in the sessions hash and then running it through an if or case statement. And this is only one of the many ways we save space in our code.

The Rest of the Code

The inclusion of Delegated Types assists us in cleaning up our code and establishing a separation of concerns in the backend and frontend. It saves us from having to write out CRUD actions for each type of User and keeps our logic in one place by limiting the required amount and complexity of fetch requests. Thanks to this, we can more easily build on top of our code using the existing framework.

Rails and ActiveRecord: Errors Save Lives

hyunho98 — Sat, 11 Nov 2023 02:11:24 +0000

I thought errors were the enemy?

Errors are often unwelcome and sometimes confusing elements that can throw a wrench into a seemingly logically sound program. Other times, error messages are succinct and easy to address. Though regardless of the type of error, we as programmers see them as a problem that is out of our control. What if that wasn't the case? What if we made our own errors?

Why custom errors?

Custom errors in rails can be used by programmers to communicate to other programmers and users that something has gone awry. A custom error can also be more specific and concise, making diagnosis and repair much easier than it would be otherwise.

Errors in ActiveRecord

More often than not an error in ActiveRecord is destructive to the user experience and could point to a problem without showing the actual cause of the problem. For example, ActiveRecord may throw a RecordInvalid error not because something is wrong with the code, but because the user tried to submit a form with invalid values (think about password fields requiring characters or length.)

In the case of an ActiveRecord error, the output would be an error page that is confusing to a user without coding knowledge.

rescue_from

What we can do to avoid this situation is to use rescue_from in a controller to quite literally rescue the program from an error that may be thrown by the ActiveRecord model. A rescue_from call may look something like this.

rescue_from ActiveRecord::RecordInvalid, with: :record_invalid

Every method call that may result in a RecordInvalid error will now be caught and then deferred to a method (:record_invalid) that we have defined elsewhere in the controller. Since this method won't be accessed outside of the class, we can make it private.

private

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

With this bit of code, instead of a confusing page view, we now get a json response containing an array of error messages and a 422 status code (unprocessable entity) from the server. Since this specific error is caused by validations, through the magic of ActiveRecord, we get an array of messages that tell us which validations failed. We could also return our own messages by replacing the code within the brackets.

...
def not_found
   render json: { errors: ["This thing was not found in that place"] }, status: :not_found
end

We've changed a couple of things between the last example and this one but the idea stays the same; instead of an error page, we get an error status code and an array of messages. However, this time, the error message is something that we can set ourselves. For example, if we have a program that works off of a database of apples in an apple tree and someone tries to search for an avocado, we can return this error message ["This [AVOCADO] was not found in the [APPLE TREE]."] and/or any other relevant error messages.

How does this help the user?

After the view receives the json response, it can then be used to communicate to the user that something has gone wrong. Instead of pulling the user out of the app to show them an error screen, since we have an array of error messages, we can just streamline these messages and display them in a way that the user can understand.

Much easier to understand than the error page that would display otherwise.

Using error messages as a programmer

In a development environment, code will often be run and rerun many times by multiple different programmers. So being able to communicate when and where something goes wrong is important. So just like the user, a programmer can use the error messages to either

Test and isolate certain errors to make sure the user cannot do anything that should not be allowed.
Test the application and receive accurate feedback on what needs to be fixed.

Usage outside of ActiveRecord

We've been talking about rails this entire time but how can we practice using custom errors outside of Ruby and ActiveRecord? Most coding languages also have custom error implementation. It's very common for languages to have a way to 'throw' and 'catch' errors because that's how errors are usually dealt with internally. That's why an understanding bugs and debugging is a supremely important skill for developers. Using this skill to create meaningful custom errors only further adds to an app.

Building habits

So how can you or I start coding with custom errors in mind? Without inflating our code with multiple error throws that don't make much sense, how can we apply this mode of thinking? One good place to start is to visualize how the code will run as you're building it. Is there a component of code that has many moving parts? We should throw an error at important junctions of that component so the problem is easier to diagnose. What if we threw error messages in sections of the program that will frequently interface with other bits of code? Although understanding good practice may be difficult at first, constantly asking questions and testing ideas may help build key habits that could be used throughout an entire career.

SQL Joins - Drawing a Picture

hyunho98 — Mon, 28 Aug 2023 23:12:36 +0000

What Is A Join

In the context of SQL, a programming language designed for coders to process information in a database, a Join is a way to connect two or more different tables that share data. One way we can illustrate this is by using the example of artists in a museum; an artist (table 1), may have many art pieces (table 2). Once an artist creates a piece of art, their connection to that art is immutable. However, artists also have names and art styles amongst many other personal traits. If an artist creates a piece of art, does it also take on these attributes? No, the art piece has its own traits such as a name, description, and time of completion. So in the context of a SQL database, how do we make this connection?

ID Association

The conventional way of doing this is to assign an ID number to each instance of an artist or art piece. This is easy to do within a database table because you can assign the row number as a database entry's ID number. But how would we use this to connect artists to their art? The key to doing this is establishing a "has many/belongs to" relationship between the two. Since the relationship between an artist and their art is immutable, we can say that an artist has many art pieces while an art piece can only belong to one artist. Knowing this, we can add a column to the art pieces table that correlates to the ID number of the artist that created it. Now that we've established the visual connection, all we need to do is join the tables using code.

Inner Joins

The most common kind of Join in SQL is called an Inner Join. An inner join connects two tables and returns data that is shared between the two. Currently, in our artist/art example, the only connection we have between the two tables is the artist ID association. When using an inner join though, this information is all we need. Let's say that we have a list of every single art piece on display at a museum. However, this list is totally unorganized and we need to find all the art that is associated with a specific artist. In this table full of every different art piece we can execute this bit of code.

SELECT art_pieces.id, artists.name
FROM art_pieces
INNER JOIN artists ON art_pieces.artist_id = artist.id

What does this do for us? This bit of code finds every single instance in the art_pieces table where the artist_id column of the art_pieces table matches the id column of the artists table. From there it gives us the id of the art piece as well as the name of the associated artist for every matching example. Now that we know where in the table our art pieces are located, we can now pass this information along to someone (or something) else that will sort this out for us.

Outer Joins

The other kind of common join is called an Outer Join. While there are a few different kinds of outer joins, the most used amongst them are the Left Outer Join and Right Outer Join.

Left Join

The left join, like the inner join, pulls information that two tables share. However, it can also retrieves information from one table that is unrelated to the second. Using our museum example, we can set up a third table in our database called section. We can set up a section with attributes like name and sponsor. Since a section can also have many artists, let's add a section_id column to artists so we can make the connection. What we can do with this information is set up a left join that might look something like this.

SELECT sections.name, section.sponsor, artists.name
FROM sections
LEFT JOIN sections ON sections.id = artists.section_id

This gives us all of the queried information in the left table, sections. Meaning that even if a section doesn't have a sponsor, it will still include that table entry in the result as NULL. This could be used to get a complete set of data regarding a museum's sections while only getting the associated data from the artists table.

Right Join

The last of the commonly used joins, the right join, functions in a similar way to the left join. The left and right joins function in a similar way so they also look the same in practice.

SELECT sections.name, sections.sponsor, artists.name, artists.style
FROM sections
RIGHT JOIN sections ON sections.id = artists.id

This join, unlike the left join, extracts information from the right table, artists, that may not have matches in sections. Meaning that any entry where sections does not have a sponsor will now not be included in the resulting join table while any entry in artists that does not have a style will now be featured as NULL in the new table.

Other Joins

There are many other kinds of joins that are utilized by SQL coders such as the full outer join, self join, and cross join. However, these are more niche and require a little more understanding of SQL and its use cases.

useState() and Props. When, Where, Why?

hyunho98 — Thu, 13 Apr 2023 07:25:27 +0000

Before State

It's important that a programmer learns to utilize props before picking up State. This is because understanding props and information flow is imperative to building a well organized, structured program. Most of the organization of a program is done through the use of different components. Utilizing components in your program has two main benefits, flexibility and reusability. When you separate your code into components, you make your program more flexible as a whole because individual components can be used and reused in different places.

function Component1() {
  return (
    <form>
      <input type="text" placeholder="First Name"/>
      <input type="text" placeholder="Last Name"/>
      <button>Submit</button>
    </form>
  )
}

default export Component1;

Take, for example, a simple First and Last name form. This component can be used in multiple locations for different purposes (What if you need the first and last name of the user? Maybe there's another page where you need the name of the user's family?) without having to repeat the code in those different locations. Components make fixing or adjusting code easier as well. Fixing or adjusting/adding to the component is much easier than scanning through every instance of a form to make the same change multiple times. But what happens when you submit that form? Where would the information go?

Introducing Props

Props are used to send information between components. Because components in react consist of functions that return JSX, information flows through these components in the form of arguments to those functions in the form of props.
function Component1(props) {
Let's say in our form component we want to clarify what we want the user to put into the first and last name form. We can pass a string through the props argument. This happens when we import and call Component1 in a separate parent component.
<Component1 message="Enter your name" />
We can then access this message string in our form (Component1)

function Component1(props) {
  const formMessage = props.message;
...
}

But what if we want to submit the form and send that information and send it back to the parent component?

Using Callback Functions in Props

If we wanted to send information back up the file tree, we would have to use a callback function. To make use of the callback function, we would have to build one first.

...
function formCallback(formData) {
  console.log(formData)
}
...
<Component1 message="Enter your name" formCallback={formCallback} />

From here we would use the callback in our form component

function Component1(props) {
  const formMessage=props.message

  function submitHandler(e) {
    e.preventDefault()
    props.formCallback(e)
  }

  return (
    <form onSubmit={submitHandler}>
      <h2>{formMessage}</h2>
      <input type="text" placeholder="First Name"/>
      <input type="text" placeholder="Last Name"/>
      <button>Submit</button>
    </form>
  )
}
...

Whenever the user clicks on the submit button, the form information would then be sent to the parent component's callback function. From there the information can be used and operated on from the parent component.

But what if we wanted to operate on variables within the child component?

Enter the useState() Hook

State is mainly used in react to retain information between renders. A benefit of this is the ability to use this persisting information in different components. To use useState(), the programmer must import the hook into their code.
import React, { useState } from "react"
From there, a state object can be created in the code. State should be used where the information is relevant but for our purposes, let's say that the form component is a child of two parent components which are also child components of our App component. We want both of App's child components to be able to access the state object, therefore, we'll create it in the App file.

function App() {
  const [message, setMessage] = useState("")

  return (
    <parentComponent1 message={message} setMessage={setMessage} />
    <parentComponent2 message={message} setMessage={setMessage} />
  )
}

Note that when using the useState() hook, we declare two variables in an array. In simple terms, the first variable (message) is used as a getter, while the second variable (setMessage) is used as a setter.

From here we can access the state variable and set the state variable in both parent components. We can use the setter variable in either to set the message of the variable to
setMessage("Enter your name")
or
setMessage("Enter your mother's name")
and then pass the getter variable to our form through either parent component
<Component1 message={message} formCallback={formCallback} />
from there we can access the message variable in our form

function Component1(props) {
  const formMessage=props.message

  function submitHandler(e) {
    e.preventDefault()
    props.formCallback(e)
  }

  return (
    <form onSubmit={submitHandler}>
      <h2>{formMessage}</h2>
      <input type="text" placeholder="First Name"/>
      <input type="text" placeholder="Last Name"/>
      <button>Submit</button>
    </form>
  )
}

Depending on which parent component we use to call the form, the message being displayed at the top will differ. This adds further flexibility to our components because we can add custom elements to our component depending on the context in which we call it. Even if we were to render the form separately, when the setter function of the useState() hook is called, it will re-render the page while retaining the information that we store in the variable.

Overall, it's easy to understand once a programmer gets used to thinking in terms of information flow. However, for the sake of cleanliness, efficiency, and keeping code DRY, programmers must practice storing information in only the relevant places.

Fetch Requests, Promises, and Asynchronous Code

hyunho98 — Sun, 15 Jan 2023 18:09:41 +0000

What happens when a fetch request is made in JavaScript? Most of it happens under the hood so it's easy to skip over when learning how to code in JS. However, learning how exactly a fetch request interacts with the machine and server is imperative to writing efficient code.

A quick summary of the order of operations when the machine runs a fetch request:

Interpreter encounters the fetch() request
The machine creates a separate executable stack for the request
The machine continues running the program

meanwhile...

3a. The fetch request returns a promise
3b. The promise either returns resolved or rejected
3c. If the promise is resolved, runs any subsequent then() requests which also return promises which are then resolved/rejected

Why is the `fetch()` request asynchronous code?

Asynchronous code, put simply, is code that is set to run not in sync with the rest of the code. Fetch requests automatically fall under asynchronous code due to the nature of a promise. Promises run for an indefinite length of time so to make sure the program doesn't freeze at a certain point, the lines of code are run while the promise is waiting for resolution. And then whenever the promise is settled (when the promise is either resolved or rejected), the code goes back to the fetch request to either run (or not run) the rest of the fetch request or subsequent then statements.

What exactly causes the promise to run for an indefinite amount of time?

To understand why the machine decides to allocate a separate place in memory to run the fetch request, it's important to know what exactly a promise does. A promise has three possible states:

Resolved
Rejected
Pending

When a promise is either resolved or rejected, it is considered settled and the code within the fetch request is executed or skipped as a result. But even before that, the fetch() line makes a request to an external server, during which, the promise is placed in a pending state. While in this pending state, the local machine must wait for a response from the server machine to continue executing the program. The server machine isn't expected to respond instantly and any responses from the server are subject to latency. This is why a fetch request's runtime is considered indefinite and is executed independently of the rest of the program.

For example, here's an excerpt from my Flatiron phase 1 project, Coffee Bean Database:

fetch('http://localhost:3000/coffee_beans')
  .then((response) => response.json())
  .then((data) => {
    console.log(2) //CONSOLE LOG 2
    data.forEach((bean) => { 
      document.getElementById('tilecontainer')
      .append(createTile(bean))
        if (!locations.has(bean.location))
          createOption(bean.location)
    })
})
console.log(1) //CONSOLE LOG 1

Of the two console log lines, which do you supposed runs first? Surprisingly enough, the code logs 1 to the console before 2 even though console.log(2) occurs earlier in the code. Like in the example, this happens even when the server getting sent the request is running on a local machine. Depending on how long the server request takes, more lines of code may be run before the promise becomes settled. This must be kept in mind when creating or debugging asynchronous code as code that makes use of the data returned by a fetch request may encounter issues if the fetch request isn't settled by the time the compiler reaches it.

Flatiron Phase 1 - A Retrospective

hyunho98 — Sat, 07 Jan 2023 12:24:21 +0000

Phase 1 Project

Link

Challenges

Figuring out how to implement a star rating system and location filter was fun, though I believe that the answers I found were not the most efficient.
Structuring my code in a way that made sense. I think that for the most part, I was successful in keeping my code DRY. However, I don't think I implemented functions in the most efficient way and in the process of trying to split up tasks into functions I believe I decreased overall readability.

Successes

Implementing CSS and presenting the webpage in a way that makes sense to the user.
Finding a solution for the star and filter feature that works in perpetuity. I believe that I coded the features in a way that does not rely on code from too many different locations in the program. Therefore, adding new features should not require too much restructuring.
Code readability. For the most part, comments are short but get the general message across. Although I need more practice, reading through the code is not too difficult.

Failures

Between the original mockup and the final product, I did not implement all the planned features. Some missing features include a search by keyword input field and filter by rating.
I didn't keep adding comments in mind, so most comments are terse and don't contain specifics
I did not manage my time well. Because I didn't manage my time well, some functions were added out of order or without structure in mind. To me, the code looks messy in some places due to this.

Improvements to be made

Add more features. Not only will adding features flesh the program out towards what I had originally envisioned, It will also test the rigidity of the code that already exists.
Keep Big O Notation in mind. I'm interested in always improving efficiency and would like to be able to look at a snippet of code and find a way to make it run faster or take up less memory.
Focus on improving readability. Human memory is limited and I won't be able to remember what every line of code's purpose. Even if just for my own sake, code needs to be readable.
Improve on understanding context. For most of Phase 1, I went with the answer that came quickest to me instead of giving more thought to what the best answer might be. In retrospect, I probably used for loops much more often than I needed to. e.g.

const array = [1,2,3]
const newArray = []
for (let i=0; i < array.length; i++)
   newArray.push(array[i] * 2)

as opposed to

const array = [1,2,3]
const newArray = array.map(x => x * 2)

To do list

Get into the habit of putting more thought into the code I write. Find the best solution to a problem and make a mental note. Hopefully practice will make perfect and down the line I will be able to more naturally implement good practice.
Be more mindful about adding comments. Add comments for every little thing and then shave them down later. Eventually, comments will become more intuitive and make more sense.
Add code for features as they come to mind. Currently the biggest thing I missed is the search by keyword functionality. The pseudocode may look like this

grab values from text input box
grab values from the DOM
loop through DOM values
   test for matching values
hide all tiles that don't match

Notes

Before Phase 1, I took on extra responsibilities in other parts of my life. This definitely hindered my work-life balance and I struggled to manage my time as a result. Remember: This is not your fault. Learn from this and know your limits and what works for you moving forwards.
Remember to communicate. Even with all the hiccups, I have no excuse for not communicating that with the people that could help me most. Whether with confidants or my cohort lead, I should update the people in my life with relevant information so I'm not leaving them in the dark.
Always work on having a regular schedule. I learn best when I build on top of habits. Even when you don't have any required work, set aside time. If you don't know what to do with that time, explore.
Going into Phase 2 or any other future learning opportunities for that matter, take your time. If a concept doesn't immediately stick, let it marinate and try to find uses for it in different contexts. This will give you a better understanding of how something works and when to best apply that information.