DEV Community: Elias Robert Hakim

Redux, Tool Kit

Elias Robert Hakim — Wed, 07 Jul 2021 20:59:23 +0000

As React applications grow larger, and more complex, sharing and passing state and props from a child component to a grandparent component and onto a separate grandchild component can be a cumbersome chore. Often times this complexity can lead to bugs in your program that are difficult to trace, as you have to check multiple locations in different files for behavior that is giving you the undesirable results.

Fortunately for us developers, Redux greatly simplifies this process by taking most of our local state, and keeping it in a 'store' for us at the application level. This is advantageous for a number of reasons. Firstly, it becomes a breeze to pass state from a child component, to the store, and then to a separate component. Secondly, it streamlines the debugging process, because the store acts as a single source of truth regarding the current state of our application.

Redux is a powerful open-source JavaScript library that we can utilize to manage application state.

Within Redux, there are a multitude of ways to implement this wonderful library. The Redux Core library gives great freedom to the developers and enables you to have precise control over each individual aspect of it's setup. This is a wonderfully flexible approach and it empowers developers to exercise absolute control over Redux's setup and implementation in their app. However, the setup can be tedious- with the structure spanning multiple files in multiple directories. The verbosity can act as a barrier of entry for those developers who are trying to avoid a complex application and wish to have a simpler, more streamlined approach.

Redux Toolkit is an excellent way to include the functionality of the Redux library with less setup, and abstraction that mitigates a lot of boilerplate code writing for you.

My favorite part of using redux is using Slices.

Now, what is a slice? A slice is a a 'slice' of state. For example, in my application, I am using state to manage Posts and Comments. In my redux directory, I have a Post Slice and a Comment Slice. As you may guess, the Post slice file houses the thunks to fetch post data from my api. The slice also will contain the reducer logic to return data payloads to the store.
On the flip side, my comment slice will contain those same items- but relating to the comments instead.

Lets talk about the different components within Redux.

Firstly, we have the Actions. Actions are a plain JavaScript object that have a type key and a payload. The type indicates what kind of action it is. For example, the action for retrieving posts from an API might have the type: GET_POSTS. When the action is passed to our slice, the slice will look at the type and decide which reducer to pass the payload to.
The payload of the action is where we store the data we are sending or receiving. In the aforementioned action { type: GET_POSTS }, my payload contains an array of post objects.

{type: GET_POSTS, payload: [ {postOBJ1}, {postOBJ2}, ect...] }

The payload value can be a string, an array, an integer, a boolean, or even an object!

So how do we pass our object to our slice?
We dispatch it!

Dispatch is a Redux method that accepts an action object as a parameter. The only way that we can update the state of our Redux store is to dispatch an action to our reducer. Dispatching can be though of similar to an event listener. When a change in state happens, and we want that change to be reflected in our store, we dispatch the action containing the value we wish to pass to our store.

Now where does the reducer fit in?
A reducer is a function that takes current state and an action as parameters. The job of the reducer is to return state.
So when we pass our GET_POSTS action to the reducer, we can write logic to take the action payload data and return that data to our store.
For example, when I fetch my posts from my API, the action.payload contains the array of post objects. In my GET_POSTS reducer, I have this following logic:

return state = action.payload

This ensures that my payload of Posts will end up in my store, making those posts accessible to the components in my React app.

Now we generally don't want to mutate state to keep our application bug-free.

However, when we are using Redux Toolkit, the createReducer and createSlice functions use a library called Immer. What this enables us to do is write logic that typically would mutate state. Instead of directly mutating state, however, Immer makes use of proxy objects and keeps track of our changes.
So within the context of my slice, I am able to write code such as:

state.push(action.payload)

to return state to my store!

How cool is that?!

I highly recommend taking a deeper dive into the Redux Toolkit documentation to see how you can put this powerful library to work in your own application!

Hooking Up With React

Elias Robert Hakim — Wed, 30 Jun 2021 19:06:20 +0000

In React, there are a great many ways to implement functionality. In my Flatiron School curriculum, we were initially taught how to build each component as a JS ES6 class, initializing state, using a constructor and taking advantage of component lifecycle methods, such as componentDidMount(), and componentDidUnmount()

As you may gather from their names, these lifecycle methods are run when our component renders to the DOM, and when the rendered component is removed from the DOM.

Enter the functional component.

Functional components are similar to class components in that, when called, our component will render the HTML we tell it to return in the DOM. However, without an ES6 class, we cannot construct a new instance using state, and we loose access to the "this" keyword that is so omnipotent within the context of a class.

Functional components, do, however take full advantage of the JS closure and the wonderful lexical scope that comes with them!

How, then, do we imitate the lifecycle methods and gain access the store (if using Redux) within the scope of a functional component?

Enter the React hook.

Hooks, while sounding intimidating, are simply functions that you can call in your functional component. Hooks are, according to the React docs, simply "functions that let you "hook into" React state and lifecycle features from function components"

They do have a few different rules to guide usage.

Since classes can be given an initial state, and have defined lifecycle methods, you don't need to use hooks in class components.

Hooks must only be called at the top level of your functional component. It is inappropriate to use a hook within a conditional, a loop, or a nested function. Adhering to this guideline will ensure that the hooks are called methodically, which makes them reliable and predictable.

You are able to use many of the same hook within a single component.

For example, if you are using Redux, and needed to access different areas of state, you are able to reuse the useSelector() (a custom hook that ships with React-Redux) hook multiple times- assigning its return value into a variable.

const posts = useSelector((state) => state.posts) 
// retrieves what is stored in state.posts and makes it available // in posts.
const comments = useSelector((state) => state.comments)
// both posts and comments are accessible in their respective
// variables within the scope of this functional component

The useState() hook allows you declare a setter and getter, as well as initializing state with a given variable for use locally within your functional component. This is incredibly handy if you are trying to implement a feature that will render conditionally.

const [showForm, setShowForm] = useState(false)

In this example, we pass an initial state value of

`false to the useState hook. Now, our falsey value will persist, and is accessible by calling our showForm variable. "setShowForm(!showForm)" will set the value of showForm, mimicking a change of state, locally, within our component.



function Post(props){
const [showForm, setShowForm] = useState(false)

return(
<button onClick{() => setShowForm(!showForm)}> Show Form </button>
{ showForm ? <Commentform id={props.id} /> : showForm}
)

}

In this example, we are using the useState() hook to set a boolean. Our Post function will render a button with an onClick event handler that will call our setShowForm function, which is generated by useState() to set the new value of the showForm variable. Here, we are toggling booleans. Finally, in the JSX below our button we are checking the value of the showForm variable with the ternary operator. If showForm returns true, it will render our comment button passing in the props that were passed when our Post() function was called. Else, it will return a falsey value and no comment form will be rendered.

React grants you the ability to even write your own custom hooks! These powerful tools are not only incredibly useful, but they are endlessly customizable.

With hooks, we are able to make our functional components behave like class components!

On Collections

Elias Robert Hakim — Wed, 02 Jun 2021 02:48:53 +0000

As you know, datatypes play an enormous role in our lives as programmers. A lot of what we do is create, collect, transform, and manipulate data before packaging it up and sending it off.

While I was building out my single page application- my first app in javascript- I encountered a datatype that I hadn't played around with too much: the HTML Collection.

I came across this object by running:

const deleteButton = document.GetElementsByClassName("delete-button")

My goal was to add an event listener on to each of these buttons, so that I could delete the recipes I was dynamically displaying with my app.

The output of the .GetElementsByClassName() is an HTML collection. Now, an HTML collection is a live object- which means that the output of that same function with the same argument passed in will be different collections, depending on how many nodes are on your DOM with the stated class name.

Okay, I thought to myself- this sounds like what I need... Because I only want to add this event listener to the buttons that have rendered- and that number will change based on the number of recipes displaying at the same time!

Well, I was given an error message telling me that I am unable to iterate over these HTML collections when I tried to run my code:

deleteButton.forEach( d => d.addEventListener("click", deleteHandler)

Why is this happening, I thought- I popped a debugger in my code and played around with the console, hypothesizing and experimenting with my suspicions. Unable to come up with a solution, I turned to MDN's Javascript documentation.

Quickly, I was able to come across the Array.from() method!
According to MDN, this "static method creates a new, shallow-copied Array instance from an array-like or iterable object."

This sounded like exactly what I needed. Another quick search for HTML Collection confirmed my suspicion- An HTML Collection is actually classified as an array-like object!

So what is an array-like object? Well, it is like a primitive array. It looks similar to, and shares some behavior traits with the classic Array- but that is the end of how they are similar. Array-like objects don't have access to the array methods that normal arrays have access to- methods including .forEach() and .map()!

So using my newfound knowledge I set off to experiment with my new friend, the Array.from() method.

const deleteButton = document.GetElementsByClassName("delete-button")

Array.from(deleteButton, (element) => {element.addEventListener("click", deleteHandler()} 
)

In the above code, I declare a variable named deleteButton, and assign the output of my GetElementsByClassName("delete-button")- which is an HTML Collection of all of the nodes with that class on my DOM.

Then, Array.from(deleteButton... essentially makes a copy of that array-like object, except it has the behavior of a traditional array.

Now, passing an arrow function to the Array.from(), I can call the .addEventListener() function onto each of those array elements, thus giving them the desired behavior- dynamically!

This process of rising to a challenge, and coming out with a greater understanding of programming is both fun and rewarding! I really have enjoyed putting the critical thinking skills I have developed to work.

Partial to Rails

Elias Robert Hakim — Tue, 04 May 2021 19:57:53 +0000

During the last few weeks, I have been pouring my time and energy into making the jump from Ruby into Rails. My immediate reaction to running the command

rails new

was "WOW!"

That amazement has not worn off...

Building out my first Rails app became an exercise in frustration, as the abstraction in the Rails platform soon concealing functions that were explicit in Sinatra in a shroud of ambiguity.

"I thought Rails was supposed to help me, not hurt me." I said to myself as I was manually building out my views pages for each model. And I was absolutely right- Rails IS supposed to help the developer with it's built in functionality- it doesn't hurt you, you just have to peel back the mysticism and become familiar with the ways it helps you!

In my case, I want to talk about rendering templates. Let's start talking about this method in the context of a Sinatra app.

get '/bikes/new' do @bike = Bike.new erb :'bikes/new' end

In this method I'm having to specify that I'm sending a get request to the /bikes/new path and in the context of that path I am setting up an instance variable with a freshly instantiated instance of my Bike class. I'm also specifying exactly which .erb file to render.

In this case, the new.erb file contains a form with which we will populate the attribues of our bike object with information.

<form action="/bikes" method="POST"> <h2> Enter information below: </h2> <input type="text" name="bikes[name]" placeholder="Name"><br> <input type="text" name="bikes[description]" placeholder="Description"><br><br> <input type="text" name="bikes[serial_number]" placeholder="Serial Number"><br><br> <input type="submit" value="Create Bike"> </form>

Let's take a look at a similar method for a similar application, but instead built out in the rails framework.

def new @bike = Bike.new end

Okay, what is happening here? We are setting our instance variable to be a new instance of our bike class, but it doesn't look like there is anything else going on... there are no explicit instructions like the Sinatra example.

That is because Rails is intelligent, and built around conventions. Because of these conventions, Rails knows that you are sending a get request, and that it needs to render the new.html.erb view for our bike class. Rails even knows that file will exist in the app/views/bikes path. Lets take a look at what is in this file.

<h1> Enter Your Bike's Information Here: </h1> <%= form_with(model: @bike, url: userbikes_path, method: "post")do |b| %> <p> Brand:</p> <%= b.collection_select(:bike_id, Bike.all, :id, :brand) %> <br><br> <%= render 'form' %> <% end %>

Okay, this is getting crazy- right? Where is our form?! Certainly Rails is smart, but how does it know what we want our form to contain? Well, it doesn't! But it has an amazing feature that will help reduce code smell.

<%= render 'form' %>

This line is telling rails to look for a file in the same directory called _form.html.erb. What is the purpose of this you ask?

Well, take our object for example. Our bike object has attributes that store data- a name, a model, serial number. When we are creating a form for this object we want to have a field for each submit-able attribute so we can attach the data to the correct attribute. We also may want to edit all of these attributes in the future for a variety of reasons. So we should have another form that communicates with our edit method, and this form should be almost identical to the new form, shouldn't it? Yes!

With the functionality of rails, we are able to build the bones for this form in our _form.html.erb file. Let's take a look at what this may look like:

<%= form_with(model: [@bike]) do |b| %> <%= b.label :name %><br> <%= b.text_field :name %><br> <%= b.label :serial_number %><br> <%= b.text_field :serial_number %><br> <%= b.label :notes %><br> <%= b.text_field :notes %><br> <%= b.submit "Save Bike" %> <% end %>

So in my bikes/new.html.erb, when I call <%= render 'form' %> I am telling Rails to look for that _form.html.erb and render that code where I am calling the render funtion.

Then, in my bikes/edit.html.erb file, I can call the body of the same form, but set the path the post request to call the edit method instead of sending that information to the update method like it does in the new page.

How cool is that? That is Rails cool!

Learning Through Application

Elias Robert Hakim — Fri, 09 Apr 2021 03:21:15 +0000

For my most recent project I decided to build a simple app where one can keep track of bicycle maintenance. For example, a user might have a few different bikes that require a variety of maintenance at different intervals. The idea came while I was fixing both of my uncle's bikes- he is very bad at maintaining both of his bikes and he rides quite a lot, which unfortunately leads to prematurely worn components and more expensive repairs.

The functionality I wanted to build in would allow a user to create a profile for each bike, storing a name, description, and a serial number for identifying characteristics. Easy-peasy.

create_table "bikes", force: :cascade do |t|
    t.string "name"
    t.string "description"
    t.string "serial_number"
end

The next major component to this app is the maintenance records themselves. I wanted to be able to track date, cost, and any notes or a brief description of the work performed... For example, if I wanted to remember the date that I had last changed the oil on my suspension fork, I wanted to be able to look for a record named "suspension tune" and retrieve the date the service was performed as well as a brief note- perhaps to state if you just changed the oil or to let yourself know that you had bled the damper or replaced the wiper seals in addition to the oil change. This is the basic schema I came up with:

  create_table "maintenance_records", force: :cascade do |t|
    t.string "name"
    t.string "date"
    t.integer "cost"
    t.string "notes"
  end

Now that we have the bike schema and the maintenance record schema set up, I needed to include some basic user information. All I wanted here was really basic functionality, essentially the bare minimum to create a log-in feature so you can password-protect your data...

  create_table "users", force: :cascade do |t|
    t.string "name"
    t.string "email"
    t.string "password_digest"
  end

Now, onto the relationships!

I wanted to associate the bikes to each user. Using ActiveRecord's awesome built in macros, this was a cinch! All I would have to do was add the has_many :bikes macro to my user model and the belongs_to :user macro in to my bike model, and run a couple of easy migrations to add a user foreign key to my bikes schema.

class User < ActiveRecord::Base 
   has_many :bikes
end

class Bike < ActiveRecord::Base
   belongs_to :user
end

Moving forward to the maintenance records... This one was a challenge for me, an opportunity to confront what had been a difficult concept for me to understand head on. Since it was such a crucial piece of my original concept, I refused to compromise and forced myself to experiment with the nuances of relationships.

I knew that I wanted to be able to look up maintenance records that were associated with a particular bike, so the first thing I tried was setting up a belongs to/has many relationship between bikes and maintenance records. Similar to above, I just put the appropriate macros in each model- maintenance records belong_to :bikes, and bikes has_many :maintenance_records before running the appropriate migrations to include the foreign keys.

But something was missing... I wasn't sure what it was until I ran through my CRUD functionality with the maintenance records....

With one of my personal hobbies being purchasing, tuning, modifying, riding, and ultimately selling bikes, I wanted to be able to view all maintenance records for all of my bikes. This was important to me, because I wanted to figure out how much I might spend over the course of a year on bikes. It is really easy for me to keep track of what I have sold and the amount I net from the sale- but because there may be many transactions related to maintenance for a particular bike, it is difficult for me to track expenses.

My first solution to this problem was to try to build a new route between the user and the maintenance records, but this turned out to be a very clunky way to do it, and I couldn't figure out a means to make it simple and dynamic. There had to be a better way to do that...

Enter, the has_many :through association! As the official ruby on rails guides says so concisely: "This [has_many :through] association indicates that the declaring model can be matched with zero or more instances of another model by proceeding through a third model."

Aha!

Typing fervently, I revised the association macros and altered the db schema to model the has_many :through syntax, ensuring that my user model had a reference in the bikes table, and that my bikes model had a reference in my maintenance_records table.

Now, I had to test it out by seeding a few bikes and maintenance records to make sure it was working. I wanted to see if I could test out the associations, so I placed a binding.pry in by bikes/show route.

In this route, I wanted to make sure I could look up all of a user's maintenance records, as well as find all of the maintenance records that belonged to a the particular instance of a bike.

Once I was inside my pry, I wanted to test my associations. First, I would assign an instance of my Bike class to a variable, and then use my .maintenance_records method on that instance, hoping that it would return an array with the correct maintenance record for that bike.

bike = Bike.find_by(name: 'Big Iron')

bike.maintenance_records

=> [#<Bike:0x00007fa5323a2828 id: 8, name: "Big Iron", description: "Waltworks Hardtail 29er, 120mm", serial_number: "69854", user_id: 19>]

Okay, great! Look at what was returned! My bike object with all of its attributes, including the correct user id.

Next, using a similar process, I wanted to ensure that I could run the same .maintenance_records method on a User object, since a maintenance record belongs to both a bike and a user.
Below, you can see that I searched my User class by name to find my user object and assigned that object to a variable. Then, I used my .maintenance_records method.

user = User.find_by(name: 'Elias')

user.maintenance_records

=> [#<MaintenanceRecord:0x00007fa53231d6f0 id: 5, name: "Suspension Tune", date: "2021-04-14", cost: 13, notes: "changed oil in fork lowers", bike_id: 8>]

As you can see above, the method returned an array containing a maintenance record object. Looking through the attributes of the object you can see that this record belongs to my bike, Big Iron that has an id of 8. That is great, because that is correct!

Now, wait a minute... doesn't a maintenance record belong to a bike AND a user?! Why isn't there an attribute for user_id in the maintenance record object if that is true?

Let's take a step back to my first association test where we were able to return the bike object...

#<Bike:0x00007fa5323a2828 id: 8, name: "Big Iron", description: "Waltworks Hardtail 29er, 120mm", serial_number: "69854", user_id: 19>

Looking through the attributes, we can see that the bike contains a column for user_id.

This, dear reader, is the the beauty of the has_many :through relationship. The User has many bikes, and bike belongs to a user. The Bike has many maintenance records, and maintenance records belong to a bike. The User has many maintenance records through bikes. This complex relationship using bikes as a join table is what allows me to associate the user with the maintenance records via bikes! A critical difference compared to my first attempt where a User had many bikes, and had many maintenance records.

This critical difference was the difference between being able to create the app I had envisioned or having a basically useless app to meet the minimum requirements for my project. While the process of trial and error was indeed challenging and time-consuming, I am glad that I was unwilling to compromise on functionality. Despite increasing my work load, I really hammered the association lessons I was struggling with and came out of the project with a working app, and more importantly a stronger foundational knowledge that will certainly help me in the future!

My First CLI App

Elias Robert Hakim — Sat, 27 Feb 2021 17:42:47 +0000

Today marks the completion of my first CLI app, and while it is indeed basic, I have learned so much in the process.

At the beginning of the project, staring at a blank screen with basic code skills, an idea, and data to support the idea felt like looking for water in the middle of the desert... There are plants, and there is sand... Where there are plants, there must be some water...

The idea that any progress was great progress helped me get started, but it still felt like the first snowflakes falling before a 500" season. But, like a storm in the night, my progress began to accumulate and grow deeper by the day.

One of the things I found most interesting about the project was how much my original idea mutated over the build-cycle. Some of the challenges along the way helped shape the final product.

Originally, I wanted to search an API recipe database to categorize the meals by ingredient. Instead, the final product lets the user select a meal and provides a link to a website with the recipe and a link to a youtube instructional video. In the end, I believe this provides a much better user experience- as the CLI interface isn't the ideal way to display all the information required for a complex recipe's ingredients, measurements, and instructions.

Eventually, the each challenge gave way to progress and I was able to complete my app. The smile on my face when it started working is the biggest smile I have had in weeks! Despite the app's simplicity- this felt like an achievement. It felt different than completing assignments with pre-written tests. It was much more challenging to start with a blank drawing board and piece the components together one by one. I feel like this process really solidified my knowledge.

In the end, completing this project felt as significant as finding water in the desert...

Here's To The Journey

Elias Robert Hakim — Sun, 14 Feb 2021 06:18:05 +0000

Henry David Thoreau once said "The path of least resistance leads to crooked rivers and crooked men" and similar sentiments were floating in my head as I kicked up my feet after another thoughtless month of work documenting construction projects.

Much like 16th century French monarch, Lord Montaigne suggested; my mind stewed in the 'vague field of imagination'... yearning for a 'definite subject to bridle' my mind with.

Enter coding. I have had an on-and-off relationship with basic tutorials in javascript and ruby. While I always enjoyed learning about them, I never found the time to properly commit myself to the time and energy required to learn them beyond a very basic level.

The economic uncertainty in 2020, mixed with the timing of my biggest projects at work coming to a close blended with little work on the horizon created a volatile concoction ready for a spark. That combustion came in the form of an opportunity to spend more time with family, and finally get serious about pursuing coding. So I left what had been an easy and stable job to pack it all up and start over. Again. So it goes.

One month later, I have found myself wrapping up my first two weeks at the Flatiron School. It has been a challenge, but I know the hardest part was deciding to make a change. The famed jazz trumpet player Miles Davis boldly told his bandmates: "Do not fear mistakes. There are none." as he pushed the boundaries of jazz; setting the standard for the shape of jazz to come.

In the past two weeks I have worked harder than I have in years, and it feels good. It feels good to keep walking after the difficult first step. As I continue to grind my way through the curriculum, I know that once I stop myself to turn and look back to were I started, I will be surprised to see how far I have traveled. And that, I am looking forward to!

So here is to the journey!